[GRASS-dev] GRASS and QGIS on Win32, testing etc.

[Tim Sutton]

Hi

Em 21/05/2007, às 13:15, Benjamin Ducke escreveu:

> I think that we can actually make everybody happy here: it should be
> possible to have a set of Win32 binaries that support tcl/tk forms  
> (and
> in the future wxPython) as well as run with current QGIS.
> This way, we can provide several layers of GUI interaction to make the
> transition for GIS newbies smooth:
>
> 1. QGIS with direct loading of file based geodata
> 2. the GRASS Toolbox providing a link to GRASS data and a simplified
> modules interfaces
> 3. auto-generated forms on the command line (be they tcl/tk or  
> wxPython)
> 4. pure command line
> 5. further tcl/tk and wxPython GUI tools for those that prefer them  
> over
>  QGIS and its GRASS plugin stuff
>
> ... and all in a single Windows installer package!
>
> The most important thing is to have a rock-solid set of binaries for
> Win32. And I think we should focus on getting the command line stuff
> with MSYS running perfectly first, then we can add GUI dependencies  
> bit
> by bit. And later get rid of shell dependencies. At any stage in the
> process, there will be a fully usable GRASS on Windows. And everybody
> can decide for themselves whether they want to have a package with
> tcl/tk, wxpython, MSYS, NVIZ etc. or rather go with QGIS and Paraview.
>

Actually this s probably a good time to bring up a broader objective  
that myself and Norman Vine have bandied about on #qgis irc channel  
before today. What we really need is an interproject effort (not  
limited to just QGIS & GRASS) to build msys packages for developers.  
Think 'rpm' or 'deb' (actually probably closer to slackware tarball  
packages) but for msys environement. At the moment we have the rather  
inefficient and non-optimal situation where e.g. QGIS project builds  
gdal, proj , grass etc etc under msys, while in parallel other  
projects do the same thing. Surely it wil be ideal if each project  
puts forward their own msys packages built with best practice for  
that project in mind. This will prevent issues where I (being fairly  
GRASS inept) am building grass for QGIS and resultng in bug reports  
etc because I havent done an optimal job. If anyone has the  
wherewithal to coordinate and host such a project (perhaps even as a  
section under the msys packages list on sf) it would be a fantastic  
contribution.

Best regards

Tim Sutton (QGIS)


> Let's just forget about Cygwin.
>
> Benjamin
>
> Paolo Cavallini wrote:
>>
>>
>> Michael Barton ha scritto:
>>
>>> It is a simple zip file and easy to install. Currently, it  
>>> requires you to
>>> separately install TclTk, and Mysys if you want to use scripts.  
>>> It needs
>>> testing, but is very actively being worked on. This is the  
>>> direction for
>>> GRASS for Windows.
>>
>> Soory: whan you say this, what do you exactly mean? We are using the
>> qgis version, which has of course its limitations, but is very much
>> usable, and far easier for novices.
>> I think diversity is a byproduct of freedom, and we have several  
>> ways at
>> hand.
>> pc
>
> -- 
> Benjamin Ducke, M.A.
> Archäoinformatik
> (Archaeoinformation Science)
> Institut für Ur- und Frühgeschichte
> (Inst. of Prehistoric and Historic Archaeology)
> Christian-Albrechts-Universität zu Kiel
> Johanna-Mestorf-Straße 2-6
> D 24098 Kiel
> Germany
>
> Tel.: ++49 (0)431 880-3378 / -3379
> Fax : ++49 (0)431 880-7300
> www.uni-kiel.de/ufg
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev