[GRASS-dev] Python GUI toolkits

Thu Jun 8 17:46:38 EDT 2006

Jachym,

The screenshots of v.pydigit look great. I just downloaded and tried to run
v.pydigit--just to see what happened.

It failed, saying I needed pygtk (I've got Python 2.4+ installed).

I went to the pyGTK website. There does not seem to be a pyGTK binary for
Mac OSX, although there is one for Windows. I dug around a bit, it seems
that compiling it on the Mac is somewhat tricky. It looks like it could be
available from Darwinports. I haven't used this (except for a brief tryout)
because it messes with some of my system settings, making it difficult for
me to run other x11 programs. Maybe Fink has it, but I haven't checked yet.

This makes me hearken back to the days of GRASS 5.0.1, when I had to search
around for a proper version of TclTk to run it. This isn't very attractive
to go through this just to be able to develop and run the
package--especially given I'd need to put it on my laptop too.

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: Jachym Cepicky <jachym.cepicky at centrum.cz>
> Date: Thu, 8 Jun 2006 23:10:17 +0200
> To: Michael Barton <michael.barton at asu.edu>
> Subject: Re: [GRASS-dev] Python GUI toolkits
> 
> On Thu, Jun 08, 2006 at 01:45:37PM -0700, Michael Barton wrote:
>> 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?
> 
> hallo, just get it and run ./v.pydigit
> 
> dependences are:
>     * python
>     * python-glade2
>     * python-gtk2
>     * grass61
> 
> these are the names of packages under debian. I have no idea, how to get
> them on other distro/unix :-(
> 
> short description
> 
>     http://les-ejk.cz/?cat=vpydigit
> 
> I'm looking forward to result
> 
> Jachym
> 
> 
>> 
>> .....
>> 
>> 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
>>> 
>>> 
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
> 
> -- 
> Jachym Cepicky
> e-mail: jachym.cepicky at centrum.cz
> URL: http://les-ejk.cz
> GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
> -----------------------------------------
> OFFICE:          
> GDF-Hannover
> Mengendamm 16d
> 30177 Hannover
> Germany
> e-mail: cepicky at gdf-hannover.de
> URL:    http://gdf-hannover.de
> Tel.:   +49 511-39088507