[GRASS-dev] Python GUI toolkits

[Michael Barton]

I'm willing to test, but what does it take to test this? I'm running GIMP
under x11, so I must have some version of GTK+ installed. Can I just get it
and run it or do I have to do anything?

.....

With respect to GUI design and platforms, I suggest we take things one step
at a time since we don't have a large development/design team, but do have
quite a bit of interest.

Out of the next generation GUI discussion of last Fall and early this year,
the basic plan was to...

1) Come up with a set of interface design specs.
2) Implement the new design specs as well as possible in the current TclTk
platform.
3) Identify and migrate to a new GUI platform if needed.
4) This step was not discussed, but reasonably, it would be to review and
revise if necessary the overall GUI design specs in the context of the new
GUI platform.

We're almost through step 2.

I recommend that we try to implement the design specs we are just now
completing in TclTk in a new platform, rather than trying to migrate to a
new platform AND comprehensively change the interface design again (after
just barely getting it out the door over the last 4-5 months). The latter
seems overly ambitious and likely to devolve into UI chaos, with multiple
competing designs. 

Currently, we have a team of people all working together on the same design
plan and same GUI platform. The result is how much it has progressed in such
a short time. I'd hate to lose that kind of synergy.

Granted, a reason for switching from TclTk to another GUI platform is that
it gives us richer options for a GUI (we already have very rich CLI
options). But it seems better to begin to explore those by improving on the
design specs we now have, rather than starting from scratch. And to be
honest, if the idea of learning Python (I've already started, given that it
is summer and I can work it in around writing and analysis) seems a little
daunting, the idea of learning Python, building a GUI, AND redesigning the
GUI from the ground up seems exhausting.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Hamish <hamish_nospam at yahoo.com>
> Date: Fri, 9 Jun 2006 00:47:45 +1200
> To: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Python GUI toolkits
> 
> IMO we should pick a GUI language based on its long term merits, not
> because we have a nice editor for one. Fast development is nice, but
> lack of bug reports is much nicer. (especially if they are upstream
> bugs)
> 
> 
> Having the resulting GUI look somewhat native is indeed very important
> on the Mac. Looking native but acting like GRASS on all platforms isn't
> too bad I think. Rewritting to conditionally "become" a Mac app on Mac
> and no where else is surely a bad idea. Linux people will be used to a
> world of heterogenous interfaces and Windows people will be used to a
> world of pain ... but on Mac  ... if I understand correctly
> 
> Python seems to be a common theme, that's nice to see.
> 
> 
> Can anyone test v.pydigit on Mac + native GTK? Win+WinGTK?
> Would pyGTK it need to have libglade on all platforms?
> Or just for development?
> 
> 
> David:
>> I was toying with the idea of creating a Matlab or R-style GUI for
>> grass. The idea would be to have a command line interface with helper
>> applications such as graphics monitors, text editor, file browser,
>> help-system, etc. All accessible from tool bars. People seem to really
>> like Matlab once they learn it and I thought that if a grass version
>> were done right, even guys like me might use it (which means that I
>> better write code that I want to use!).
> 
> FWIW, I really like the Matlab language & engine but I hate the 6+ GUI
> command interface. I run it -nojvm from my normal rxvt terminal window
> with nedit in Matlab mode for the editor. For me, I need to focus when
> working with it and a cluttered command window really hurts that.
> It doesn't help that the Java interface is slow, buggy, and the fonts
> horrible. I don't know R so well, so there the GUI version is a nice
> crutch -- I can see the advantage to the concept.
> 
> 
> 
> Hamish
> 
>