Re: [GRASS-dev] CLI!=GUI

[Glynn Clements]

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).

Every optional dependency can be disabled at configure time. At build
time, you can build individual directories. In 7.0, you can control
the target directory (ARCH_DISTDIR) separately from the directory
where previously built components are found (GISBASE).

Packaging involves work, and GRASS is no different to any other
package. E.g. most modern Linux distributions split libraries between
a run-time package containing the shared libraries and a -devel
package containing the headers, static libraries etc. The source tree
from which the package is built doesn't provide explicit support for
this; it's just something the packager has to do.

Moreover, integrating (and subsequently maintaining) the support for
various packaging systems would be significantly more work for the
GRASS developers than it would take for the package maintainers to
maintain their own packaging systems privately. A privately-maintained
system only needs to work to the level of "works for me". Something
intended for inclusion into the source tree has to be more "finished",
which can take more work than creating the original version.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] CLI!=GUI

[Michael Barton]

On Nov 29, 2010, at 5:28 PM,  wrote:

> Date: Tue, 30 Nov 2010 00:26:20 +0100
> From: "Francesco P. Lovergine" 
> Subject: Re: [GRASS-dev] CLI!=GUI
> To: Glynn Clements 
> Cc: "Francesco P. Lovergine" ,
>grass-dev@lists.osgeo.org
> Message-ID: <20101129232620.ga6...@frankie.is-a-geek.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On Mon, Nov 29, 2010 at 10:20:52PM +, Glynn Clements wrote:
>> 
>> Francesco P. Lovergine wrote:
>> 
>>> As said in another mail of mine, it is not a problem brute-splitting GUI
>>> dependencies (e.g. current squeeze release for 6.4 only *suggests*
>>> wxpython dependencies). Moving GUI-related binaries in different
>>> packages is a pain to maintain, but theoretically it can also be done.
>>> 
>>> It remains a brute hack anyway, which is a symptom of
>>> a fundamental design problem: the whole system is theoretically
>>> layered and modular, but in fact it cannot be really componentized
>>> in a *clean* way. Something I find basically disturbing and not
>>> elegant, sorry my purism.
>> 
>> You are really going to have to explain what you are talking about,
>> otherwise I (and possibly others) are going to conclude that you don't
>> have a clue and should just be ignored.
>> 
>> GRASS' structure is about as layered and modular as you can get. If
>> you install it on a system without GUI libraries, the only portions
>> which won't work are those which inherently cannot function without
>> those libraries (i.e. the GUI, digitiser, XDRIVER).
>> 
> 
> 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.

This may work for folks on Linux but is incompatible with the way software is 
installed and used on Mac and Windows. I'm not sure that GRASS will even run on 
Windows without the GUI. Certainly xdrivers will not. 

Michael

> --
> Francesco P. Lovergine

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #1225: Include support for kilometres / metres (re) as unit options, alongside of kilometers/meters (er)

[GRASS GIS]

#1225: Include support for kilometres / metres  (re) as unit options, alongside 
of
kilometers/meters (er)
-+--
 Reporter:  voncasec |   Owner:  grass-...@…  
 Type:  enhancement  |  Status:  new  
 Priority:  trivial  |   Milestone:  6.4.1
Component:  Ps.map   | Version:  unspecified  
 Keywords:  ps.map   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 It would be nice if the ps.map instructions would recognize the metric
 spelling of kilometre / metre alongside of the imperial spelling when
 placing unit labels alongside of the scalebar decorations.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] CLI!=GUI

[Francesco P. Lovergine]

On Mon, Nov 29, 2010 at 10:20:52PM +, Glynn Clements wrote:
> 
> Francesco P. Lovergine wrote:
> 
> > As said in another mail of mine, it is not a problem brute-splitting GUI
> > dependencies (e.g. current squeeze release for 6.4 only *suggests*
> > wxpython dependencies). Moving GUI-related binaries in different
> > packages is a pain to maintain, but theoretically it can also be done. 
> > 
> > It remains a brute hack anyway, which is a symptom of
> > a fundamental design problem: the whole system is theoretically 
> > layered and modular, but in fact it cannot be really componentized
> > in a *clean* way. Something I find basically disturbing and not
> > elegant, sorry my purism. 
> 
> You are really going to have to explain what you are talking about,
> otherwise I (and possibly others) are going to conclude that you don't
> have a clue and should just be ignored.
> 
> GRASS' structure is about as layered and modular as you can get. If
> you install it on a system without GUI libraries, the only portions
> which won't work are those which inherently cannot function without
> those libraries (i.e. the GUI, digitiser, XDRIVER).
> 

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. 

-- 
Francesco P. Lovergine
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] CLI!=GUI

[Glynn Clements]

Francesco P. Lovergine wrote:

> As said in another mail of mine, it is not a problem brute-splitting GUI
> dependencies (e.g. current squeeze release for 6.4 only *suggests*
> wxpython dependencies). Moving GUI-related binaries in different
> packages is a pain to maintain, but theoretically it can also be done. 
> 
> It remains a brute hack anyway, which is a symptom of
> a fundamental design problem: the whole system is theoretically 
> layered and modular, but in fact it cannot be really componentized
> in a *clean* way. Something I find basically disturbing and not
> elegant, sorry my purism. 

You are really going to have to explain what you are talking about,
otherwise I (and possibly others) are going to conclude that you don't
have a clue and should just be ignored.

GRASS' structure is about as layered and modular as you can get. If
you install it on a system without GUI libraries, the only portions
which won't work are those which inherently cannot function without
those libraries (i.e. the GUI, digitiser, XDRIVER).

> And like it or not, there are people that do not use the
> default GUI or a GUI at all.

Like me. The only time I'll run the GUI is if I need to test some
aspect of the GUI. Which is why I have no idea where you're getting
these notions about integration from.

-- 
Glynn Clements 
___
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

[GRASS GIS]

#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):

 The following code works:


 {{{
# Requested by issue #1187
 if {[tk windowingsystem] eq "aqua"} {

 #   # option + left-click for Mac equals middle-click
 bind .screen.canvas  { c_update_tool %x
 %y 2 }
 # right-click is acting like a middle-click...
 bind .screen.canvas  {
 puts "button: %b"
 if { %b == 3 } {
 c_update_tool %x %y 2
 } elseif { %b == 2 } {
 c_update_tool %x %y 3
 } else {
 c_update_tool %x %y %b
 }
 }
 } else {
 bind .screen.canvas  { c_update_tool %x %y %b
 }
 }
 }}}


 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.

 I still get the bind_scroll error, but I don't think it is related. It
 seems to be a different bug. Also polygons don't seem to be closing
 correctly even though drawing ends.

 Finally, it has long been a problem that when I go to register a database
 entry after completing a vector object (point, line, area), it comes up as
 "Cannot update table: DMBI-DBF driver error: SQL parser error: syntax
 error, unexpected WHERE, expecting NAME process in 'where' in statement
 update deleteme set where cat = 1 Error in db_execute_immediate()

 [my test vector file is called "deleteme"]

 Michael

-- 
Ticket URL: 
GRASS GIS 

___
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

[GRASS GIS]

#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):

 Wait a minute. It sort of works. Still raises an error, but now if I do an
 option-left-click, it registers as a right-click. Right-click is
 registering as a middle-click. This is after changing your code to the
 following:


 {{{
 # Requested by issue #1187
 if {[tk windowingsystem] eq "aqua"} {

 # right-click is acting like a middle-click...
 bind .screen.canvas  {
 if { %b == 3 } {
 c_update_tool %x %y 2
 } else {
 c_update_tool %x %y %b
 }
 }
 # option + left-click for Mac equals middle-click
 bind .screen.canvas  { c_update_tool
 %x %y 3 }
 } else {
 bind .screen.canvas  { c_update_tool %x %y %b
 }
 }

 }}}

-- 
Ticket URL: 
GRASS GIS 

___
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

[GRASS GIS]

