[GRASS-dev] Discussing new GUI toolkit: v.pydigit

[Hamish]

> [Python]

Larger devel pool vs. C.
Whole classes bugs are removed vs. C.
It will never be as fast as C, but apparently it is fast enough?
  (the GUI doesn't take much number crunching; backend is still C)
I'm for it. (in my ignorance...)


> The jury seems still out between the main contenders for a GUI: QT,
> wxWidgets, and GTK.

Will Qt/GTK+ act+look natively on Mac/Windows? [no?] I think this is
most important for Mac; Windows it would be nice but the interface is
more of a mash; and let linux people do whatever they want (total mash).
If I understand Glynn's comments, this points to wxW?


I'm not sure I have the order correct:
 We program in Python, calling wxWidgets commands via wxPython bindings.
 wxW would then use a) Native Mac; b) GTK+ on linux; or c) Native Windows
  [GTK is not needed for Mac or Windows versions]

[*] Mac/windows users: how is "Audacity" for you?  http://audacity.sf.net
I'd suggest WinGimp and MacGimp as a GTK test and Qgis as a Qt platform
test.

interesting:
"A wxGLCanvas package is available to allow wxWidgets applications
(currently GTK and Windows only) to support OpenGL. Very few changes
need to be made to existing OpenGL applications."

also  http://wxglade.sourceforge.net


>From WikiPedia:
> WxWidgets is released under "a permissive modified (but explicitly
> OSI-approved) LGPL".

Sounds no problem, but what does it mean?


Also from WikiPedia "It also has a built in ODBC based database library,
an Interprocess Communication layer, socket networking functionality,
and more."

Will the "Interprocess Communication layer" help our piping stderr &
return value woes? Can ODBC be used for DB tasks, such as v.digit
attribute editing?


The other big Toolkit requirement is how easily each of these will allow
for integration of translation efforts. I have no idea about this, but
it could help us decide if one is great/terrible at i18n.
Do we have to go through another Unicode debate?



Hamish