[GRASS5] Platform for next generation UI

[William Kyngesburye]

There is also the question of 'platform distictiveness' vs. 'cross- 
platform blandness', as someone put it on the Qgis dev list (in  
response to a Mac question I had), in toolkits.

It appears that Qt is moving towards the blandness end in Qt 4 - that  
is, doing specialized things the same on all platforms, instead of  
using platform widgets where possible.  This may make an application  
easier to develop across platforms, and make it more consistent and  
stable across platforms, but you may make it more difficult to use  
the application as well, if it doesn't behave like an application  
should on your chosen platform.

A specific example that I asked about with Qt on Mac OS X for Qgis:

- Open/Save dialogs are pure Windows design.  At least when they are  
customized.  Without any customization (filters, extra popups or  
buttons), Qt uses a Mac open/save dialog.  Add customization and Qt  
uses it's own, which is a Windows design.  This can be very confusing  
for a Mac user if they aren't familiar with other platforms.  Even if  
they are, the context of having this strange dialog box in a Mac  
environment could be confusing.

I'm not sure how Tcl/Tk Aqua deals with this - plain open/save  
dialogs look fine, but I couldn't find any customized open/save  
dialogs in GRASS to see that case.  Of course, Tcl/Tk in Apple X11  
works like any other X-based Tcl/Tk.

And since the Mac GTK port is only just starting, who knows how it  
will behave...


I would definitely prefer platform distinctiveness in a GUI.


On Jan 1, 2006, at 2:10 PM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>> My main goal has been to try to have some kind of organized,  
>> coordinated
>> effort in developing a new UI. GRASS seems a rather diffuse open  
>> source
>> project, which means that it is open to a wider variety of  
>> contributors and
>> more difficult to organize. It seems like we need to get a few  
>> energetic
>> people to give a UI a trial run and then try to build some support  
>> for it.
>> I'm trying to spark that.
>
> One final point to bear in mind is that much (maybe even most) of the
> work required for a good GUI consists of making the rest of GRASS more
> GUI-friendly, e.g.:
>
> + Removing assumptions about having access to a terminal, or even to
> stdin/stdout.
> + Minimising dependence upon global state (WIND, $GISRC, monitor pads,
> etc).
> + Improving modules' metadata (e.g. the information used by
> G_parser()).
>
> Part of that involves getting rid of stuff which is GUI-unfriendly,
> e.g. use of the vask library, G_ask(), R_get_location_with_*() etc. In
> order to do that without leaving GRASS in a crippled state, some of it
> will need to be replaced. In that regard, a basic GUI in e.g. Tcl/Tk
> or wxPython could accelerate some of the tasks which need to be done
> in preparation for a "real" GUI.
>

-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy