On Sep 6, 2008, at 4:03 AM, <grass-dev-request@lists.osgeo.org> wrote:
Message: 8
Date: Sat, 06 Sep 2008 10:53:32 -0000
From: "GRASS GIS" <trac@osgeo.org>
Subject: [GRASS-dev] [GRASS GIS] #293: wxGUI should provide a switch
for region-constrained/free display mode
To: undisclosed-recipients:;
Message-ID: <042.c32e73800c23ec17093f4df5c04885a3@osgeo.org>
Content-Type: text/plain; charset="utf-8"#293: wxGUI should provide a switch for region-constrained/free display mode
----------------------+-----------------------------------------------------
Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Keywords: | Platform: All
Cpu: All |
----------------------+-----------------------------------------------------
wxGUI should provide an easily accessible switch for region-
constrained/free display mode. Like gis.m does.
This is a feature request, not a defect. This kind of setting tries to have the image proportions inside the display window conform to the computational region proportions, rather than match the display window proportions. This affects only the way maps are displayed on the screen and has nothing to do with the computational region. Currently, maps are rendered to match the display window geometry and resolution. This is simple to calculate for rendering and renders the display almost instantaneously, regardless of the underlying geometry or resolution of the maps.
Constraining the image inside the display to the computational region produces a display with white space on either the side of the map image or above and below the map image. It requires recalculating the rendered map extents in a complicated way to keep it fitting inside the display window at different geometries but preserving computational region proportions. These kinds of calculations also have to be made whenever the map is zoomed in and out if the display is in this mode.
Having thought about this for awhile, I can't think of a good reason why we need to do this. When maps displayed in xterms, the display and computational region were inextricably linked. The xterm window always matched the computational geometry, AND changing the display also changed the computational region geometry. There were originally technical reasons for maintaining the computational geometry of images from maps inside the TclTk window (but that are no longer needed there). However, these technical reasons are no longer relevant in wxPython. The display window can be resized. The computational region can be set independently of the display. The bounding box of the computational region can be displayed. The display resolution can even be set to match the computational region resolution (though the only reason for doing this AFAICT is so that d.rast.num works. I'd prefer to fix d.rast.num because this display resolution change again adds complexity to the display rendering algorithms, slows it down, and is one more thing that can break). This also adds more complexity for users as it is not easily obvious what is going on when the display changes in this way.
I'm all for flexibility in the UI, but too many bells and whistles can lead to a GUI that is so complex that it defeats the purpose of making a complicated program easier to use. This balance is a general design issue that we continue to have to wrestle with in multiple places and not just the display. Now that we are getting more testing of the wxPython GUI--which is very good to have--and people become aware of it's potential, we will be faced with an increasing number of feature requests. We should consider all of them, but need to think which features will enhance the user experience, which could degrade the user experience, and which could have negative consequences elsewhere in the increasingly complex GUI code base (I think Martin counted around 40K lines in the GUI recently). Every feature added has a maintenance cost. Martin and I are already faced with the constant need to fix things that break when a new capability is added somewhere else.
Perhaps it's due to a lack of imagination, but this is a case where I can't think of any real-world use-related reason to try to have the image inside the display window match the proportions of the computational region (leaving white space around the image) that cannot be better accomplished with the already very diverse display mode controls. I also can't think of another GIS product that behaves this way. Can you or others give some examples of actual display use that requires this kind of option (warranting the added complexity in display rendering that it involves) that cannot be achieved in another way?
Michael
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/293>
GRASS GIS <http://grass.osgeo.org>