I’m late coming to Grass-GIS 7.0. Partly, this is because I’m also not enthusiastic about migrating all my stuff to a new OS that I don’t need.
However, I decided to run up Debian in a VM and give it a spin.
My very first observation relates to the Python interface: compared to either the old TCL-TK or the former d.mon X11, boundaries render too thick. It’s an aesthetic issue only, but I’ve worked with people who are willing to fight for their desired “look” practically to the death. Examples are included and I hope they survived intact.
TCL
Python:
Second, Python selection panels, for modules that should allow multiple selections, work badly.
For example, g.copy. In the TCL-TK interface, I can use g.copy for multiple copies. OK, I usually use the command-line anyhow, but: If I attempt a second selection in the Python interface pane, it replaces the first selection instead of adding to it.
I’ll continue fooling around with 7.0 and hope nobody - particularly our ever-helpful Markus and the rest of the development team - think I’m being deliberately critical. I’ve been a user of Grass-GIS for six years now, and it’s an indispensable part of my professional life. (I recently saw a company devote two weeks - I am not kidding - of ESRI temporary employee time doing stuff in the GUI that a competent Grass-GIS user would complete in hours, using v.distance and some database updates. The non-GIS manager simply didn’t believe my time estimate, even after a demo. “No, we’ll spend $4k on what we know.”).
Concerning the boundaries rendering too thick; under GUI settings (menu: settings - preferences) under the tab ‘Map display’, you can set the Display driver from Cairo (the default I think) to png. That will bring you back to thinner lines.
I was going to answer that there was an option to disable anti-alias, but I can’t find that option. But I guess that is what Cairo display is doing; anti-aliasing the lines.
As for the g.copy problem with selecting multiple maps, I can confirm that doesn’t work. Sounds like a bug to me, perhaps you can file a bug report?
I’m late coming to Grass-GIS 7.0. Partly, this is because I’m also not enthusiastic about migrating all my stuff to a new OS that I don’t need.
However, I decided to run up Debian in a VM and give it a spin.
My very first observation relates to the Python interface: compared to either the old TCL-TK or the former d.mon X11, boundaries render too thick. It’s an aesthetic issue only, but I’ve worked with people who are willing to fight for their desired “look” practically to the death. Examples are included and I hope they survived intact.
TCL
Python:
Second, Python selection panels, for modules that should allow multiple selections, work badly.
For example, g.copy. In the TCL-TK interface, I can use g.copy for multiple copies. OK, I usually use the command-line anyhow, but: If I attempt a second selection in the Python interface pane, it replaces the first selection instead of adding to it.
I’ll continue fooling around with 7.0 and hope nobody - particularly our ever-helpful Markus and the rest of the development team - think I’m being deliberately critical. I’ve been a user of Grass-GIS for six years now, and it’s an indispensable part of my professional life. (I recently saw a company devote two weeks - I am not kidding - of ESRI temporary employee time doing stuff in the GUI that a competent Grass-GIS user would complete in hours, using v.distance and some database updates. The non-GIS manager simply didn’t believe my time estimate, even after a demo. “No, we’ll spend $4k on what we know.”).
Concerning the boundaries rendering too thick; under GUI settings (menu: settings - preferences) under the tab 'Map display', you can set the Display driver from Cairo (the default I think) to png. That will bring you back to thinner lines.
I was going to answer that there was an option to disable anti-alias, but I can't find that option. But I guess that is what Cairo display is doing; anti-aliasing the lines.
As for the g.copy problem with selecting multiple maps, I can confirm that doesn't work. Sounds like a bug to me, perhaps you can file a bug report?
Cheers,
Paulo
On Thu, Oct 18, 2012 at 11:02 AM, Richard Chirgwin <rchirgwin@ozemail.com.au <mailto:rchirgwin@ozemail.com.au>> wrote:
I'm late coming to Grass-GIS 7.0. Partly, this is because I'm also
not enthusiastic about migrating all my stuff to a new OS that I
don't need.
However, I decided to run up Debian in a VM and give it a spin.
My very first observation relates to the Python interface:
compared to either the old TCL-TK or the former d.mon X11,
boundaries render too thick. It's an aesthetic issue only, but
I've worked with people who are willing to fight for their desired
"look" practically to the death. Examples are included and I hope
they survived intact.
TCL
Python:
Second, Python selection panels, for modules that should allow
multiple selections, work badly.
For example, g.copy. In the TCL-TK interface, I can use g.copy for
multiple copies. OK, I usually use the command-line anyhow, but:
If I attempt a second selection in the Python interface pane, it
replaces the first selection instead of adding to it.
I'll continue fooling around with 7.0 and hope nobody -
particularly our ever-helpful Markus and the rest of the
development team - think I'm being deliberately critical. I've
been a user of Grass-GIS for six years now, and it's an
indispensable part of my professional life. (I recently saw a
company devote two weeks - I am not kidding - of ESRI temporary
employee time doing stuff in the GUI that a competent Grass-GIS
user would complete in hours, using v.distance and some database
updates. The non-GIS manager simply didn't believe my time
estimate, even after a demo. "No, we'll spend $4k on what we know.").
For example, g.copy. In the TCL-TK interface, I can use g.copy for multiple copies. OK, I usually use the command-line anyhow, but: If I attempt a second selection in the Python interface pane, it replaces the first selection instead of adding to it.
This is a special case, `g.copy` doesn't define "multiple" params, it
uses "from,to" syntax. Choose "from" from map selection widget and
then manually write ",<map_to>". In any case autogenerated GUI of the
modules like `g.copy` is not very usable. It would be cool to have
some fancy "map management" to allow more user-friendly coping,
renaming and removing maps. It's core functionality.
