[GRASS-dev] Re: GRASS-dev] [GRASS GIS] #293: wxGUI should provide a switch for region-constrained/free display mode

[Michael Barton]

On Sep 6, 2008, at 4:03 AM, <grass-dev-request at lists.osgeo.org> wrote:

> Message: 8
> Date: Sat, 06 Sep 2008 10:53:32 -0000
> From: "GRASS GIS" <trac at 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 at 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 at 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>