[GRASS5] Platform for next generation UI

[Maciek Sieczka]

On czw, 2005-12-29 at 10:26 +0100, Paolo Cavallini wrote:
> Hi all.
> So basically the GUI devel team is split in two:
> - TclTk (mostly Michael)
> - Qt/QGIS (mostly Radim)

The popularity of TCL/TK compared to QT is decreasing. Thus QT
develepers are more likely to join GRASS team than those who know
TCL/TK. QT is then a safer, more durable approach.

If QT, why not help developing QGIS GRASS Tools instead of developing a
native GRASS GUI from scratch? IMHO it would be safer - QGIS GRASS Tools
plugin is being actively developed already, while the modern, native
GRASS GUI is still a matter of concept only. (Slight OT: If only QGIS
could offer multiple displays with a highly managable (copy,cut,paste of
groups and layers alone) seperate layer tree for each display, it would
be perfect. Personally I would prefer  separate windows within one
workspace rather than tabs - to be able to display and compare between
multiple windows at one time.)

I think it would be better to help Radim and QGIS team in their effort
rather than starting somthing new which will never be really functional
I'm affraid. New native Grass GUI would be best, but it's not realistic
IMHO. And QGIS with Grass Tools and Grass Digit can be good. Better than
current Grass GUI for sure.

Pros for QT/QGIS approach that matter for me:
- active QGIS devel team
- most basic work already done, only need to jump in (in my
non-developer thinking, correct me if wrong)
- the ability to mix different datasources within QGIS, which Paolo
mentioned, is a cool feature. Eg. I'm digitising GRASS vector layers
with GRASS Digit tool in QGIS using geotiffs as background - no need to
double the data and fiddle with importing it to Grass first
- QGIS already displays GRASS rasters quicker than GRASS
- most FOSS GIS users (who I know) use QGIS already anyway. Thus QT libs
are already present in their systems, even if they don't use KDE. Let's
not force them to install another, TCL/TK, for Grass only - most users
won't need TCL/TK for anyting else
- TCL/TK, which Michael mentioned, is not as cross-paltform as QT is
- "the look and feel" for what it matters. I have took a look at
Michael's links with screenshots of TCL/TK apps, and although they look
better than our GRASS GIS manager indeed, I don't like those TCL/TK
sliders and window size control. They look always different (and worse
as to me) than those in KDE or GTK apps.

> Please don't take it personally, but I'm still convinced of the superiority of 
> the new approach, especially because we can tap from another valid pool of 
> developers (the qgissers), which is something we need.
> Using grass as an engine behind qgis has a number of important advantages 
> (behind the more pleasant experience for the "normal" GIS user), attracting 
> new users, easing up the migration from proprietary software (see 
> eghttp://www.faunalia.it/en/freegis_comments/qgis_mapinfo.php), and in 
> general, avoiding to expose new users to unnecessary complexity. In our case, 
> we saved 10+ Gb of disk space for our reference (background) maps by keeping 
> them in their original format (geotiff and jpeg) instead of converting them 
> into GRASS format. Displaying other formats of data (shapefile, postgis, wms, 
> etc.) is also much more straightforward with qgis.
> So my vote (for what is worth) is for the second solution.
> pc



--------------------
W polskim Internecie s± setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/