Re: [GRASS-dev] CLI!=GUI
MAKE system patches into studio! Be ready to deal also with any code that migh assume GUI-related tools to be present by default. Saving less than 10MB of uncompressed disk space is not worth a large effort. GRASS has so many dependencies, that it's impossible to split-out all tools that require some obscure lib/utility without ruining GRASS as whole. I doubt that Debian now is providing ALL dependencies of ALL GRASS modules - reports about module X requires Y will not go away because of GUI/CLI split. As GRASS lacks manpower - code or GTFO* ;) Maris. * A nice reference to Chatroulette 2010/11/30, Francesco P. Lovergine fran...@debian.org: Something like: make build-core | build-xdriver | build-wxgui | build-tkgui make install-core | install-xdriver | install-wxgui | install-tkgui would be more modular and clean. Of course, one can always now install the whole beast, use only what is of interest and avoid installing all dependencies. As said, it works too. But I - as packager - would prefer avoiding tons of silly reports about 'command X is not working because Y is missing' and installing most required dependencies for all commands provided. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1187: TclTk digitizer does not recognize right-click
#1187: TclTk digitizer does not recognize right-click
-+--
Reporter: cmbarton | Owner: grass-...@…
Type: defect | Status: new
Priority: critical | Milestone: 6.4.1
Component: Tcl/Tk | Version: 6.4.0
Keywords: digitizer, v.digit, right-click |Platform: MacOSX
Cpu: OSX/Intel|
-+--
Comment(by marisn):
Replying to [comment:11 cmbarton]:
I did a puts %b and the mouse is registering correctly in TclTk. The
problem lies in c_update_tool. That is where the buttons are getting
switched.
c_update_tool is not touching button number, it's just passing it as-is to
registered tool update function. Tool decides what kind of action to take
depending on button number 1, 2 or 3. I.e. line.c @210 has defined 1=new
point; 2=Undo; 3=quit.
You can rearrange buttons or keys in any order as long as it results in
sending correct button number to c_update_tool function.
You can test Your TCL/windowing system mouse button order by launching
wish from CLI and executing:
{{{
bind . ButtonPress { puts Plain %b }
}}}
On my GNU/Linux system it gives: 1=left; 2=middle; 3=right.
As I wrote, more complex bindings (i.e. double click) are tricky as we
then have to delay single click event some ms before firing to detect
double/tripple/... click. This was a case for KDE some time a go and got
removed to make UI more responsive, as there are no more few ms delays on
every mouse click.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1187#comment:12
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
On Tue, Nov 30, 2010 at 4:12 AM, Glynn Clements gl...@gclements.plus.com wrote: Francesco P. Lovergine wrote: Something like: make build-core | build-xdriver | build-wxgui | build-tkgui make install-core | install-xdriver | install-wxgui | install-tkgui would be more modular and clean. Of course, one can always now install the whole beast, use only what is of interest and avoid installing all dependencies. As said, it works too. But I - as packager - would prefer avoiding tons of silly reports about 'command X is not working because Y is missing' and installing most required dependencies for all commands provided. You can package it how you want, but I don't think that it's realistic to structure GRASS around individual packagers' policies (e.g. who says what is core and what isn't). Well, I think that Francesco suggestion above is pretty clear. It does not look like too strange to me and sufficiently generic. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1187: TclTk digitizer does not recognize right-click
#1187: TclTk digitizer does not recognize right-click -+-- Reporter: cmbarton | Owner: grass-...@… Type: defect | Status: new Priority: critical | Milestone: 6.4.1 Component: Tcl/Tk | Version: 6.4.0 Keywords: digitizer, v.digit, right-click |Platform: MacOSX Cpu: OSX/Intel| -+-- Comment(by cmbarton): Hmmm. TclTk defines the left button as button 1, the right button as button 2, and the middle button as button 3 for my system. This is how Apple treats mouse buttons, and maybe Windows too (someone needs to check this. So this is where the problem lies. The script does a good job of remapping this but we'll need to add a binding for Control-Button-1 so that it maps to 2 on the Mac. I just was able to check on my laptop and this is not automatically registering as button 2 with the trackpad. The other issues I mentioned remain. Do you know where it is having a problem with .bind_scroll ? -- Ticket URL: http://trac.osgeo.org/grass/ticket/1187#comment:13 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CLI!=GUI
Michael Barton wrote: I'm not sure that GRASS will even run on Windows without the GUI. Certainly xdrivers will not. None of the standalone display drivers (d.mon ...) will run on Windows. d.* commands always behave as if GRASS_RENDER_IMMEDIATE=TRUE, i.e. they will save an image to $GRASS_PNGFILE. Other commands are unaffected. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1225: Include support for kilometres / metres (re) as unit options, alongside of kilometers/meters (er)
#1225: Include support for kilometres / metres (re) as unit options, alongside of kilometers/meters (er) -+-- Reporter: voncasec | Owner: hamish Type: enhancement | Status: assigned Priority: trivial | Milestone: 6.5.0 Component: Ps.map | Version: unspecified Keywords: ps.map |Platform: All Cpu: All | -+-- Changes (by hamish): * status: new = assigned * cc: grass-...@… (added) * platform: Unspecified = All * milestone: 6.4.1 = 6.5.0 * owner: grass-...@… = hamish * cpu: Unspecified = All Comment: taking ownership of this one, but not sure about the best way to resolve it. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1225#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1225: Include support for kilometres / metres (re) as unit options, alongside of kilometers/meters (er)
#1225: Include support for kilometres / metres (re) as unit options, alongside of kilometers/meters (er) -+-- Reporter: voncasec | Owner: hamish Type: enhancement | Status: assigned Priority: trivial | Milestone: 6.5.0 Component: Ps.map | Version: unspecified Keywords: ps.map |Platform: All Cpu: All | -+-- Comment(by hamish): The place that is set is: source:grass/trunk/ps/ps.map/do_scaleba...@#l192 you can edit that file by hand and recompile if you need to. I do not like the idea of making it current-locale setting dependent, or a translated macro as many of us work in/with/for both systems and need to be able to produce for both, from both on demand. Those things being silently adjusted for me drives me batty. It could take a cue from the spelling of UNITS in g.proj -p, but that's rather fragile and not an option for lat/lon locations. I am loathe to add another instruction just for this spelling. ?, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1225#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