#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):

 It didn't work. I tried changing a couple things (Option-Button-1 to
 Option-ButtonPress-1, and changing the order of the new key bindings), but
 none of it worked. It also generated errors any time the mouse was moved
 after starting a line or polygon like the following:

 can't read "bind_scroll_list": no such variable
 can't read "bind_scroll_list": no such variable
 while executing
 "lsearch -exact $bind_scroll_list $window"
 (procedure "handle_scroll" line 5)
 invoked from within
 "handle_scroll -1 .screen.canvas"
 (command bound to event)

-- 
Ticket URL: 
GRASS GIS 

___
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

[GRASS GIS]

#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:7 cmbarton]:
 > I looked to see if there was something in the TclTk code that I could
 change to fix this issue. But it looks to me like the key bindings are set
 in the C-code for v.digit. So someone else would need to make changes
 there.

 Bindings in v.digit are tricky: toolbox.tcl just sends mouse click
 together with mouse button code to particlular editing function (see
 c_face.c and centre.c). Every editing function decides what to do on mouse
 click (buttons 1 to 3). Adding more complex bindings (alt+mouse) can be
 tricky (not today for me) as i.e. double-click at first time sends two
 events - single click and double click.

 Michael, please, test attached patch for 6.5.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] CLI!=GUI

[Francesco P. Lovergine]

On Sun, Nov 28, 2010 at 09:29:28PM +, Glynn Clements wrote:
> 
> Hamish wrote:
> 
> > > > If the only available packages (RPM, .deb, etc) insist
> > > > upon installing GUI libraries, complain to the people who
> > > > make the packages.
> > 
> > Paolo:
> > > OK, so, now I'm complaining ;) : packagers, please have
> > > your saying here.
> > 
> > disk space is very cheap. package maintaining time is not. IMHO
> > unused libraries & a couple extra packages do no real harm
> 
> It isn't "a couple". Once you link against wx, you're looking at ~60
> extra libraries.
> 
> I'd suggest that the core GRASS package shouldn't list X, wxWidgets or
> (in 6.x) Python as dependencies.
> 
> It shouldn't be necessary to split the actual GRASS distribution into
> GUI and non-GUI components. Put everything in the non-GUI package, and
> have a separate GUI package which is empty (or contains a single dummy
> file if the packaging system doesn't allow empty packages) and exists
> solely to hold the GUI-specific dependencies.
> 

As said in another mail of mine, it is not a problem brute-splitting GUI
dependencies (e.g. current squeeze release for 6.4 only *suggests*
wxpython dependencies). Moving GUI-related binaries in different
packages is a pain to maintain, but theoretically it can also be done. 

It remains a brute hack anyway, which is a symptom of
a fundamental design problem: the whole system is theoretically 
layered and modular, but in fact it cannot be really componentized
in a *clean* way. Something I find basically disturbing and not
elegant, sorry my purism. 

BTW, I tend to disagree about considering GUI maintainance not influent
in the releasing cycle. It *is* influent and caused many of the
past/present windows/macos delays. Having a sort of grass-toolbox 
and grass-gui sub-projects could help a lot (like CNES does 
with OTB and Monteverdi).

And like it or not, there are people that do not use the
default GUI or a GUI at all. Splitting would gain consensus
about the core, which is IMVHO the true value of GRASS.

Of course, my 2 cents, as always.

-- 
Francesco P. Lovergine
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1222: v.rast.stats returns error: global name 'vector' is not defined

[GRASS GIS]

#1222: v.rast.stats returns error: global name 'vector' is not defined
-+--
  Reporter:  akbgf   |   Owner:  grass-...@…  
  Type:  defect  |  Status:  closed   
  Priority:  normal  |   Milestone:  7.0.0
 Component:  Vector  | Version:  svn-trunk
Resolution:  fixed   |Keywords:  v.rast.stats 
  Platform:  Linux   | Cpu:  x86-32   
-+--
Changes (by akbgf):

  * status:  new => closed
  * version:  unspecified => svn-trunk
  * resolution:  => fixed


Comment:

 r44483 works.

 Great!

 Thank you, Andres Kuusk, Tartu Observatory, Estonia

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev