Re: [GRASS-dev] wxGUI toolboxes

[Anna Kratochvílová]

On Thu, May 2, 2013 at 10:11 AM, Sören Gebbert
 wrote:
> Hi Anna,
>
>
> 2013/5/2 Anna Kratochvílová 
>>
>> On Thu, May 2, 2013 at 9:52 AM, Sören Gebbert
>>  wrote:
>> > Hi,
>> > this is really great, many thanks! I am looking forward to add a
>> > temporal
>> > modules menu layout.
>>
>> I was about to suggest adding temporal framework to the toolboxes so
>> that it can be optionally added to menu. Will you try it? The needed
>> information should be in the programming manual. Or I can create the
>> toolbox and you can improve it later. The main work beside creating
>> the structure is to add menu labels.
>
>
> That is nice, i would like to improve it later. :)
>
Sure, try r56081. Copy gui/wxpython/xml/main_menu.xml to
$HOME/.grass7/toolboxes/main_menu.xml
 and add line:



to appropriate place.

Now start gui and you should see it in menu.

I am sure you'll have to adjust the menu (structure, labels), it's in
file gui/wxpython/xml/toolboxes.xml. There are problems how to make
the labels not so long, so I use 'raster dataset' instead of 'space
time raster dataset' and so on. Also I am not sure about naming
raster3D x volume.

Best,

Anna




> Best regards
> Soeren
>>
>>
>> Anna
>>
>> >
>> > Best regards
>> > Soeren
>> >
>> >
>> > 2013/4/30 Vaclav Petras 
>> >>
>> >> Hi all,
>> >>
>> >> first version of toolboxes for wxGUI is released (for GRASS GIS 7) and
>> >> is available in trunk. The main purpose of toolboxes is the wxGUI menu
>> >> customization. The current implementation of toolboxes does not
>> >> influence the set of installed or available modules. The toolboxes are
>> >> the possibility to create different highly specialized menu layouts.
>> >>
>> >> Users, which are able to edit XML, can now create toolboxes which
>> >> contain modules from GRASS distribution, existing toolboxes (from the
>> >> distribution) and modules from addons or their own modules. These
>> >> toolboxes or set of toolboxes (in the toolboxes file) can be copied
>> >> and shared, and users, which are able to copy the file into the
>> >> .grass7 directory, can use them. Note that distribution of toolboxes
>> >> is now not connected to the distribution of modules itself. GUI
>> >> front-end is not available.
>> >>
>> >> The main menu (main menubar) is treated separately in the separate
>> >> file with slightly different structure but its very similar to toolbox
>> >> and it follows the same concepts.
>> >>
>> >> Note that you need to create your custom toolboxes.xml file or
>> >> main_menu.xml file into your $HOME/toolboxes directory to see
>> >> toolboxes in action.
>> >>
>> >> For the detailed description please see Programmer's Manual [1] and
>> >> for future consideration and development issues see Trac [2].
>> >>
>> >> Anna and Vaclav
>> >>
>> >> [1] http://grass.osgeo.org/programming7/wxguitoolboxes.html
>> >> [2] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/Toolboxes
>> >> (links will work soon)
>> >> ___
>> >> grass-dev mailing list
>> >> grass-dev@lists.osgeo.org
>> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> >
>> >
>> >
>> > ___
>> > grass-dev mailing list
>> > grass-dev@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1554: wxGUI Cartographic Composer: preview broken on Windows

[Anna Kratochvílová]

On Thu, May 2, 2013 at 8:29 AM, SWAPAN GHOSH  wrote:
> Hi all,
>
> It needs to change the code for "EpsImagePlugin.py" in the Python PIL
> packages as below-
>
> command = ["gswin32c",
>"-q",# quite mode
>"-g%dx%d" % size,# set output geometry (pixels)
>"-dNOPAUSE -dSAFER", # don't pause between pages, safe
> mode
>"-sDEVICE=ppmraw",   # ppm driver
>"-sOutputFile=%s" % file # output file
>   ]
>
> Then It will work in windows.
>
> Regards,
>

Thanks, it was already fixed. The problem was indeed the command.
There are more bugs discussed in the ticket, so the status can be
unclear.

Anna

> Swapan
>
>
>
> On Sun, Apr 28, 2013 at 6:53 PM, GRASS GIS  wrote:
>>
>> #1554: wxGUI Cartographic Composer: preview broken on Windows
>>
>> +---
>>  Reporter:  martinl |   Owner:
>> grass-dev@…
>>  Type:  defect  |  Status:  new
>>  Priority:  critical|   Milestone:  6.4.3
>> Component:  wxGUI   | Version:
>> unspecified
>>  Keywords:  cartographic composer, psmap, wingrass  |Platform:
>> MSWindows XP
>>   Cpu:  Unspecified |
>>
>> +---
>>
>> Comment(by annakrat):
>>
>>  Replying to [comment:40 martinl]:
>>  > Replying to [comment:38 annakrat]:
>>  >
>>  > > > Quick test: `ps2pdf` works from cmd, cartographic composer fails
>>  with `Cannot open this file: _.at`
>>  > >
>>  > > and it complains about missing gssetgs.bat (in terminal)
>>  >
>>  > added to `gs` package (9.07-3)
>>
>>  still not working, some 'unrecoverable error' shows in the terminal
>>
>> --
>> Ticket URL: 
>> GRASS GIS 
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 6.4.3 release planning

[Anna Kratochvílová]

On Wed, May 1, 2013 at 2:20 PM, Markus Neteler  wrote:
> Hi,
>
> since RC3 was published some days ago and since there are no more blockers:
>
> http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0
>
> ... we should get GRASS GIS 6.4.3 final out of the doors.
>
> What's missing, any objections? Remember that 6.4.4 can follow then.
>

Sorry for delaying, there is a pretty high chance to make cartographic
composer (PDF export) working [1]. Tomorrow it will be clear.

Anna

[1] https://trac.osgeo.org/grass/ticket/1554#comment:43


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

Re: [GRASS-dev] wxGUI toolboxes

[Anna Kratochvílová]

On Thu, May 2, 2013 at 9:52 AM, Sören Gebbert
 wrote:
> Hi,
> this is really great, many thanks! I am looking forward to add a temporal
> modules menu layout.

I was about to suggest adding temporal framework to the toolboxes so
that it can be optionally added to menu. Will you try it? The needed
information should be in the programming manual. Or I can create the
toolbox and you can improve it later. The main work beside creating
the structure is to add menu labels.

Anna

>
> Best regards
> Soeren
>
>
> 2013/4/30 Vaclav Petras 
>>
>> Hi all,
>>
>> first version of toolboxes for wxGUI is released (for GRASS GIS 7) and
>> is available in trunk. The main purpose of toolboxes is the wxGUI menu
>> customization. The current implementation of toolboxes does not
>> influence the set of installed or available modules. The toolboxes are
>> the possibility to create different highly specialized menu layouts.
>>
>> Users, which are able to edit XML, can now create toolboxes which
>> contain modules from GRASS distribution, existing toolboxes (from the
>> distribution) and modules from addons or their own modules. These
>> toolboxes or set of toolboxes (in the toolboxes file) can be copied
>> and shared, and users, which are able to copy the file into the
>> .grass7 directory, can use them. Note that distribution of toolboxes
>> is now not connected to the distribution of modules itself. GUI
>> front-end is not available.
>>
>> The main menu (main menubar) is treated separately in the separate
>> file with slightly different structure but its very similar to toolbox
>> and it follows the same concepts.
>>
>> Note that you need to create your custom toolboxes.xml file or
>> main_menu.xml file into your $HOME/toolboxes directory to see
>> toolboxes in action.
>>
>> For the detailed description please see Programmer's Manual [1] and
>> for future consideration and development issues see Trac [2].
>>
>> Anna and Vaclav
>>
>> [1] http://grass.osgeo.org/programming7/wxguitoolboxes.html
>> [2] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/Toolboxes
>> (links will work soon)
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Can't add vector label and point file in cartiographic composer

[Anna Kratochvílová]

Hi,

On Tue, Apr 23, 2013 at 1:02 PM, SWAPAN GHOSH  wrote:
> Thank you very much Anna. Please add the label to carteographic composer as
> soon as possible.
>

I just added labels support to Cartographic composer in grass 7 (Add
overlays -> Add labels)

Anna

> Thanks,
>
> Swapan
>
>
> On Tue, Apr 23, 2013 at 2:10 AM, Anna Kratochvílová 
> wrote:
>>
>> On Sat, Apr 20, 2013 at 10:28 AM, SWAPAN GHOSH 
>> wrote:
>> > Hi all,
>> >
>> > I Can't add vector label and point file in cartiographic composer. But
>> > this
>> > is very much necessary in my project. I use grass6.5.
>>
>> Please see my recent answer [1] related to vector labels. With point
>> file you mean vector map with points? Add vector map layer -> select
>> map and choose data type points -> click button add -> optionally
>> click on properties to set the appearance of the vector map.
>>
>> Anna
>>
>> [1] http://lists.osgeo.org/pipermail/grass-user/2013-April/067902.html
>>
>>
>> >
>> > Please give me a solution.
>> >
>> > Thanks & Rgards,
>> >
>> > Swapan Ghosh
>> >
>> > ___
>> > grass-dev mailing list
>> > grass-dev@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI adding menu file with our Addons

[Anna Kratochvílová]

Hi Yann,

actually, we just started working on this, so we will let you know
about the progress.

Anna and Vaclav

On Tue, Apr 23, 2013 at 12:17 PM, Yann Chemin  wrote:
> Upon compiling addons, it would be nice to have another file
> (menuaddons.xml in grass70/gui/wxpython/xml/) that could be loaded
> additionally to menudata.xml, or directly into it by some python
> import magic.
>
> here is an example of few modules:
> 
>   &Addons
>   
> 
>   ET Senay (2001)
>   Computes ET after Senay (2001)
>   imagery,evapotranspiration,Senay
>   OnMenuCmd
>   i.evapo.senay
> 
> 
> 
>   ET Biome (2011)
>   Computes Biome based ET (Global model)
>   OnMenuCmd
>   i.evapo.senay
> 
>   
> 
>
> If loaded properly into the menu on compilation time it would appear
> as an "Addon" extra menu. before the "Help" menu.
>
> I realize this idea comes from the compiling side of G7, but it can be
> extended to g.extension etc... by asking teh menu bar to reload once
> in a while any new menuaddons*.xml file available.
>
>
> --
> Yann Chemin
> Researcher@IWMI
> Skype/FB: yann.chemin
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Can't add vector label and point file in cartiographic composer

[Anna Kratochvílová]

On Sat, Apr 20, 2013 at 10:28 AM, SWAPAN GHOSH  wrote:
> Hi all,
>
> I Can't add vector label and point file in cartiographic composer. But this
> is very much necessary in my project. I use grass6.5.

Please see my recent answer [1] related to vector labels. With point
file you mean vector map with points? Add vector map layer -> select
map and choose data type points -> click button add -> optionally
click on properties to set the appearance of the vector map.

Anna

[1] http://lists.osgeo.org/pipermail/grass-user/2013-April/067902.html


>
> Please give me a solution.
>
> Thanks & Rgards,
>
> Swapan Ghosh
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error in v.proj - wxpython

[Anna Kratochvílová]

On Mon, Apr 22, 2013 at 4:52 PM, Margherita Di Leo
 wrote:
> Hi,
>
> using v.proj I get the following errors:
>
> Traceback (most recent call last):
>   File
> "/space/gis/grass64_release/grass-6.4.3svn/etc/wxpython/gui_core/goutput.py",
> line 731, in OnCmdOutput
> if self.linepos < 0:
> AttributeError: 'GMConsole' object has no attribute 'linepos'
> Traceback (most recent call last):
>   File
> "/space/gis/grass64_release/grass-6.4.3svn/etc/wxpython/gui_core/goutput.py",
> line 731, in OnCmdOutput
> if self.linepos < 0:
> AttributeError: 'GMConsole' object has no attribute 'linepos'
> Traceback (most recent call last):
>   File
> "/space/gis/grass64_release/grass-6.4.3svn/etc/wxpython/gui_core/goutput.py",
> line 731, in OnCmdOutput
> if self.linepos < 0:
> AttributeError: 'GMConsole' object has no attribute 'linepos'
>
> Eventually the map is reprojected anyway.
> GRASS 6.4.3 svn , not the freshest one: Revision: 50937 on red hat.
>

Should be fixed in r55946, thanks for reporting.

Anna


> Thanks.
>
> --
> Best regards,
>
> Margherita DI LEO
> Postdoctoral Researcher
>
> European Commission - DG JRC
> Institute for Environment and Sustainability (IES)
> Via Fermi, 2749
> I-21027 Ispra (VA) - Italy - TP 261
>
> Tel. +39 0332 78 3600
> margherita.di-...@jrc.ec.europa.eu
>
> Disclaimer: The views expressed are purely those of the writer and may not
> in any circumstance be regarded as stating an official position of the
> European Commission.
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7: d.vect needs a dedicated GUI

[Anna Kratochvílová]

On Thu, Apr 4, 2013 at 6:08 PM, Markus Neteler  wrote:
> (deriving this from " Re: [GRASS-dev] could r.stream.* become part of
> GRASS core?"
>
> On Thu, Apr 4, 2013 at 10:47 AM, Hamish  wrote:
> ...
>> Very much straying offtopic now, I'd also advocate a series of
>> wrapper scripts to run from GUI buttons for simple-mode d.vect.
>> (see also my d.* helper/wrapper scripts in g6 addons like d.varea,
>> d.stations, and d.mark)  I feel the current d.vect GUI window
>> is a bit overwhelming, but that's no reason to break up the base
>> module, since wrapper scripts can handle the "simple views",
>> and the full d.vect module gui could be there for "advanced"
>> mode.
>
> I fully agree. Just today I tried the current wxGUI d.vect dialog window
> (usually I use cmd line) and found it hard to find things since they
> are in different tabs while belonging together.

So is it possible to improve first the d.vect dialog?

And what should the custom gui look like? It should probably provide
all the options but better organized (e.g. symbology containing
symbols, colors, lines...) and some less important features should be
hidden (collapsible pane).

Should there be also a dedicated gui for d.rast? I don't like the
possible inconsistency here.

Anna

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

Re: [GRASS-dev] wxGUI HTML manual: images not shown

[Anna Kratochvílová]

On Tue, Mar 26, 2013 at 7:58 PM, Markus Neteler  wrote:
> Hi,
>
> this was already reported long ago but I don't remember the outcome:
> Neither G7 nor G6.4 the manual is rendered with embedded pictures
> in the wxGUI manual browser (see attachment).
>
> Does anyone have an idea how to get this working? (I know that it is a
> somewhat limited "browser" but the manual images are important).

This is due to missing quotes in img tag:



I fixed this in GRASS 7 (r55528). I didn't check if it is easy or not
to backport it.

Anna

>
> Note that the GRASS logo on top is rendered!
>
> Markus
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI spin control for floating point ???

[Anna Kratochvílová]

On Thu, Mar 21, 2013 at 9:15 PM, Markus Metz
 wrote:
> On Thu, Mar 21, 2013 at 8:53 PM, Anna Kratochvílová
>  wrote:
>> On Thu, Mar 21, 2013 at 1:11 PM, Martin Landa  wrote:
>>> Hi,
>>>
>>> 2013/3/21 Markus Metz :
>>>> What is the reason to have a spin control for floating point values?
>>>> Could the spin control at least not use the number but the significant
>>>> digits (same like printing with %g) for spinning? E.g. for 0.0001
>>>> I see 0.000 which is wrong. IMHO the spin control should be reverted
>>>> to text input.
>>>
>>> sometimes float spin controls are useful sometimes not. Useful eg.
>>> `d.vect size`, but not for the case you mentioned. Probably we could
>>> stay with floating spin control (some improvements required)  rather
>>> than plain text input. No strong opinion here.
>>>
>>
>> Because we don't know the meaningful number of digits, I agree to use
>> text input. Changing the float spin might be too much work and I think
>> it is not worth it. I have changed it in r55484.
>
> Thanks! That means we can change the r.terraflow default for d8cut
> back to infinity which is a valid number (#1888)?


Hm, not sure about that, there is a validator in the textCtrl to check
for float values...
[testing]

Ok, if you use 'inf' as a default answer it should work because
float('inf') is a valid expression in Python.
But there was 'infinity', so if you insist on 'infinity', some
conversion must be done in forms.py before setting the value.

Anna

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

Re: [GRASS-dev] wxGUI spin control for floating point ???

[Anna Kratochvílová]

On Thu, Mar 21, 2013 at 1:11 PM, Martin Landa  wrote:
> Hi,
>
> 2013/3/21 Markus Metz :
>> What is the reason to have a spin control for floating point values?
>> Could the spin control at least not use the number but the significant
>> digits (same like printing with %g) for spinning? E.g. for 0.0001
>> I see 0.000 which is wrong. IMHO the spin control should be reverted
>> to text input.
>
> sometimes float spin controls are useful sometimes not. Useful eg.
> `d.vect size`, but not for the case you mentioned. Probably we could
> stay with floating spin control (some improvements required)  rather
> than plain text input. No strong opinion here.
>

Because we don't know the meaningful number of digits, I agree to use
text input. Changing the float spin might be too much work and I think
it is not worth it. I have changed it in r55484.

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

Re: [GRASS-dev] RE : [GRASS-user] minimal wxPython version

[Anna Kratochvílová]

On Wed, Mar 20, 2013 at 5:40 PM, Robert Lagacé
 wrote:
> Some information :
>
> Python 2.5 first release 2006, last release 2.5.6 May 26, 2011 - No more fix 
> or update
>
> Python 2.6 first release oct. 2008, last release 2.6.6 April 10, 2012 
> security and bug fix until october 2013
>- features : prepare migration to Pyton 3.0+
>
> Python 2.7 first relaese July 3, 2010, last release 2.7.3 April 9, 2012
>- features : inclusion of 3.1 features
>
> wxPython 2.8.12 - April 2011 - available for Python 2.7 , 2.6 (first version 
> 2.8.0 Dec 12, 2006 - Python version ??)
>
> wxPython 2.8.10 - May 2009 - available for Python 2.6,  2.5, 2.4
>
> wxPython 2.8.8 - June 2008 - available for Python 2.5, 2.4, 2.3
>
> wxPython 2.6.4 - June 2007 -  available for Python 2.5, 2.4, 2.3  (first 
> verion 2.6.0 April 27, 2005 - Python version 2.4, 2.3)
>
> In preparation for migration to Python 3 (in some future), tools existe for 
> migrating from 2.6 and 2.7 but none from 2.5.
>See : http://python3porting.com/
>
> As previously mentionned, wxPython is not available for Python 3.+ but in 
> some future.
>
> So, requiring Python 2.6 for programming is the minimum. This will facilitate 
> the futur porting work.
> For users, we make a recommandation for Python 2.6+ with a note that it may 
> work for version < 2.6 but without guaranty.
> Consequently, wxPython 2.8.10 is required
>
> For GRASS 7, wxPython 2.8.12 should be required.

Thanks for the nice summary. wxPython 2.8.10 is probably still used so
I would leave this as required version. We can reconsider it again (in
a year or so).

Anna

>
> Robert Lagacé
>
> ____
> De : grass-dev-boun...@lists.osgeo.org [grass-dev-boun...@lists.osgeo.org] de 
> la part de Anna Kratochvílová [kratocha...@gmail.com]
> Date d'envoi : 20 mars 2013 11:26
> À : Pietro
> Cc : grass-user grass-user; Michael Barton; GRASS developers list
> Objet : Re: [GRASS-dev] [GRASS-user] minimal wxPython version
>
> Minimum wxPython version is changed in r55466 (I hope I haven't missed
> any other places).
>
> On Wed, Mar 20, 2013 at 1:31 PM, Pietro  wrote:
>> On Wed, Mar 20, 2013 at 12:02 PM, Newcomb, Doug  wrote:
>>> By at least, do you mean looking at 2.6, 2.7 or 3.0 as well?
>>
>> +1 for python 2.6 that it is the default version in debian stable [0]...
>>
>>
>> Moreover, the Python 2.6 [1] added compatibility functions in a
>> future_builtins module and a -3 switch to warn about usages that will
>> become unsupported in 3.0...
>> Therefore if we require python2.6, we can start to think about
>> cleaning the python code and start to use the "future_builtins"
>> modules.
>
> Yes, python3 is probably inevitable so we should prepare for it.
>
>>
>> Concerning GRASS and python 3.X, I think that the biggest problem is
>> the WxPython, at the moment only the develop version Phoneix[2] it is
>> working with python 3.
>
> I think a lot of other projects are in the same situation so I hope
> Phoenix will become more stable soon. It will take some time to update
> wxGUI to work with it but in theory there shouldn't be any major
> problems. A lot of small problems will appear, often because some
> parts of the gui code is a mess (usually some gui layout parts) and
> the newer wxPython doesn't accept it.
>
>
> So any other opinions on Python version?
>
> Anna
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] minimal wxPython version

[Anna Kratochvílová]

Minimum wxPython version is changed in r55466 (I hope I haven't missed
any other places).

On Wed, Mar 20, 2013 at 1:31 PM, Pietro  wrote:
> On Wed, Mar 20, 2013 at 12:02 PM, Newcomb, Doug  wrote:
>> By at least, do you mean looking at 2.6, 2.7 or 3.0 as well?
>
> +1 for python 2.6 that it is the default version in debian stable [0]...
>
>
> Moreover, the Python 2.6 [1] added compatibility functions in a
> future_builtins module and a -3 switch to warn about usages that will
> become unsupported in 3.0...
> Therefore if we require python2.6, we can start to think about
> cleaning the python code and start to use the "future_builtins"
> modules.

Yes, python3 is probably inevitable so we should prepare for it.

>
> Concerning GRASS and python 3.X, I think that the biggest problem is
> the WxPython, at the moment only the develop version Phoneix[2] it is
> working with python 3.

I think a lot of other projects are in the same situation so I hope
Phoenix will become more stable soon. It will take some time to update
wxGUI to work with it but in theory there shouldn't be any major
problems. A lot of small problems will appear, often because some
parts of the gui code is a mess (usually some gui layout parts) and
the newer wxPython doesn't accept it.


So any other opinions on Python version?

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

[GRASS-dev] minimal wxPython version

[Anna Kratochvílová]

Hi all,

I would like to change minimal required version of wxPython [1].
Currently we support (theoretically) version 2.8.1.1 (released 2007).
I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was
shipped with Ubuntu 10.04 LTS. The reason is obvious: wxGUI is limited
by this requirement. Even the 2.8.10.1 version is pretty old so I
think this won't hurt anybody. Any objections?

[1] http://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html


PS - There is a similar problem with Python version (required 2.4).
Some interesting features start with 2.5 but usually we can live
without it. Any opinions?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] formatting expressions for r.mapcalc in GRASS6.4.3

[Anna Kratochvílová]

On Fri, Mar 15, 2013 at 6:17 PM, Glynn Clements
 wrote:
>
> Helmut Kudrnovsky wrote:
>
>> - working:
>>
>> r.mapcalc
>> ndvi3=float(lsat7_2002_40-lsat7_2002_30)/float(lsat7_2002_40+lsat7_2002_30)
>> (Fri Feb 15 16:23:42 2013) Command finished (0 sec)
>>
>> r.mapcalc urban1_30m=if(landuse96_28m==1,1,0)+if(landuse96_28m==2,2,0)
>> (Fri Feb 15 16:24:24 2013) Command finished (0 sec)
>>
>> - not working (as Anna mentioned caused by ||):
>>
>> r.mapcalc urban2_30m=if(landuse96_28m==1 ||
>> landuse96_28m==2,landuse96_28m,null()
>> r.mapcalc MASK=if((elevation<100 && elevation>60) && (landuse96_28m==1 ||
>> landuse96_28m==2),1,null())
>
> Why do you think that the problem is caused by || rather than the
> spaces?


I've noticed it multiple times that pipe character is causing
problems. For example, running command

v.db.select map=... vs=|

from auto-generated dialog is giving error (something like bad syntax)
on Windows. In most cases you don't have any problems because you
don't explicitly use the option fs/separator (usually we use default)
in the command.

Anna

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

Re: [GRASS-dev] GRASS 7 wish: Keyword index

[Anna Kratochvílová]

On Tue, Mar 12, 2013 at 8:49 PM, Markus Neteler  wrote:
> On Tue, Mar 12, 2013 at 8:34 PM, Vaclav Petras  wrote:
>> On 12 March 2013 19:45, Markus Neteler  wrote:
>>> On Tue, Mar 12, 2013 at 6:58 PM, Vaclav Petras  wrote:
 Thinking about the style of keywords.html page, I discovered that the
 h2 and h3 have the same font-size in CSS [1]. Is it an intention?
>>>
>>> I darkly remember that a font smaller than "medium" (used for h4) seems
>>> to be too small, so h3 and h4 were made the same.
>>> Suggestions are welcome.
>>>
>> Hm, for me after deleting font-size setting the page looks good. h2 is
>> bigger than now, h3 is the same as h2 and h3 now. h2 on module page
>> are uppercased, so they may look bit more important by itself. This
>> was maybe the reason for setting the same sizes. I tried to set sizes
>> and get the same result (same sizes). I'm not satisfied but I don't
>> know what to do.
>
> @all:
> For fun I have deleted the size definitions on the server. You can
> reload the manual to see the effect as suggested by Vaclav.
>
> Next Saturday it will be overwritten unless changes are committed
> to SVN.
>
 And about the style itself. I would suggest to use description (dl)
 instead of bullet list. The change in code is small but I don't want
 to do it without asking others.
>>>
>>> Can you give an example of improvement?
>>>
>> It would be the same as the Flags section at module page (the flag
>> description is ). It would be cleaner than the current state -- no
>> bullets, no double colons. The keyword would be bold () on separate
>> line and the list of modules would be on the other line.
>
> Sounds good to me.

Done in r55341. Feel free to revert or change.

>
> Perhaps, to not mess up the other pages, have some special
> keywords style? Could also go into the page header itself.

Probably no special style is needed.

Anna

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

Re: [GRASS-dev] what reference for i.segment ?

[Anna Kratochvílová]

On Tue, Mar 12, 2013 at 5:39 PM, Markus Neteler  wrote:
> On Tue, Mar 12, 2013 at 12:42 PM, Nikos Alexandris
>  wrote:
>> On Tuesday 12 of March 2013 16:38:17 Yann Chemin wrote:
>>> Hi all,
>>> I am making a poster and would like to give a reference to i.segment module.
>>>
>>> Is there anything written I can use for it?
>>
>>
>> I am also interested in a "correct" reference. Informing someone about it, I
>> wrote to him the following:
> ...
>
> I would certainly include the author(s) and year to make it a complete 
> citation.
> And mention GRASS GIS as well.
>
> Maybe something like this ?
>
> Momsen, E., Metz, M. 2012: i.segment. Addon for Geographic Resources
> Analysis Support System (GRASS GIS) Software, Version 7.
> http://grass.osgeo.org
>
> I agree with Moritz that we should have a "suggested citation" section in each
> manual page.

just reminding that there is already a wiki page for this [1].
Probably there should be some universal citation which can be used for
any module. It would be nice to have the citation generated
automatically in the manual page, but the authors are not listed in a
standardized way.

Anna

[1] http://grasswiki.osgeo.org/wiki/GRASS_Citation_Repository

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

[GRASS-dev] wxNviz rendering order problem

[Anna Kratochvílová]

Hi,

I have recently noticed strange behavior of wxNviz, for example vector
layer is always visible even if I use negative z coordinate and it
should be hidden below a surface. Probably, it is connected to newer
wxPython version I started to use recently (2.8.12, so it's actually
not new at all). According to the discussion [1], I tried these lines:

Index: nviz/mapwindow.py
===
--- nviz/mapwindow.py   (revision 55276)
+++ nviz/mapwindow.py   (working copy)
@@ -72,8 +72,10 @@
 def __init__(self, parent, id = wx.ID_ANY,
  Map = None, tree = None, lmgr = None):
 self.parent = parent # MapFrame
-glcanvas.GLCanvas.__init__(self, parent, id)
+from wx.glcanvas import WX_GL_DEPTH_SIZE
+attribs=[WX_GL_DEPTH_SIZE,16,0]
+glcanvas.GLCanvas.__init__(self, parent, id, attribList=attribs)
 MapWindow.__init__(self, parent, id,
Map, tree, lmgr)

which solved the problem. So, I would like to know if someone noticed
this problem on other platforms than Linux. It's not clear to me if
these lines are harmless or not for other platforms and if the number
of the WX_GL_DEPTH_SIZE (= 16) can be used safely (probably different
number works on different computers, see also [2]).

Thanks for any info,
Anna


[1] 
http://wxpython-users.1045709.n5.nabble.com/OpenGL-depth-buffer-deosn-t-seem-to-work-in-wx-glcanvas-td5714984.html#a5714991
[2] 
http://stackoverflow.com/questions/14715739/how-can-i-determine-the-max-allowable-wx-gl-depth-size-for-a-wx-glcanvas
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1888: r.terraflow won't run

[Anna Kratochvílová]

On Tue, Feb 19, 2013 at 1:14 PM, Martin Landa  wrote:
> Hi,
>
> 2013/2/19 Martin Landa :
>
> [...]
>
>> not a number then use TextCtrl instead of FloatSpin. Or to change
>> default answer in r.terraflow to a number.
>
> or probably in the best case to remove default answer, eg.
>
> d8cut   Routing using SFD (D8) direction
>   If flow accumulation is larger than this value it is
> routed using SFD (D8) direction (meaningfull only  for MFD flow). *If
> not give, the use infinity.*
>

I agree with this solution.

Anna

> Martin
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Additional switch(es) for ?

[Anna Kratochvílová]

On Tue, Feb 19, 2013 at 1:07 PM, Markus Metz
 wrote:
> On Tue, Feb 19, 2013 at 11:25 AM, Markus Neteler  wrote:
>> On Mon, Feb 18, 2013 at 11:03 PM, Markus Metz
>>  wrote:
>>> On Mon, Feb 18, 2013 at 10:39 PM, Vaclav Petras  
>>> wrote:
 On 18 February 2013 20:08, Markus Metz  
 wrote:
> On Mon, Feb 18, 2013 at 6:51 PM, Vaclav Petras  
> wrote:
>> ...
> Since the -s flag does not add new functionality to g.mapsets, I would
> strongly opt to remove the -s flag.

> If you want to use the customized gui interface for
> r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc, use the gui
> menu.
> Otherwise, you can use the command line.
>>
>> This makes perfect sense: i.e. g.mapsets fired up from cmd line
>> without anything pops up the nice related g.mapsets gui window.
>>
 But still there are some power users which would like to avoid
 starting the main big GUI. Personally, I like the idea of accessing
 anything in the gui from command line (one reason is that it helps to
 reduce dependencies in the gui code).

 One solution would be run gui for modules such as r.in.gdal by some
 gui starter command which would accept the module name as a parameter;
 it is something like command line menu (g.gui.climenu). This was
 proposed for the g.gui.* in order to avoid having many new modules or
 to avoid the new kind of modules.
>>
>> +1
>
> I don't think you need another gui starter command. What the parser is
> doing right now is sufficient. The parser calls
> gui/wxpython/gui_core/forms.py which in turn brings up the appropriate
> interface. The only modification that is needed is make forms.py bring
> up the customized interface. This solution would not require a special
> flag and no special gui starter command. You would then fire up a
> module from the command line without arguments and get the same
> interface like when calling it from the gui menu.

In some cases, the auto-generated form is also useful, for example the
gui interface for r.colors is created specifically for defining rules,
however for setting ready color table the generated form is more
suitable. So can we keep somehow the option to launch the generated
form (e.g. --ui)?

Anna

>
> Markus M
>
>>
>> ...
>>> I am not sure if this needs emphasizing, but the customized GUI
>>> interfaces already exist. The idea here is to call the already
>>> existing customized interface for a given module, e.g.
>>> r.in.gdal/v.in.ogr/r.colors/v.clean/i.group/g.mapsets etc. No funny
>>> flag needed in the module.
>>
>> Much agreed :)
>>
>> markusN
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1888: r.terraflow won't run

[Anna Kratochvílová]

On Tue, Feb 19, 2013 at 12:56 PM, Paulo van Breugel
 wrote:
> Hi Anna,
>
> I am not sure what you mean with 'special case'? The error message appears
> when I try to open the r.terraflow gui, i.e., before I can set any value.

With the special case I mean the default value 'infinity' when the
option is defined as TYPE_DOUBLE

>
> Just to add, it works for me in GRASS 6.4 (running it right now), so I would
> assume it has something to do how this is implemented in GRASS 7.0?

The difference is that in 6.4 we use TextCtrl in dialogs for float
values, but in 7 it was changed to use FloatSpin control (see for
example d.vect symbol size option). So text 'infinity' is completely
ok for TextCtrl but not for a control expecting numbers.
I don't know, maybe we should go back and use the TextCtrl widget?

>
> Cheers,
>
> Paulo
>
>
> On Tue, Feb 19, 2013 at 12:39 PM, GRASS GIS  wrote:
>>
>> #1888: r.terraflow won't run
>>
>> +---
>>  Reporter:  pvanbosgeo  |   Owner:  grass-dev@…
>>  Type:  defect  |  Status:  new
>>  Priority:  normal  |   Milestone:  7.0.0
>> Component:  wxGUI   | Version:  svn-trunk
>>  Keywords:  r.terraflow, forms  |Platform:  Unspecified
>>   Cpu:  Unspecified |
>>
>> +---
>>
>> Comment(by annakrat):
>>
>>  The problem is that r.terraflow option ''d8cut'' has default value
>>  'infinity'. The gui expects float and not string. Inside r.terraflow
>>  answer infinity means
>>
>>  {{{
>>  static const flowaccumulation_type MAX_ACCU = 1e+15;
>>  }}}
>>
>>  I am not sure how to handle this special case. We can test 'infinity'
>>  string and set maximum value of the Float Spin instead (which is
>> currently
>>  1e9, but it can be increased).
>>
>>  Anna
>>
>> --
>> Ticket URL: 
>> GRASS GIS 
>>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] question about new query

[Anna Kratochvílová]

Hi Michael,

I cc'd grass-dev,

On Tue, Feb 19, 2013 at 4:11 AM, Michael Barton  wrote:
> Anna,
>
> In the new query tool, it seems like it is no longer possible to edit the
> vector object queried. Is there another way to do this?
>
> Michael

the previous system allows to change attributes by querying which is
in my opinion wrong behavior (#1608).  Currently, you can change the
attributes in the attribute manager and in the digitizer. I agree that
it is less convenient than before. So the query dialog could on
request display Attribute Manager with dialog for editing record or
DisplayAttributesDialog?

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

Re: [GRASS-dev] Additional switch(es) for ?

[Anna Kratochvílová]

Hi all,

On Sun, Feb 17, 2013 at 1:56 AM, Hamish  wrote:
>> > Or, add an optional switch "-s" or
>
> fwiw there is already a "-s" switch to launch the selection GUI,

I didn't know about this option. From the layer manager menu you can
launch the same dialog. The problem is that the code is duplicated (in
wxpython/gui_core/preferences.py and
general/g.mapsets/g.mapsets_picker.py). There are some differences but
I think there is no reason for that. Also, this g.mapsets -s is not
really consistent with the new g.gui.modules. What about
g.gui.mapsets? Or if we want to keep the flag -s, the code should be
at least on one place.

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

Re: [GRASS-dev] [GRASS-user] NViz - problem in the visualization of 3D objects

[Anna Kratochvílová]

On Thu, Feb 14, 2013 at 6:30 PM, Carla Rebelo  wrote:
> Hi,
>
> I have footprint buildings and the height value (type double
> precision) of each footprint.
>
> v.info -t map=buildings@
> nodes=250
> points=0
> lines=0
> boundaries=243
> centroids=88
> areas=89
> islands=8
> faces=0
> kernels=0
> primitives=331
> map3d=1
>
> After the v.extrude step "v.extrude --overwrite --verbose
> input=buldings@ output=buildings3D hcolumn=Height type=area
>
> v.info -t map=buildings3D@
> nodes=646
> points=0
> lines=0
> boundaries=0
> centroids=0
> areas=0
> islands=0
> faces=743
> kernels=88
> primitives=831
> map3d=1
>
> When I visualized the file 3D from NViz, I have seen some of the
> buildings with a black filling (it's black inside or the top of
> building is black) 
>
> Is it a problem of rendering? Or a problem with the topology?

Some of the buildings look ok? I've just tried a small example and it
works for me .

There could be a problem with the normal vectors of the faces.
Unfortunately I don't know much about the topology of kernels.

Regards,
Anna

>
> Best regards,
> CR
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] formatting expressions for r.mapcalc in GRASS6.4.3

[Anna Kratochvílová]

On Thu, Feb 14, 2013 at 5:41 PM, Helena Mitasova  wrote:
>
>
>> The wxGUI command line has its own rules (see shlex.split()
>> in the Python library documentation).
>
> running mapcalc through the wxGUI command line is where the students have 
> problems in winGRASS
> (but it works on Mac)
>
> Helmut - can you please try this commands with data in nc_spm_08
> just pasting them in command console in wingrass?
> - I had them originally in double quotes but that did not work for any 
> expression,
> without quotes this works:
>
> g.region rast=landuse96_28m -p
> r.mapcalc 
> ndvi3=float(lsat7_2002_40-lsat7_2002_30)/float(lsat7_2002_40+lsat7_2002_30)
>
> but the students complain that the ones with if statements don't
> (they say that they tried to put spaces around = and some other modifications 
> but they keep getting syntax error):
>
> r.mapcalc urban1_30m=if(landuse96_28m==1,1,0)+if(landuse96_28m==2,2,0)
> r.mapcalc urban2_30m=if(landuse96_28m==1 || 
> landuse96_28m==2,landuse96_28m,null()
> g.region rast=elevation -p
> r.mapcalc MASK=if((elevation<100 && elevation>60) && (landuse96_28m==1 || 
> landuse96_28m==2),1,null())

One problem is caused by the pipe character. It seems that it is taken
as the end of a command and the rest is evaluated as another command.
I noticed the same problem when I wanted to execute a command
(run_command) with option separator = "|" from gui. It's a general
problem both in grass 6 and 7.

Anna

>
> so I am trying to figure out how to make r.mapcalc work in wingrass in 
> command console
> (all of these expressions work if entered through the map calculator GUI)
>
> r.mapcalc is one of the most used commands so I think it is important to have 
> it running reliably
> and it may be just a matter of special instrcutions for wingrass in the 
> manual page,
>
> Thank you, Helena
>
>>
>> Map names can be quoted with either single or double quotes, so if the
>> expression is quoted with double quotes you can quote map names with
>> single quotes and vice-versa.
>>
>> --
>> Glynn Clements 
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS 6.4.3RC2 released

[Anna Kratochvílová]

Hi Hamish,

On Wed, Feb 13, 2013 at 11:55 PM, Hamish  wrote:
> Hi,
>
> - verify that the wxPsmap symbol decoration tool can be refined
> later without breaking backwards compatibility

sorry, I haven't have time to think about it so far.
So you want to use the grass symbols instead of eps north arrow
images. What is exactly the reason? You probably explained it but I
forgot it. Personally, I am not very fond of this format. Anyway if
you convert the arrow images, there is probably no way not to break
the compatibility. One thing we can then do is to create a script
which could find and convert the eps instruction to a point
instruction in the ps.map instructions file. However, is the
compatibility a real problem?

If you want to convert the arrows, I would suggest to create a new
directory 'north_arrows' (besides basic, extra, ...). This would
simplify the life of users (why on earth are north arrows located in
'extra'?) and me as a developer of the composer (in the north arrow
dialog I would show only the north_arrow directory, otherwise I would
have to filter all the symbols by the name or something like this). I
think we can afford this change in grass 7, maybe we can revise also
the other names like basic and extra?

Regards,
Anna

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

Re: [GRASS-dev] does GRASS 7 for Mac compile yet?

[Anna Kratochvílová]

Hi Massimo,

I have hopefully fixed some of the errors you sent me. Could you go
through them again and make an updated list of errors? I will try to
fix as much as possible and for the rest you should create a ticket
not to forget about them.

The problem with wxversion is strange, I have now similar problem too
(with Ubuntu 12.04).

On Tue, Feb 12, 2013 at 12:56 AM, epi  wrote:
>
> Thank you Anna,
>
> i'll be happy to try any solution.
>
> in the main time i opened a bug :
>
> http://trac.osgeo.org/grass/ticket/1884
>
> related to the cairodriver, is mac specific but not directly related to the 
> gui

perhaps someone else could help you with this?

Anna


>
>
> Massimo.
>
> Il giorno 08/feb/2013, alle ore 06:28, Anna Kratochvílová 
>  ha scritto:
>
> > Hi,
> >
> > I am able to fix certain problems but sometimes the error messages are
> > not helpful much and I need to test myself but I don't have the Mac
> > with the wxpython 2.9. During the community sprint I tested it a
> > little on Nikos' computer but I didn't have enough time.
> >
> > On Thu, Feb 7, 2013 at 11:28 PM, massimo di stefano
> >  wrote:
> >> Is this way to debug the gui useful for you dev ?
> >>
> >> is there anything i can try to do for you to help in debugging ?
> >>
> >
> > I can send you a patch to test but it can take a long time to fix it
> > because I don't usually have clear idea what can be wrong. However,
> > this is probably the only way, now. I will try to work on it in the
> > next days/weeks.
> >
> > Thanks for the testing,
> > Anna
> >
> >
> >>
> >>
> >>
> >> I think the cairo problem is related to grass core, not just the gui.
> >> anyone can help in fixing the build error ?
> >>
> >>
> >> thanks!
> >>
> >> Massimo.
> >>
> >>
> >> ##
> >>
> >>
> >> Hi Anna,
> >>
> >> it fails to import the wxversion module.
> >>
> >> ERROR: wxGUI requires wxPython. No module named wxversion
> >> Error in GUI startup. If necessary, please report this error to the GRASS
> >> developers.
> >> Switching to text mode now.
> >>
> >> Hit RETURN to continue...
> >>
> >> i had to comment the lines :
> >>
> >> #if not os.getenv("GRASS_WXBUNDLED"):
> >> #CheckForWx()
> >>
> >>
> >> thanks for the fix, the rasrer map is displayed correctly without any
> >> changes to the code.
> >>
> >> testing the gui ..
> >>
> >> - pointer, query, pan, zoom (all the options)  [works]
> >> - measure tool [works]
> >>
> >>
> >> - profile tool doesn't work [doesn't work]
> >>
> >> it let me select the raster map, then shows a blanc "Grass Profile 
> >> Analysis"
> >> in the status bar i can see "left mouse down at point (float, float)"
> >> when click on the map i got in the "command console" :
> >>
> >> (Wed Feb  6 11:12:13 2013)
> >> r.what --v -f -n map=elevation.10m@PERMANENT
> >> coordinates=595356.617647,4923676.470588
> >> easting|northing|site_name|elevation.10m@PERMANENT|elevation.10m@PERMANENT_label
> >> 595356.617647|4923676.470588||1253.797607|
> >> (Wed Feb  6 11:12:13 2013) Command finished (0 sec)
> >> (Wed Feb  6 11:12:26 2013)
> >> r.what --v -f -n map=elevation.10m@PERMANENT
> >> coordinates=599551.470588,4920665.441176
> >> easting|northing|site_name|elevation.10m@PERMANENT|elevation.10m@PERMANENT_label
> >> 599551.470588|4920665.441176||1344.138306|
> >> (Wed Feb  6 11:12:26 2013) Command finished (0 sec)
> >> (Wed Feb  6 11:12:30 2013)
> >> r.what --v -f -n map=elevation.10m@PERMANENT
> >> coordinates=596669.117647,4921051.470588
> >> easting|northing|site_name|elevation.10m@PERMANENT|elevation.10m@PERMANENT_label
> >> 596669.117647|4921051.470588||1400.473877|
> >>
> >> .. but nothing is displayed back to the profile tool
> >>
> >>
> >> - Grass histogramming Tool [doesn't work] :
> >>
> >> it show me the "Grass histogramming Tool " window, but then i got this log
> >> in the console :
> >>
> >> (Wed Feb  6 11:12:37 2013) Command finished (0 sec)
> >> Traceback (most recent call last):
> >>  File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/fr
> &g

Re: [GRASS-dev] g.gui fails

[Anna Kratochvílová]

On Sun, Feb 10, 2013 at 9:15 PM, Michael Barton  wrote:
> This sounds suspiciously similar to the compile errors we are getting on the
> Mac, even though g.gui modules actually launch.
>
> The error given from compile is that wx cannot be found.

This is maybe a similar type of problem but I think it's not related
to mine. I don't have any compile errors. The interesting part is that
g.gui (which is not working) should launch the gui by the same command
which is working for me in command line (python .../wxgui.py&).

Anna

>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
> On Feb 10, 2013, at 1:00 PM, grass-dev-requ...@lists.osgeo.org wrote:
>
>
> From: Anna Kratochvílová 
> Subject: [GRASS-dev] g.gui fails
> Date: February 10, 2013 7:39:52 AM MST
> To: GRASS-dev 
>
>
> Hi,
>
> I've upgraded today from ubuntu 10.04 to 12.04 and now I have problems
> to start wxGUI. Launching grass is OK, the GUI appears but when I want
> to open a new one with g.gui, it refuses to open because it is not
> able to import wxversion and wx (in globalvar.py). When I launch
> python in command line, I can import both wxversion and wx without
> problems. Launching gui directly - python gui/wxpython/wxgui.py& -
> works (using python 2.7). Is there something special about the g.gui
> command? Any ideas where could be the problem?
>
> Thanks,
> Anna
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] g.gui fails

[Anna Kratochvílová]

Hi,

I've upgraded today from ubuntu 10.04 to 12.04 and now I have problems
to start wxGUI. Launching grass is OK, the GUI appears but when I want
to open a new one with g.gui, it refuses to open because it is not
able to import wxversion and wx (in globalvar.py). When I launch
python in command line, I can import both wxversion and wx without
problems. Launching gui directly - python gui/wxpython/wxgui.py& -
works (using python 2.7). Is there something special about the g.gui
command? Any ideas where could be the problem?

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

Re: [GRASS-dev] Fwd: does GRASS 7 for Mac compile yet?

[Anna Kratochvílová]

ython/mapdisp/fr
> ame.py", line 1209, in OnAddText
>
> self.SwitchTool(self.toolbars['map'], event)
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/fr
> ame.py", line 1378, in SwitchTool
>
> self.UpdateTools(event)
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/fr
> ame.py", line 1400, in UpdateTools
>
> if event.GetEventObject().GetId() == \
> AttributeError
> :
> 'Menu' object has no attribute 'GetId'
>
> - Save display to graphic file [works]
>
> - Print [works]
>
> - switch to 3D (wxNviz) [doesn't work]:
>
> i got this log in the console :
>
> Starting 3D view mode...
> Traceback (most recent call last):
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/to
> olbars.py", line 229, in OnSelectTool
>
> self.parent.AddNviz()
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/fr
> ame.py", line 328, in AddNviz
>
> self._layerManager.AddNvizTools()
>   File
> "/usr/local/grass-7.0.svn/etc/gui/wxpython/lmgr/frame.py",
> line 341, in AddNvizTools
>
> display = self.GetMapDisplay())
>   File
> "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/tools.py",
> line 102, in __init__
>
> self.AddPage(page = self._createAnimationPage(),
>   File
> "/usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/tools.py",
> line 401, in _createAnimationPage
>
> usage = "record", label = _("Record"))
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/w
> idgets.py", line 405, in __init__
>
> maskColor = wx.Color(255, 255, 255)
> AttributeError
> :
> 'module' object has no attribute 'Color'
> Traceback (most recent call last):
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/ma
> pwindow.py", line 463, in OnIdle
>
> self.UpdateMap()
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/ma
> pwindow.py", line 687, in UpdateMap
>
> pdctype = self.overlays[id].pdcType, coords =
> self.overlays[id].coords)
> KeyError
> :
> 0
>
> # afeter that i was not able to have the 2D map back working, opening a new
> display fixed it.
>
> - vector tools [doesn't work] :
> i guess the main problem is the cairo driver .. in any case this is part of
> the log i got :
>
> Traceback (most recent call last):
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/ma
> pwindow.py", line 1000, in MouseActions
>
> self.OnLeftUp(event)
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/ma
> pwindow.py", line 1214, in OnLeftUp
>
> self._onLeftUp(event)
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/vdigit/map
> window.py", line 834, in _onLeftUp
>
> if len(self.digit.GetDisplay().GetSelected()) > 0:
> AttributeError
> :
> 'NoneType' object has no attribute 'GetDisplay'
>
> (and a pop up no vector map selected for editing)
>
>
>
>
>
> i had to build without cairo support .. because of the error i posted
> before.
> thanks to William that point out it can be a configuration problem
>
> GRASS Configure is not storing the fontconfig linking in
>> platform.make so it doesn't get into the cairo driver compilation.
>
>
> also building without-cairo  when try to display vector data the gui
> complain about missed cairo.
> i tried to change the driver in the gui preference from cairo to png but
> then the gui freeze and i have to force-quit it.
>
> i'll be happy to continue testing if can be of any help,
> thanks for the hard work!
>
> Massimo
>
>
>
>
> 2013/2/5 Anna Kratochvílová 
>>
>> Hi,
>>
>> On Mon, Feb 4, 2013 at 11:57 PM, epi  wrote:
>> > i'm trying to debug the build of GRASS 7 on mac OSX 10.8.x in 64 bit
>> > with WX
>> > 2.9.x
>> >
>> > After commenting the check for wx version i got the GUI start, some
>> > worning
>>
>> what exactly is the problem with the 'check for wx version'? The
>> warning (wx.InitAllImageHandlers) and the PrepareDC error should be
>> fixed now.
>>
>> Anna
>>
>> > :
>> >
>> > ###
>> > GRASS 7.0.svn (spearfish60):~ >
>> > /usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py:54:
>> > wxPyDeprecationWarning: Call to deprecated item 'InitAllImageHandlers'.
>> >   wx.InitAllImageHandlers()
>> > /usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/goutput.py:230:
>> > wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSize

Re: [GRASS-dev] GRASS6.4.3RC2 issues

[Anna Kratochvílová]

On Tue, Jan 22, 2013 at 2:47 AM, Helena Mitasova  wrote:

>
> - in 2D display legend is now much better than ever before, but
> when the d.legend command is run from command line
> it appears that the legend parameters are not carried over to the GUI
> and need to be entered in GUI again - is this the desired behavior?
> For example in the sequence
> # Convert from vector to raster
> in this assignment
> http://courses.ncsu.edu/mea582/common/GIS_anal_grass/GIS_Anal_grdataS2.html
> this command does not work properly from the command line
> d.legend streets_speed_30m at=5,30,2,5 use=25,35,45,55,65
> Also, if there is a legend already present, "Add legend" opens the legend GUI
> behind the map display window (where it is of course hard to find)
> I think this issue has already been discussed before
> BTW, the legend now runs on Mac in 3d wxnviz well.

Please try to test, I made larger changes and I hope I didn't create
any new problem.

>
> - g.remove run from command console thinks I am in PERMANENT rather than the 
> current mapset

I was not able to reproduce it, anyone else?


Anna

>
> g.remove rast=elev_lidrural1mr_1m
> Removing raster 
> WARNING: Raster map  not found
> WARNING:  nothing removed
>
> from linux shell it works
> GRASS 6.4.3RC2 (nc_spm_08):~ > g.remove rast=elev_lidruralmr_1m
> Removing raster 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] does GRASS 7 for Mac compile yet?

[Anna Kratochvílová]

Hi,

On Mon, Feb 4, 2013 at 11:57 PM, epi  wrote:
> i'm trying to debug the build of GRASS 7 on mac OSX 10.8.x in 64 bit with WX
> 2.9.x
>
> After commenting the check for wx version i got the GUI start, some worning

what exactly is the problem with the 'check for wx version'? The
warning (wx.InitAllImageHandlers) and the PrepareDC error should be
fixed now.

Anna

> :
>
> ###
> GRASS 7.0.svn (spearfish60):~ >
> /usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py:54:
> wxPyDeprecationWarning: Call to deprecated item 'InitAllImageHandlers'.
>   wx.InitAllImageHandlers()
> /usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/goutput.py:230:
> wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSizeHints'.
>   outputSizer.SetVirtualSizeHints(self.panelOutput)
> ###
>
>
> the Window Manager seems to work properly (i cal load a layer Rast/Vect in
> the lkayer tree, the shell also pront out the log of commands nicely)
> but i can't display layers (both Vector and Raster are not displayed).
> Commenting  this 2 line in madisp.py :
>
> 359 #self.PrepareDC(dc)
> 519#self.PrepareDC(dc)
>
> i got the Raster map displaying properly
>
> but no vector, the error is in a missed Cairo Driver :
>
>
> /usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/ghelp.py:
> 608: wxPyDeprecationWarning: Call to deprecated item
> 'InitAllImageHandlers'.
>   wx.InitAllImageHandlers()
> Command 'd.vect map=archsites@PERMANENT
> type=point,line,area,face' failed
> Details: Unknown display driver 
> Command 'd.vect map=archsites@PERMANENT
> type=point,line,area,face' failed
> Details: Unknown display driver 
>
>
> I wasn't able to get the cairo driver working during the Make step, it shows
> the error at the end of the log [1]
> about a missed arch ... but i guess ... I have everything built as
> --universal
>
> In doubt I rebuilt fontconfig and cairo and checked the relative
> architecture :
>
> lipo -info /usr/local/Cellar/cairo/1.12.12/lib/cairo/libcairo-trace.0.dylib
> /usr/local/Cellar/cairo/1.12.12/lib/libcairo-gobject.2.dylib
> /usr/local/Cellar/cairo/1.12.12/lib/libcairo-script-interpreter.2.dylib
> /usr/local/Cellar/cairo/1.12.12/lib/libcairo.2.dylib
> Architectures in the fat file:
> /usr/local/Cellar/cairo/1.12.12/lib/cairo/libcairo-trace.0.dylib are: i386
> x86_64
> Architectures in the fat file:
> /usr/local/Cellar/cairo/1.12.12/lib/libcairo-gobject.2.dylib are: i386
> x86_64
> Architectures in the fat file:
> /usr/local/Cellar/cairo/1.12.12/lib/libcairo-script-interpreter.2.dylib are:
> i386 x86_64
> Architectures in the fat file:
> /usr/local/Cellar/cairo/1.12.12/lib/libcairo.2.dylib are: i386 x86_64
> epi:~ epi$
>
>
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cache:Mach-O universal
> binary with 2 architectures
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cache (for architecture i386):
> Mach-O executable i386
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cache (for architecture x86_64):
> Mach-O 64-bit executable x86_64
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cat:  Mach-O universal
> binary with 2 architectures
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cat (for architecture i386):
> Mach-O executable i386
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-cat (for architecture x86_64):
> Mach-O 64-bit executable x86_64
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-list: Mach-O universal
> binary with 2 architectures
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-list (for architecture i386):
> Mach-O executable i386
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-list (for architecture x86_64):
> Mach-O 64-bit executable x86_64
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-match:Mach-O universal
> binary with 2 architectures
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-match (for architecture i386):
> Mach-O executable i386
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-match (for architecture x86_64):
> Mach-O 64-bit executable x86_64
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-pattern:  Mach-O universal
> binary with 2 architectures
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-pattern (for architecture i386):
> Mach-O executable i386
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-pattern (for architecture
> x86_64): Mach-O 64-bit executable x86_64
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-query:Mach-O universal
> binary with 2 architectures
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-query (for architecture i386):
> Mach-O executable i386
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-query (for architecture x86_64):
> Mach-O 64-bit executable x86_64
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-scan: Mach-O universal
> binary with 2 architectures
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-scan (for architecture i386):
> Mach-O executable i386
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-scan (for architecture x86_64):
> Mach-O 64-bit executable x86_64
> /usr/local/Cellar/fontconfig/2.10.91/bin/fc-validate: Mach-O universal
> binary with 2 architectures
> /usr/l

Re: [GRASS-dev] a minor but annoying bug just discovered with switching mapsets

[Anna Kratochvílová]

On Sun, Feb 3, 2013 at 8:49 PM, Michael Barton  wrote:
> I'm emailing in case that anyone is still sprinting on the opposite side of
> the world.
>
> I just realized that if you change to a new mapset using g.mapset and then
> quit (properly), the mapset you changed to with g.mapset appears as locked
> the next time you try to open it. This is in trunk, but may affect other
> versions.

I am not sure what you mean. You use the g.mapset through menu (GRASS
working environment->Change mapset)?

Anna

>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS 6.4.3RC2 released

[Anna Kratochvílová]

On Sun, Feb 3, 2013 at 1:30 AM, Helena Mitasova  wrote:
>
> -wxnviz - in wxnviz for draped vector lines after I change the line width 
> e.g. to 0,
> the displayed line goes back to wider line each time something else is drawn
> (e.g. fringe or view is changed) but the number is still set to 0.  (I 
> haven't submitted a bug report on this yet)

I just set the minimum line width to 1 instead of 0 because 0 seems to
be a invalid and a nonsense anyway. Please try if it helps.

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

Re: [GRASS-dev] animations on Mac problem

[Anna Kratochvílová]

On Thu, Jan 31, 2013 at 5:09 PM, Helena Mitasova  wrote:
> This is the error that I get when I try to run the animation (on MacOSX10.6 - 
> I will try on 10.8 as well later on):

Could you test it again, I've just committed a small change which could help.

Anna

>
> Helena
>
> Traceback (most recent call last):
>   File "/Users/helena/grassdev7/grass_trunk/dist.x86_64
> -apple-darwin10.8.0/etc/gui/wxpython/lmgr/frame.py", line
> 1397, in OnAnimationTool
>
> frame = AnimationFrame(parent = self)
>   File "/Users/helena/grassdev7/grass_trunk/dist.x86_64
> -apple-darwin10.8.0/etc/gui/wxpython/animation/frame.py",
> line 54, in __init__
>
> self.animationPanel = AnimationsPanel(self, self.windows,
> initialCount = MAX_COUNT)
>   File "/Users/helena/grassdev7/grass_trunk/dist.x86_64
> -apple-darwin10.8.0/etc/gui/wxpython/animation/frame.py",
> line 256, in __init__
>
> w = AnimationWindow(self)
>   File "/Users/helena/grassdev7/grass_trunk/dist.x86_64
> -apple-
> darwin10.8.0/etc/gui/wxpython/animation/mapwindow.py", line
> 108, in __init__
>
> self.bitmap = wx.EmptyBitmap(0, 0)
>   File "/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/Syst
> em/Library/Frameworks/Python.framework/Versions/2.6/Extras/l
> ib/python/wx-2.8-mac-unicode/wx/_gdi.py", line 726, in
> EmptyBitmap
> wx._core
> .
> PyAssertionError
> :
> C++ assertion "m_hBitmap" failed at
> ../src/mac/carbon/bitmap.cpp(242) in Create(): Unable to
> create CGBitmapContext context
>
>
> Helena Mitasova
> Associate Professor
> Department of Marine, Earth, and Atmospheric Sciences
> 2800 Faucette Drive, Rm. 1125 Jordan Hall
> North Carolina State University
> Raleigh, NC 27695-8208
> hmit...@ncsu.edu
>
> "All electronic mail messages in connection with State business which are 
> sent to or received by this account are subject to the NC Public Records Law 
> and may be disclosed to third parties.”
>
> On Jan 31, 2013, at 6:15 AM, Anna Kratochvílová wrote:
>
>> On Thu, Jan 31, 2013 at 11:47 AM, Luca Delucchi  wrote:
>>> 2013/1/31 Thomas Adams - NOAA Federal :
>>>> All,
>>>>
>>>
>>> Hi Thomas
>>>
>>>> I'm a Mac user in addition to Linux. I'm going to have more free time
>>>> starting in a few weeks. I'd be happy to step-up my use of GRASS 7 for
>>>> testing. Just let me know what I can do. I'm moving from the U.S. to
>>>> Melbourne, Australia in a couple of weeks!
>>>>
>>>
>>> thanks for your support, you could start to read from here [0].
>>> Michael and William could you update the instructions of this file [1]
>>> for GRASS7 and move them to the wiki page please?
>>>
>>
>> Michael, it would be helpful to summarize all the problems. It is very
>> confusing at least for me. It is not clear which problems are related
>> to the introduction of g.gui.* modules, wxPython version and so on
>> because the information is in many threads.
>>
>> Thanks,
>> Anna
>>
>>>> Cheers,
>>>> Tom
>>>>
>>>
>>> [0] http://grasswiki.osgeo.org/wiki/Compiling_on_MacOSX
>>> [1] 
>>> http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/macosx/ReadMe.rtf?format=raw
>>>
>>>
>>> --
>>> ciao
>>> Luca
>>>
>>> http://gis.cri.fmach.it/delucchi/
>>> www.lucadelu.org
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] does GRASS 7 for Mac compile yet?

[Anna Kratochvílová]

/wx-2.8-mac-unicode/wx/__init__.py",
>  line 45, in 
>
>   File 
> "/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core.py",
>  line 4, in 
> ImportError: 
> /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core_.so:
>  no appropriate 64-bit architecture (see "man python" for running in 32-bit 
> mode)
> make[1]: *** [g.gui.mapswipe.tmp.html] Error 1
> rm g.gui.mapswipe.tmp.html
> make: *** [guiscript] Error 2
>


Maybe this could be helpful [1]? Also, there is a changeset [2] which
could be related although it is quite old.


[1] 
http://stackoverflow.com/questions/2565201/wxpython-incompatible-with-snow-leopard
[2] http://trac.osgeo.org/grass/changeset/40523


> Helena Mitasova
> Associate Professor
> Department of Marine, Earth, and Atmospheric Sciences
> 2800 Faucette Drive, Rm. 1125 Jordan Hall
> North Carolina State University
> Raleigh, NC 27695-8208
> hmit...@ncsu.edu
>
> "All electronic mail messages in connection with State business which are 
> sent to or received by this account are subject to the NC Public Records Law 
> and may be disclosed to third parties.”
>
> On Jan 31, 2013, at 6:15 AM, Anna Kratochvílová wrote:
>
>> On Thu, Jan 31, 2013 at 11:47 AM, Luca Delucchi  wrote:
>>> 2013/1/31 Thomas Adams - NOAA Federal :
>>>> All,
>>>>
>>>
>>> Hi Thomas
>>>
>>>> I'm a Mac user in addition to Linux. I'm going to have more free time
>>>> starting in a few weeks. I'd be happy to step-up my use of GRASS 7 for
>>>> testing. Just let me know what I can do. I'm moving from the U.S. to
>>>> Melbourne, Australia in a couple of weeks!
>>>>
>>>
>>> thanks for your support, you could start to read from here [0].
>>> Michael and William could you update the instructions of this file [1]
>>> for GRASS7 and move them to the wiki page please?
>>>
>>
>> Michael, it would be helpful to summarize all the problems. It is very
>> confusing at least for me. It is not clear which problems are related
>> to the introduction of g.gui.* modules, wxPython version and so on
>> because the information is in many threads.
>>
>> Thanks,
>> Anna
>>
>>>> Cheers,
>>>> Tom
>>>>
>>>
>>> [0] http://grasswiki.osgeo.org/wiki/Compiling_on_MacOSX
>>> [1] 
>>> http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/macosx/ReadMe.rtf?format=raw
>>>
>>>
>>> --
>>> ciao
>>> Luca
>>>
>>> http://gis.cri.fmach.it/delucchi/
>>> www.lucadelu.org
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] does GRASS 7 for Mac compile yet?

[Anna Kratochvílová]

On Thu, Jan 31, 2013 at 11:47 AM, Luca Delucchi  wrote:
> 2013/1/31 Thomas Adams - NOAA Federal :
>> All,
>>
>
> Hi Thomas
>
>> I'm a Mac user in addition to Linux. I'm going to have more free time
>> starting in a few weeks. I'd be happy to step-up my use of GRASS 7 for
>> testing. Just let me know what I can do. I'm moving from the U.S. to
>> Melbourne, Australia in a couple of weeks!
>>
>
> thanks for your support, you could start to read from here [0].
> Michael and William could you update the instructions of this file [1]
> for GRASS7 and move them to the wiki page please?
>

Michael, it would be helpful to summarize all the problems. It is very
confusing at least for me. It is not clear which problems are related
to the introduction of g.gui.* modules, wxPython version and so on
because the information is in many threads.

Thanks,
Anna

>> Cheers,
>> Tom
>>
>
> [0] http://grasswiki.osgeo.org/wiki/Compiling_on_MacOSX
> [1] 
> http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/macosx/ReadMe.rtf?format=raw
>
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] does GRASS 7 for Mac compile yet?

[Anna Kratochvílová]

On Thu, Jan 31, 2013 at 9:35 AM, Luca Delucchi  wrote:
> 2013/1/31 Anna Kratochvílová :
>
>>
>> Anyone with Mac is coming to GRASS community sprint? It could be a
>> good opportunity to solve it.
>>
>
> I could bring my minimac from home... otherwise if I remember well
> Nikos has a Mac

That would be great. But is GRASS 7 not compiling on your or Nikos
Mac? I think that some configurations (Mac/Python/wxPython) are
working and some are not.

Anna

>
>> Anna
>>
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] does GRASS 7 for Mac compile yet?

[Anna Kratochvílová]

On Sat, Jan 26, 2013 at 6:32 PM, Michael Barton  wrote:
> Does anyone know if the compile errors introduced with the new wxPython
> animation module have been fixed for GRASS 7 and it now compiles again on
> the Mac? I haven't had a chance to check for the past month.
>

Anyone with Mac is coming to GRASS community sprint? It could be a
good opportunity to solve it.

Anna

> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] WxGUI should provide area measurement tool

[Anna Kratochvílová]

On Mon, Jan 21, 2013 at 6:47 AM, Rashad M  wrote:
> All,
>
> Is there anyone working on this ?

related ticket: http://trac.osgeo.org/grass/ticket/975

Anna

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

Re: [GRASS-dev] d.correlate not working

[Anna Kratochvílová]

On Mon, Jan 14, 2013 at 5:46 AM, Rashad M  wrote:
> when a command is issued and if d.mon wx monitor is working it should be
> routed in a different way.
>
> I noticed when d.correlate command is issued with wx  montior ON, the
> command is not properly parsed.
>
> could you tell when a command is issued within grass shell with Gui ON,
> where is get parsed?
>
> so that i could try for a patch :)

It is strange that instead of d.correlate, there is written d.graph in
the command file used by d.mon (d.correlate calls d.graph). But I
don't know where the command is written into the command file (perhaps
g.parser?).

Anna

>
>
> On Mon, Jan 14, 2013 at 10:04 AM, Rashad M 
> wrote:
>>
>> it worked using command layer
>>
>> There should be some an option to use d.correlate in the other way too
>> d.mon wx0
>> d.correlate .
>>
>>
>> On Sun, Jan 13, 2013 at 9:49 PM, Anna Kratochvílová
>>  wrote:
>>>
>>> On Sat, Jan 12, 2013 at 10:43 AM, Rashad M 
>>> wrote:
>>> > using:
>>> > grass  7.0
>>> > revision:54601
>>> >
>>> >
>>> > d.correlate is not working
>>> >
>>> > To reproduce
>>> > d.mon wx0
>>> > d.correlate map=lsat5_1987_10,lsat5_1987_20
>>> >
>>> > error:
>>> >
>>> > GRASS_INFO_WARNING(25298,1): Illegal filename
>>> > . Character <,> not allowed.
>>> >
>>> > GRASS_INFO_END(25298,1)
>>> >
>>> > GRASS_INFO_WARNING(25314,1): Illegal filename
>>> > . Character <,> not allowed.
>>> >
>>> > GRASS_INFO_END(25314,1)
>>> > Traceback (most recent call last):
>>> >   File
>>> > "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_misc.py",
>>> > line 1358, in Notify
>>> > self.notify()
>>> >   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/main.py",
>>> > line
>>> > 290, in watcher
>>> > self.mapFrm.GetMap().GetLayersFromCmdFile()
>>> >   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/main.py",
>>> > line
>>> > 102, in GetLayersFromCmdFile
>>> > self.AddLayer(ltype = ltype, command = cmd, active = False, name =
>>> > name)
>>> >   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py", line
>>> > 1042, in AddLayer
>>> > active = active, hidden = hidden, opacity = opacity)
>>> >   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py", line
>>> > 339,
>>> > in __init__
>>> > active, hidden, opacity)
>>> >   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py", line
>>> > 88,
>>> > in __init__
>>> > self.SetType(ltype)
>>> >   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py", line
>>> > 268,
>>> > in SetType
>>> > raise GException(_("Unsupported map layer type '%s'") % ltype)
>>> > core.gcmd.GException: Unsupported map layer type 'None'
>>> >
>>> >
>>>
>>> Some of d. commands are not supported yet in wxGUI but at least you
>>> can try to add them as a command layer in Layer Manager, it is in the
>>> 'Add grid or vector overlays' (perhaps it should be 'Add miscellaneous
>>> overlays').
>>>
>>> Anna
>>>
>>> > --
>>> > Regards,
>>> >Rashad
>>> >
>>> > ___
>>> > grass-dev mailing list
>>> > grass-dev@lists.osgeo.org
>>> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>>
>>
>>
>> --
>> Regards,
>>Rashad
>
>
>
>
> --
> Regards,
>Rashad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] d.correlate not working

[Anna Kratochvílová]

On Sat, Jan 12, 2013 at 10:43 AM, Rashad M  wrote:
> using:
> grass  7.0
> revision:54601
>
>
> d.correlate is not working
>
> To reproduce
> d.mon wx0
> d.correlate map=lsat5_1987_10,lsat5_1987_20
>
> error:
>
> GRASS_INFO_WARNING(25298,1): Illegal filename
> . Character <,> not allowed.
>
> GRASS_INFO_END(25298,1)
>
> GRASS_INFO_WARNING(25314,1): Illegal filename
> . Character <,> not allowed.
>
> GRASS_INFO_END(25314,1)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_misc.py",
> line 1358, in Notify
> self.notify()
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/main.py", line
> 290, in watcher
> self.mapFrm.GetMap().GetLayersFromCmdFile()
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/mapdisp/main.py", line
> 102, in GetLayersFromCmdFile
> self.AddLayer(ltype = ltype, command = cmd, active = False, name = name)
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py", line
> 1042, in AddLayer
> active = active, hidden = hidden, opacity = opacity)
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py", line 339,
> in __init__
> active, hidden, opacity)
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py", line 88,
> in __init__
> self.SetType(ltype)
>   File "/usr/local/grass-7.0.svn/etc/gui/wxpython/core/render.py", line 268,
> in SetType
> raise GException(_("Unsupported map layer type '%s'") % ltype)
> core.gcmd.GException: Unsupported map layer type 'None'
>
>

Some of d. commands are not supported yet in wxGUI but at least you
can try to add them as a command layer in Layer Manager, it is in the
'Add grid or vector overlays' (perhaps it should be 'Add miscellaneous
overlays').

Anna

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

Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?

[Anna Kratochvílová]

mple of settings that I have used (the name of the volume 
>>>>> raster is slightly different
>>>>> but it is the same data).
>>>>>
>>>>>> m.nviz.image elevation_map=JR_2008_ALL -a mode=fine resolution_fine=1 
>>>>>> color=243:243:243 volume=JR_7408MR_2m volume_shading=gouraud 
>>>>>> volume_resolution=1 volume_position=0,0,20 isosurf_level=1:17.0 
>>>>>> isosurf_color_map=JR_7408MR_2m isosurf_transp_value=0 position=0.11,0.07 
>>>>>> height=243 perspective=13 twist=0 zexag=6.00 focus=569,593,17 
>>>>>> light_position=0.26,-0.30,0.61 light_brightness=94 light_ambient=55 
>>>>>> light_color=255:255:255 output=nviz_output format=ppm size=798,545
>>>>>
>>>>> This volume includes no-data because the original rasters were masked, I 
>>>>> think it would be useful to start with a volume without no-data -
>>>>> just use r3.null to replace no-data with 0.
>>>>>
>>>>> Let me know if it would be useful for me to run same thing in MacOSX 10.6 
>>>>> (I still don't have 10.8 machine quite ready),
>>>>> (see the slides 12 and 13 here for the isosurfaces at different levels, I 
>>>>> have the isosurfaces colored by year - I don't think I gave you
>>>>> that raster, so your isosurfaces should be just a single color).
>>>>> http://skagit.meas.ncsu.edu/~helena/publwork/AGU2012lidar6.pptx
>>>>>
>>>>> Helena
>>>>>
>>>>>> Slices still crash because they still call gvl_align_data. As before, 
>>>>>> though initially displaying a slice works fine. It only crashes when I 
>>>>>> try to change something about the slice and it wants to redraw.
>>>>>>
>>>>>> Michael
>>>>>> 
>>>>>> C. Michael Barton
>>>>>> Director, Center for Social Dynamics & Complexity
>>>>>> Professor of Anthropology, School of Human Evolution & Social Change
>>>>>> Arizona State University
>>>>>>
>>>>>> voice:480-965-6262 (SHESC), 480-727-9746 (CSDC)
>>>>>> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jan 1, 2013, at 1:24 PM, Anna Kratochvílová 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> On Tue, Jan 1, 2013 at 8:48 PM, Michael Barton  
>>>>>>> wrote:
>>>>>>>> Hi Anna,
>>>>>>>>
>>>>>>>> On the slim chance that you are online today, can you tell me where 
>>>>>>>> gvl_align_data in gvl_calc.c reside in either the source code or 
>>>>>>>> compiled code? I have a bit of down time and thought I'd see what I 
>>>>>>>> could find out about the volume display breaking. I don't know C but 
>>>>>>>> can selectively rem out some things and see what happens.
>>>>>>>
>>>>>>> It should be here
>>>>>>> http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/gvl_calc.c#L685
>>>>>>>
>>>>>>> Also, you could try debugging with QtCreator [1] (as an user-friendly
>>>>>>> interface to the debugger), it is quite easy, here [2] is some help
>>>>>>> for setting up the project. I don't know what method you would like to
>>>>>>> use but this is the easiest I know. I suppose it should work on Mac,
>>>>>>> too.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Anna
>>>>>>>
>>>>>>> [1] http://qt-project.org/downloads
>>>>>>> [2] 
>>>>>>> http://grasswiki.osgeo.org/wiki/Using_QtCreator_for_GRASS_C_development#Debugging
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Michael
>>>>>>>> 
>>>>>>>> C. Michael Barton
>>>>>>>> Director, Center for Social Dynamics & Complexity
>>>>>>>> Professor of Anthropology, School of Human Evolution & Social Change
>>>>>>>> Arizona State University
>>>>>>>>
>>>>>>>> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
>>>>>>>> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
>>>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Dec 6, 2012, at 12:07 AM, Anna Kratochvílová 
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> Hi Michael,
>>>>>>>>>
>>>>>>>>> On Wed, Dec 5, 2012 at 11:02 PM, Michael Barton 
>>>>>>>>>  wrote:
>>>>>>>>>> Any suggestions yet on where the crash I documented in
>>>>>>>>>> http://trac.osgeo.org/grass/ticket/1736 actually happens in the code 
>>>>>>>>>> so that
>>>>>>>>>> I can take a look at it and see if there is something fixable for 
>>>>>>>>>> the Mac? I
>>>>>>>>>> posted what I hope is the relevant debug output to help identify 
>>>>>>>>>> this.
>>>>>>>>>>
>>>>>>>>>> While we may need to think about wxPython 2.9, it seems best to 
>>>>>>>>>> first look
>>>>>>>>>> at what line is actually causing the crash and see if there is a fix 
>>>>>>>>>> or
>>>>>>>>>> workaround.
>>>>>>>>>
>>>>>>>>> The crash occurs probably in gvl_align_data in gvl_calc.c. The error
>>>>>>>>> message 'pointer being realloc'd was not allocated' is quite clear,
>>>>>>>>> however it's not clear why it happens on Mac only. Maybe someone with
>>>>>>>>> better knowledge of C could understand it more.
>>>>>>>>>
>>>>>>>>> Anna
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Michael
>>>>>>>>>> 
>>>>>>>>>> C. Michael Barton
>>>>>>>>>> Director, Center for Social Dynamics & Complexity
>>>>>>>>>> Professor of Anthropology, School of Human Evolution & Social Change
>>>>>>>>>> Arizona State University
>>>>>>>>>>
>>>>>>>>>> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
>>>>>>>>>> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
>>>>>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Updating colorrules.py

[Anna Kratochvílová]

> On Thu, Dec 20, 2012 at 11:45 AM, Mohammed Rashad
>  wrote:
>> updated the patch. PFA

I've tested it on Ubuntu 12.04 (running in virtaul machine) with
wxPython 2.8.12.1 and there are some bugs. I've attached a screenshot.

 As you can see I have a problem with strange background of
checkboxes. I tried wxPython demo and this problem is there too so
probably we cannot do much about it. Do you have the same problem or
it's just me?

Then, when you change the color table (above the rules, there is 'Load
color table'; e.g. from rainbow to aspect) the original numbers in the
list ctrl are still there below the new ones.

I also had sometimes problems to uncheck the items but I am not sure
under which conditions (maybe after changing colortable).

In the beginning when there is no map loaded there are the two
original wx.TextCtrl widgtes

Have you tried to avoid the dialog for setting values? Ideally, user
could edit the rule's value directly in the listctrl and click (or
double click) on the color would launch the wx color dialog.

I think that this solution with ultimatelistctrl looks much better
than the original, however we must first make it work properly.

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

Re: [GRASS-dev] wxGUI: supervised classification tool

[Anna Kratochvílová]

Hi,

On Thu, Dec 20, 2012 at 9:52 AM, Markus Neteler  wrote:
> Hi,
>
> while searching for the new i.class tool I have discovered
> the "supervised classification tool"
> in Imagery -> Classify Image -> Interactive input for supervised 
> classification
>
> Nice!  /edit: I now see that it *is* the
> http://grasswiki.osgeo.org/wiki/WxIClass
>
Right, wxIClass (perhaps g.gui.iclass in the future), available as
"Interactive input for supervised classification" from the menu, is
intended to be an i.class replacement.

> I tried it with NC data and loaded the Landsat2002 group.
> Now I would expect that I can select channels for display from
> the group. Perhaps something with [x] checkboxes would be
> good. The existing "free" choice of maps should remain of course.

That's reasonable, other suggestions are here:
http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/wxIClass

>
> When I then digitize, it nicely opens the class dialog, ok. Then,
> when running, it segfaults (entire wxGUI disappears, no error msg
> visible).

There have been some changes three days ago which should fix this
crash. If you used the latest version, we have a problem.

>
> Suggestion: It may also become the tool for i.smap, just a method
> dialog would be needed
>
>> Run Analysis
> - MaxLik: i.maxlik
> - SMAP: i.gensigset, i.smap
>

yes, something like this is planned, Stepan is collecting these ideas now.

We haven't touched this tool for some time, however Martin tried to
use it in class with students this week and he promised to report
bugs.

Anna and Vaclav

> to make it universal. However, great to have such a tool now.
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Updating colorrules.py

[Anna Kratochvílová]

On Wed, Dec 19, 2012 at 4:39 PM, Mohammed Rashad
 wrote:
> Hi All,
>
> gui/wxpython/modules/colorrules.py, providing inteface for setting
> colortable for raster and vector.
>
> As I reported on trac[1] several weeks ago there is a bug in the code which
> happens if no. color rules for raster map is big (eg: 32763 This for
> nc_spm_08/landsat 4,3,2 color composite) . This will result in crashing the
> whole wxGUI!
>
> The problem is for each rule colorrules.py create a checkbox,textCtrl and
> ColorSelect.
>
> Creating these widgets will hangup the UI.
>
> A solution is to use a list control agw provides one such thing called
> ultimatelistCtrl.
>
> I had updated the colorrules.py and made a patch for it. Anyone Please
> review and update the file

Hi Rashad,

I can't even test your patch at the moment because UltimateListCtrl is
not supported in wxPython 2.8.10.1 (which is installed on my
computer). It seems that it is available from 2.8.11, however in the
grass requirements, there is wxPython >= 2.8.1.1. I agree that this
one is pretty old but still we must decide if it is worth changing the
requirements. I think that the version I have is still used a lot so
we should support it. You are using this widget to show the color I
suppose. I am not aware of any other good solution. Maybe you can a
condition on wxPython version and if it is high enough use this
widget, otherwise use the current implementation?

Anna

>
> PFA patch
>
> [0] http://trac.osgeo.org/grass/ticket/1816
>
>
> --
> Regards,
>Rashad
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] new wxGUI feature: Map Swipe

[Anna Kratochvílová]

On Thu, Dec 13, 2012 at 6:50 PM, Martin Landa  wrote:
> 2012/12/13 Moritz Lennert :
>>> it's more complicated there because it's needed to reproject the
>>> region I think. Anyway, georectifier needs refactoring first...
>>
>>
>> MarkusM has already implemented mirror mode in the georectifier:
>> http://trac.osgeo.org/grass/ticket/1669#comment:2
>
> really? it doesn't seem to work for me. Martin

maybe you are talking about different things? I know that georectifier
can synchronize the displays at one moment but they are not linked
permanently or at least I don't know about it.

Anna

>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] why is r.li.setup unavailable in GRASS 7?

[Anna Kratochvílová]

On Sat, Dec 1, 2012 at 2:09 PM, Luca Delucchi  wrote:
> 2012/12/1 Michael Barton :
>> Luca,
>
> Hi Micheal
>
>>
>> r.li.setup does not yet compile in GRASS 7, at least on the Mac.
>>
>
> I'm sorry :-(
>
>> Here is the error:
>>
>> anthgradpc7:g.version cmbarton$ cd 
>> /Users/Shared/grass_dev/grass7_dev/gui/wxpython/rlisetup
>> anthgradpc7:rlisetup cmbarton$ make
>> if [ 
>> "/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/scripts/g.gui.rlisetup"
>>  != "" ] ; then 
>> GISRC=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/demolocation/.grassrc70
>>  GISBASE=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0 
>> PATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/bin:$PATH"
>>  
>> PYTHONPATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/etc/python:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/etc/python:$PYTHONPATH"
>>  
>> DYLD_LIBRARY_PATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/lib:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/lib:"
>>  LC_ALL=C 
>> /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/scripts/g.gui.rlisetup
>>  --html-description < /dev/null | grep -v '\|' > g.gui.rlisetup.tmp.html ; fi
>> Traceback (most recent call last):
>>   File 
>> "/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.2.0/scripts/g.gui.rlisetup",
>>  line 32, in 
>> import  wx
>>   File 
>> "/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/__init__.py",
>>  line 45, in 
>> from wx._core import *
>>   File 
>> "/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core.py",
>>  line 4, in 
>> import _core_
>> ImportError: 
>> /usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so:
>>  no appropriate 64-bit architecture (see "man python" for running in 32-bit 
>> mode)
>> make: *** [g.gui.rlisetup.tmp.html] Error 1
>> rm g.gui.rlisetup.tmp.html
>>
>
> This seems more a WX problem...I know that it's a "stupid" answer but
> could you try
>
> import wx
>
> from python console?
>
>>
>> This may be the same error that is now affecting several GUI modules like 
>> map swipe, animation, and the graphical modeler.
>>

Just a remark:
This problem affecting map swipe, animation, graphical modeler and
r.li.setup is spread in several threads which makes it more
complicated to follow. What about to choose one of them?

subjects:
compiling animation, mapswipe, etc.
problems compiling GRASS 7 on Mac
Compiling under OSX Mountain Lion

Best,
Anna

>> Michael
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 3D points in grass7

[Anna Kratochvílová]

On Fri, Nov 30, 2012 at 7:56 PM, Helena Mitasova  wrote:
> when I need to display 3D vector points as 3D points (not draped over a 
> surface), is this supposed to happen automatically
> when I switch off the display on surface button or it is not supported yet?
> I get that the vector map is 3D but there is no button to tell it that the 
> points should be displayed using their z-coordinate.
> maybe I am missing something?

Currently, 3D points should be drawn with z coordinate by default. The
'display on surface' is misleading, now you can't drape them over any
surface.
This option is present in the library, so it must be added to the gui.
I will try to look at it later.

Anna


>
> Thank you, Helena
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Compiling under OSX Mountain Lion

[Anna Kratochvílová]

On Thu, Nov 29, 2012 at 3:12 AM, William Kyngesburye
 wrote:
> On Nov 28, 2012, at 12:27 PM, Markus Neteler wrote:
>
>> On Wed, Nov 28, 2012 at 6:35 PM, Carlos Grohmann
>>  wrote:
>>> Hi
>>>
>>> so, all modules under guy/wxpython that didn't compile show the same error:
>>>
>>>
>>> /usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so:
>>> no matching architecture in universal wrapper
>>> make: *** [g.gui.animation.tmp.html] Error 1
>>>
>>> and both modules under visualization also have a common problem
>>>
>>> "_wxEVT_ERASE_BACKGROUND", referenced from:
>>>  __static_initialization_and_destruction_0(int, int)in gui.o
>>>  "_wxEVT_IDLE", referenced from:
>>>  __static_initialization_and_destruction_0(int, int)in main.o
>>>  "_wxEVT_NULL", referenced from:
>>>  __static_initialization_and_destruction_0(int, int)in gui.o
>>>  __static_initialization_and_destruction_0(int, int)in main.o
>>>  "_wxEmptyString", referenced from:
>>>  wxStringBase::Init()  in gui.o
>>>  "_wxFrameNameStr", referenced from:
>>>  MyFrame::MyFrame(wxString const&, int, int, gui_data*)in gui.o
>>>  MyFrame::MyFrame(wxString const&, int, int, gui_data*)in gui.o
>>>  "_wxPanelNameStr", referenced from:
>>>  MyCanvas::MyCanvas(wxWindow*, int, wxSize const&)in gui.o
>>>  MyCanvas::MyCanvas(wxWindow*, int, wxSize const&)in gui.o
>>>  "_wxStaticTextNameStr", referenced from:
>>>  MyFrame::MyFrame(wxString const&, int, int, gui_data*)in gui.o
>>>  MyFrame::MyFrame(wxString const&, int, int, gui_data*)in gui.o
>>> ld: symbol(s) not found for architecture x86_64
>>> collect2: ld returned 1 exit status
>>> lipo: can't open input file:
>>> /var/folders/gf/8bwpz0412gs7706j57hdyb4hgn/T//ccTJ28Cm.out (No such file
>>> or directory)
>>> make: ***
>>> [/Volumes/HDD/Users/guano/Documents/installs/GIS/grass/grass_trunk/dist.x86_64-apple-darwin12.2.0/bin/xganim]
>>> Error 1
>
>
> WxPython 2.8 can only be built 32bit (aka Carbon).  GRASS configuration will 
> detect if wxPython is 64bit-ready, and force compilation in 32bits if not, 
> but that only works if you configure GRASS at least 32bit.  ie 32bit only, or 
> 32+64bit.  The default on Mt Lion is 64bit-only if you don't set any arch 
> options.
>
> This is why compilation with WxPython 2.9 works, because it can use 64bit 
> Cocoa.  But then there is the runtime problem that has yet to be solved.

What about the fix r40523 from the discussion mentioned by Markus?
Could it be helpful in this case?

Anna

>
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
>
> "I ache, therefore I am.  Or in my case - I am, therefore I ache."
>
> - Marvin
>
>
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.extension does not find wx.animation in svn

[Anna Kratochvílová]

On Wed, Nov 28, 2012 at 2:28 PM, Sören Gebbert
 wrote:
> Hi Martin,
> thanks for your fast answer. The animation tool is now available in
> the menu after i made a subversion update. Everything works fine now.

Sorry Soeren, I should have told you. You can now access it also
through command line. Try

g.gui.animation --help

Anna

>
> Best regards
> Soeren
>
> 2012/11/28 Martin Landa :
>> Hi,
>>
>> 2012/11/28 Sören Gebbert :
>>> The svn directory is missing indeed. So my question is: Where is
>>> wx.animation i really need it desperately.
>>>
>>> Any suggestions are welcome.
>>
>> the tool has been move recently by Anna to trunk.
>>
>> File -> Animation tool
>>
>> Martin
>>
>> --
>> Martin Landa  * http://geo.fsv.cvut.cz/~landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] MASK indicated on map display even after it was removed in GRASS 6.4.3 release

[Anna Kratochvílová]

On Thu, Nov 15, 2012 at 4:10 PM, Helena Mitasova  wrote:
>
>
> On Nov 15, 2012, at 8:27 AM, Markus Metz wrote:
>
>> On Thu, Nov 15, 2012 at 10:45 AM, Martin Landa  
>> wrote:
>>> Hi Helena,
>>>
>>> 2012/11/15 Helena Mitasova :
 This is not a serious problem but I just noticed  that the grass6.4.3 
 compiled on oct 18 on mac
 the red word MASK remains on the Map display even after the MASK is 
 removed.
 I don't seem to find a way how to get rid of it.
>>>
>>> tested with fresh 6.4.3svn. After removing the mask (`r.mask -r`) the
>>> indicator is also removed from the Map Display.
>>>
>>> Unfortunately I cannot reproduce this problem. Martin
>>
>> You can reproduce it if you create a MASK in one mapset, then change
>> to another mapset without a MASK, but with the first mapset in the
>> search path. If a MASK is found in any mapset in the search path, the
>> red word MASK will appear in the Map display. But only MASKs in the
>> current mapset are respected by raster operations, thus that red word
>> MASK should not be there in this case.

Should be fixed in all branches now (53839, 40, 41).

Anna

>
> yes, that is exactly my case, I have a MASK in another mapset,
>
> Helena
>
>>
>> Markus M
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new `g.gui.` modules

[Anna Kratochvílová]

On Fri, Nov 9, 2012 at 5:20 PM, Markus Neteler  wrote:
> Hi Martin,
>
> On Fri, Nov 9, 2012 at 2:54 PM, Martin Landa  wrote:
>> Hi,
>>
>> yesterday with Anna and Vaclav we added a new module `g.gui.mapswipe`
>> in G7 which allows to launch wxGUI Map Swipe as standalone
>> application. Today I did the same for Graphical Modeler. So currently
>> you can launch the Graphical Modeler also from CLI
> ...
>
> cool!! But :) to not have too many modules, how about
>
> # already there:
> g.gui gui=wxgui
>
> # new parameter "module=":
> g.gui module=mapswipe
> g.gui module=gmodeler
>
> Just a random thought,
>

We have already thought about this solution, however each gui module
would have different parameters, that's why we separated the modules.

Anna

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

Re: [GRASS-dev] why can't I query vector point in nc_spm08 demo data?

[Anna Kratochvílová]

On Tue, Nov 6, 2012 at 6:07 AM, Michael Barton  wrote:
> Any idea why I cannot query the precip_20ynormals vector points with a mouse
> in the sc_spm08 data set? I'm using GRASS 7 r53615 compiled on 30 October.
>
> These points have a single data layer with a valid attribute table. If I
> select all of the points and attempt to highlight them from the table
> manager, they all turn yellow as they should. But I get "nothing found" when
> I try to query them with a mouse from the display.

It works for me. Don't forget to select the vector layer before
querying but you probably know this.

Anna

>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] new wxGUI Animation Tool in addons

[Anna Kratochvílová]

Hi Soeren,

On Tue, Oct 30, 2012 at 2:35 PM, Sören Gebbert
 wrote:
> Hi Anna,
> you have implemented a great tool! I was able to visualize two space
> time raster datasets with different temporal granularity  (mixing year
> and month) synchronously. :)
> This is really cool.

Thanks to your temporal library, of course:)

>
> Having such a great tool raises many wishes that could be implemented
> in addition. :)
> Here just a few of them:

I've been thinking of these enhancements too. Some comments:
>
> * It would be great if vector time series are available to visulaize too
>   (as vector map list or space time vector datasets). So we can visualize
>   for example temperature maps and vector contours at the same
>   time in the same frame?

Of course this would make sense. To implement this, there should be a
more sophisticated way to specify layers to render - this means to
write a simplified layer manager. Another problem is the rendering -
the current rendering system in GUI is too slow to load too many maps
(therefore I currently use r.out.ppm module to write to stdout so that
it is in memory and it is not written to disk).
I also thought about adding option to load ready images. It would be
useful when you create some map composition with d.vect.chart or
similar and then you could load it in the animation tool and
optionally provide the time information as a temporal dataset which
was used for creating the charts.

>
> * Having a legend for the raster maps would be very handy for comparison.
>   I am preparing a tool to set the color table for a space time raster 
> datasets
>   computed from all registered maps. So the maps of a dataset would have
>   all the same color table representing the data range of the space
> time raster dataset.

I agree that legend is definitely useful.

>
> * A stepper would be great to step through the time series data
>   using the lowest temporal granularity of the visualized space time datasets

I guess you mean 'next/previous frame'. Now the slider enables to
change the frame by one time unit, for example, if granularity is 2
months, the next position is +1 month. I think this behavior is more
natural but we can discuss it more.

>
> * Exporting animation as mp4 or similar :)

The animation tool now provides export to image sequence. I am not
sure what should be done next - I can call an external program like
ffmpeg to create a video but someone else would like to use different
program or with different parameters and also I am not sure how these
things work on Windows.
Also it would be useful to convert the images directly (without saving
images on disk) by a python library but there are two problems -
PyMedia which seems to be dead and I can't find any other, and
secondly you need to install it.
There should be probably some general module in GRASS to export video
from images - now there is r.out.mpeg only for rasters and as far as I
remember it calls some external program too.
Therefore I think that for now it could be useful (at least for
someone) to get the animation as animated GIF (with the images2gif.py
script), although GIF has many disadvantages.
Correct me if I omitted any option.

>
> * Starting the animation tool from comand line

I will try to implement it. Maybe there will be only a limited
functionality available from the command line.

>
>
> I have prepared some datasets which you can play with:
> http://www-pool.math.tu-berlin.de/~soeren/tmp/

Thank you very much, I will have a look.

Best,
Anna

>
> These datasets are derived form the ECA&D project E-OBS gridded data[1].
> Usage policy od ECAD data is available here [2].
>
>
> You can simply import the datasets in a Lat/lon location using t.rast.import.
>
> Best regards
> Soeren
>
>
> [1] http://eca.knmi.nl/download/ensembles/ensembles.php
> [2] http://eca.knmi.nl/documents/ECAD_datapolicy.pdf
>
> 2012/10/19 Anna Kratochvílová :
>> Hi all,
>>
>> I would like to announce that new wxGUI Animation Tool is available
>> for testing in GRASS 7 Addons. You can install it with the g.extension
>> dialog (or in the command line: g.extension -s
>> extension=wx.animation). You can animate a series of raster maps or
>> better, a space time raster dataset created by the new GRASS 7
>> temporal framework.
>> Please, have a look at the videos on the wiki page [1] and the manual
>> page. I would like to demonstrate the functionality on some more
>> interesting data which I don't have, so I would be glad if someone
>> could help.
>>
>> Best,
>>
>> Anna
>>
>> [1] http://grass.osgeo.org/wiki/WxPython-based_GUI_for_GRASS#Animation_Tool
>> ___
>> grass-user mailing list
>> grass-u...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] removing nviz from trunk

[Anna Kratochvílová]

On Sat, Oct 27, 2012 at 12:13 AM, Martin Landa  wrote:
> Hi all,
>
> nviz is the last Tcl/Tk application in trunk.
>
> wxNviz [1] covers almost 100% of functionality compared to original
> nviz and it's stable enough for other testing and development. This is
> the main reason why I would vote for removing nviz from trunk
> including related libraries like `form` or `gtcltk`.

Hi,

here [1] is the comparison of tcltk nviz and wxNviz functionality,
feel free to edit it.

Anna

[1] 
http://grass.osgeo.org/wiki/WxNviz#Comparison_of_Tcl.2FTk_nviz_and_wxNviz_functionality

>
> Martin
>
> [1] http://grass.osgeo.org/wiki/WxNviz
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] composer preview

[Anna Kratochvílová]

On Fri, Oct 26, 2012 at 12:23 AM, Michael Barton  wrote:
>
> So that was easier to test than I thought. I had not reinstalled X11 on one 
> of my computers since updating to OS X 10.8. Even with PIL installed, here is 
> what happens:
>
> 1. When I click the preview button, I get the following screen.
>
>
> If I click "continue" it takes me to the XQuartz project site to install 
> XQuartz. If I click cancel, I get the following error:
>
>
> So this is a PIL/Ghostscript/X11 issue. Note that Ghostscript IS installed on 
> my Mac by default.
>
> After installing a XQuartz, the composer preview works. This is not a huge 
> problem on the Mac then, but it seems like people should not need to install 
> X11 solely for converting pdf2png. No other way?

I don't know how Ghostscript handles PostScript and why is X11 needed.
And I can't see any way to change it.

Anna

>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
> On Oct 25, 2012, at 1:13 PM, Anna Kratochvílová 
>  wrote:
>
> On Thu, Oct 25, 2012 at 6:49 PM, Michael Barton  
> wrote:
>
> Anna,
>
> I am happy to test. But composer preview has worked for me in the past once I 
> installed PIL. I do have Ghostscript. I installed it manually long ago, but 
> I'm pretty sure that it comes with the Mac OS these days.
>
>
> I thougt the preview was not working for you because of the ticket
> [1]. If it is working there is probably nothing to test.
>
> Thanks anyway,
> Anna
>
>
> [1] http://trac.osgeo.org/grass/ticket/1715
>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
> On Oct 25, 2012, at 12:11 AM, Anna Kratochvílová 
> wrote:
>
> Hi Michael,
>
> could you do a test for me with the cartographic composer? The preview
> can be broken for several reasons [1]. Could you check that you have
> Ghostscript installed? Then, if you have it, try if it is on the PATH.
> If not, could you put it on the PATH? Then it could work on Mac. But
> there is probably no chance to make it work on Windows.
>
> Thanks,
>
> Anna
>
> [1] http://trac.osgeo.org/grass/ticket/1554#comment:5
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r53518 - grass/trunk/lib/temporal/lib

[Anna Kratochvílová]

On Sun, Oct 21, 2012 at 8:03 PM, Vaclav Petras  wrote:
>>
>> Sorry for confusion, should i disable the message?
>>
> I consider it as confusing (for user) only when starting GUI. When
> using t.* module I would expect some t-related messages.

I moved the init function so that it is called only for gui forms with
temporal element types (r53520).

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

Re: [GRASS-dev] [GRASS-SVN] r53518 - grass/trunk/lib/temporal/lib

[Anna Kratochvílová]

On Sun, Oct 21, 2012 at 6:49 PM, Martin Landa  wrote:
> Hi,
>
> 2012/10/21 Anna Kratochvílová :
>
>> Default TGIS driver / database set to:
>> driver: sqlite
>> database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db
>>
>> this is G_important_message and comes from
>> lib/temporal/t.connect/main.c. As I understand it, you get it only for
>> the first time when the temporal database is created so it should stay
>> there.
>
> probably it should be done when user runs any t.* for the first time.

I think, this is the implemented behaviour, maybe Soeren can explain it better.

Anna

> Otherwise it's not necessary and for some users can be confusing.
>
> Martin
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r53518 - grass/trunk/lib/temporal/lib

[Anna Kratochvílová]

On Sun, Oct 21, 2012 at 6:27 PM, Martin Landa  wrote:
> 2012/10/21 Markus Neteler :
> debug level 0 seems to be illegal.

 Why this?
>>>
>>> then this debug message will be printed *always*.
>>
>> That looks like a bug in this case.
>
> well, `g.gisenv set=DEBUG=-1` will work. But AFAIR we used `DEBUG=0`
> to turn off all debug messages. So first legal level should be 1.
>
>>> In the manual we
>>> claim that `g.gisenv set=DEBUG=0` turn of all debug messages.
>>
>> Yes, so I would expect G_debug(0, ...) to behave like this.
>
> DEBUG=0 defines first printed debug level. So DEBUG=0 indicates that
> all debug messages with level >= 0 will be printed out.
>
> I think that `G_debug(0, ...)` should be changed to `G_debug(1, ...)`
> in the code.
>
> Martin


btw, this change of the debug level is not related do the message
(Michael was asking about):

Default TGIS driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/PERMANENT/tgis.db

this is G_important_message and comes from
lib/temporal/t.connect/main.c. As I understand it, you get it only for
the first time when the temporal database is created so it should stay
there.

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

[GRASS-dev] new wxGUI Animation Tool in addons

[Anna Kratochvílová]

Hi all,

I would like to announce that new wxGUI Animation Tool is available
for testing in GRASS 7 Addons. You can install it with the g.extension
dialog (or in the command line: g.extension -s
extension=wx.animation). You can animate a series of raster maps or
better, a space time raster dataset created by the new GRASS 7
temporal framework.
Please, have a look at the videos on the wiki page [1] and the manual
page. I would like to demonstrate the functionality on some more
interesting data which I don't have, so I would be glad if someone
could help.

Best,

Anna

[1] http://grass.osgeo.org/wiki/WxPython-based_GUI_for_GRASS#Animation_Tool
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] images2gif.py in grass

[Anna Kratochvílová]

On Tue, Oct 16, 2012 at 4:23 PM, Margherita Di Leo
 wrote:
> Hi Sören,
>
> On Tue, Oct 16, 2012 at 4:15 PM, Sören Gebbert
>  wrote:
>>
>> Hi,
>> i hope i do not start a flame war. :)
>>
>> 2012/10/16 Martin Landa :
>> > Hi,
>> >
>> > 2012/10/16 Vaclav Petras :
>> >> gif is a nice simple option how to present 'moving images'. It is
>> >> widely supported and we don't need any external dependency in case of
>> >> using images2gif.py. I would like to see this option even if we were
>> >> able to export a real video.
>> >
>> > agreed, Martin
>>
>> IMHO animated GIF's have so many limitations i wouldn't support it for
>> GIS related map animations at all. The results will be to horrible.
>>
>> Some arguments against it:
>> * Very small color range support: 8 bit per pixel == 256 colors for a
>> picture
>> * True color is only supported when creating 256 bit tiles in a single
>> picture,
>>   each tile can use different parts of a 24 bit RGB color space
>> * Only suitable for small animations and low-resolution film clips
>> * No control over animation frame rate/animation flow/pausing while
>> playing GIF's
>>
>>
> GIF's have also pro's, for example I use them in presentations, they usually
> are more handy to show than videos, you can just add them as images. Of
> course the option to export regular video as well, if technically possible,
> would be a plus.

The gif output would be something you get quickly and easily and it's
ideal for presentations (as Madi said). I would also export the
sequence of images to let the 'advanced' users make anything what they
want.

Anna


>
> Ciao madi
>
>
> --
> Margherita DI LEO
> Postdoctoral Researcher
> European Commission - DG JRC
> Forest Resources and Climate
> I-21020 Ispra (VA) - Italy - TP 261
>
> Tel. +39 0332 78 3600
> margherita.di-...@jrc.ec.europa.eu
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] images2gif.py in grass

[Anna Kratochvílová]

Where should this script be placed? It could be a grass module,
however I need to call the writeGif function directly to avoid saving
images to disk (writeGif accepts PIL images).

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

[GRASS-dev] images2gif.py in grass

[Anna Kratochvílová]

Hi,

I'm currently developing new tool for animation (wxpython-based
replacement of wxwidgets-based xganim, coming soon to addons) and I
would like to include the possibility to export the animation not only
as a sequence of images. It seems to me that the easiest possibility
is to use script images2gif.py [1] for creating animated gif, which is
under BSD license. Would it be possible to have it in grass?

Thanks,
Anna

[1] http://visvis.googlecode.com/hg/vvmovie/images2gif.py
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS6.4.3svn d.his maps from different mapsets

[Anna Kratochvílová]

Hi Helena,

On Thu, Sep 20, 2012 at 5:37 AM, Helena Mitasova  wrote:
> It appears that d.his does not work when the map layers are from different 
> mapsets,
> the following command which has the first map in PERMANENT and the second one 
> in mea582f2012
> expects both maps in PERMANENT
> d.his i_map=elevation_shade h_map=noise bright=30
> Command 'd.his bright=30 i_map=elevation_shade@PERMANENT
> h_map=noise@PERMANENT' failed
> Details: Raster map  not found

I hopefully fixed it in r53241. Please test also other similar
commands like d.rgb if I didn't forget about something.

> adding the mapset to the name did not help, I was still getting the error for 
> the following:
> d.his h_map=noise@mea582f2012 i_map=elevation_shade@PERMANENT bright=30
> d.his i_map=elevation_shade@PERMANENT h_map=noise@mea582f2012 bright=30

This should work (also before the fix). Maybe you could get confused
because the error message appears again after re-rendering. To avoid
this you must remove the layer or double click to open properties
dialog and fix it there.

>
> It runs OK from GUI.
> Can somebody try this out independently?
> I can file a bug report but I would like to make sure that this is not my 
> local problem,
>
> Thanks, Helena

Best,
Anna

>
>
> Helena Mitasova
> Associate Professor
> Department of Marine, Earth, and Atmospheric Sciences
> 2800 Faucette Drive, Rm. 1125 Jordan Hall
> North Carolina State University
> Raleigh, NC 27695-8208
> hmit...@ncsu.edu
>
> "All electronic mail messages in connection with State business which are 
> sent to or received by this account are subject to the NC Public Records Law 
> and may be disclosed to third parties.”
>
> On Sep 19, 2012, at 3:02 AM, Anna Kratochvílová wrote:
>
>> Hi,
>>
>> sorry for the late answer,
>>
>> On Tue, Sep 11, 2012 at 4:26 AM, Helena Mitasova  wrote:
>>> Anna,
>>>
>>> here is a more complete information:
>>>
>>> this is what I typed in and running it resulted in the error message below
>>> d.vect -c basin_50Kval
>>>
>>
>> for me it works. I try for example
>>
>> d.vect -c railroads
>>
>> and the layer is added correctly and arrow up shows you
>>
>> d.vect -c map=railroads@PERMANENT
>>
>> There shouldn't be any platform specific code so I don't understand
>> why it's not working. I tested it for both grass 6.4 and 7. Is it
>> still an issue?
>>
>> Anna
>>
>>> if you try to rerun it by retrieving it from history using up arrow it 
>>> shows this (apparently that is what I sent without checking it)
>>> d.vect map=-c basin_50Kval
>>>
>>> it works with the word map
>>> d.vect -c map=basin_50Kval
>>>
>>> or if -c is at the end
>>> d.vect map=basin_50Kval -c
>>>
>>> so it unfortunately does the same thing as d.rast,
>>>
>>> Helena
>>>
>>>
>>> On Sep 10, 2012, at 3:17 AM, Anna Kratochvílová wrote:
>>>
>>>> On Mon, Sep 10, 2012 at 3:09 AM, Helena Mitasova  wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> d.rast -o landuse96_28m cat=1,2
>>>>>>> run in command console is interpreted as follows:
>>>>>>> Command 'd.rast -l -a -n -d -u -s -e -9 -6 -_ -2 -8 -m
>>>>>>> map=-o cat=1,2' failed
>>>>>>> Details: Sorry,  is not a valid flag
>>>>>>> Sorry,  is not a valid flag
>>>>>>> Sorry,  is not a valid flag
>>>>>>> Sorry,  is not a valid flag
>>>>>>> Sorry,  is not a valid flag
>>>>>>> Sorry,  is not a valid flag
>>>>>>> Sorry,  is not a valid flag
>>>>>>> Sorry, <9> is not a valid flag
>>>>>>> Sorry, <6> is not a valid flag
>>>>>>> Sorry, <_> is not a valid flag
>>>>>>> Sorry, <2> is not a valid flag
>>>>>>> Sorry, <8> is not a valid flag
>>>>>>> Sorry,  is not a valid flag
>>>>>>>
>>>>>>> d.rast landuse96_28m cat=1,2 -o works fine.
>>>>>>
>>>>>> I tried to fix it so it should work now. I hope I didn't break
>>>>>> something else, this is quite difficult to test.
>>>>>
>>>>> does this fix solve also the flags with d.vect? For example I get
>>>>> d.vect map=-c basin_50Kval
>>>>
>&g

Re: [GRASS-dev] GRASS6.4.3svn d.rast -o, d.vect -c, clarification

[Anna Kratochvílová]

Hi,

sorry for the late answer,

On Tue, Sep 11, 2012 at 4:26 AM, Helena Mitasova  wrote:
> Anna,
>
> here is a more complete information:
>
> this is what I typed in and running it resulted in the error message below
> d.vect -c basin_50Kval
>

for me it works. I try for example

d.vect -c railroads

and the layer is added correctly and arrow up shows you

d.vect -c map=railroads@PERMANENT

There shouldn't be any platform specific code so I don't understand
why it's not working. I tested it for both grass 6.4 and 7. Is it
still an issue?

Anna

> if you try to rerun it by retrieving it from history using up arrow it shows 
> this (apparently that is what I sent without checking it)
> d.vect map=-c basin_50Kval
>
> it works with the word map
> d.vect -c map=basin_50Kval
>
> or if -c is at the end
> d.vect map=basin_50Kval -c
>
> so it unfortunately does the same thing as d.rast,
>
> Helena
>
>
> On Sep 10, 2012, at 3:17 AM, Anna Kratochvílová wrote:
>
>> On Mon, Sep 10, 2012 at 3:09 AM, Helena Mitasova  wrote:
>>>>
>>>>
>>>>>
>>>>> d.rast -o landuse96_28m cat=1,2
>>>>> run in command console is interpreted as follows:
>>>>> Command 'd.rast -l -a -n -d -u -s -e -9 -6 -_ -2 -8 -m
>>>>> map=-o cat=1,2' failed
>>>>> Details: Sorry,  is not a valid flag
>>>>> Sorry,  is not a valid flag
>>>>> Sorry,  is not a valid flag
>>>>> Sorry,  is not a valid flag
>>>>> Sorry,  is not a valid flag
>>>>> Sorry,  is not a valid flag
>>>>> Sorry,  is not a valid flag
>>>>> Sorry, <9> is not a valid flag
>>>>> Sorry, <6> is not a valid flag
>>>>> Sorry, <_> is not a valid flag
>>>>> Sorry, <2> is not a valid flag
>>>>> Sorry, <8> is not a valid flag
>>>>> Sorry,  is not a valid flag
>>>>>
>>>>> d.rast landuse96_28m cat=1,2 -o works fine.
>>>>
>>>> I tried to fix it so it should work now. I hope I didn't break
>>>> something else, this is quite difficult to test.
>>>
>>> does this fix solve also the flags with d.vect? For example I get
>>> d.vect map=-c basin_50Kval
>>
>> This should probably be  d.vect -c  map=basin_50Kval? This case works.
>> "d.vect map=-c basin_50Kval" is bad input and it would be difficult to
>> handle  all wrong inputs.
>>
>>>
>>>> Command 'd.vect -b -a -s -i -n -_ -5 -0 -K -v -a -l map=-c'
>>>> failed
>>>> Details: Sorry,  is not a valid flag
>>>> Sorry,  is not a valid flag
>>>> Sorry,  is not a valid flag
>>>> Sorry, <_> is not a valid flag
>>>> Sorry, <5> is not a valid flag
>>>> Sorry, <0> is not a valid flag
>>>> Sorry,  is not a valid flag
>>>> Sorry,  is not a valid flag
>>>
>>> Thanks a lot.
>>>
>>> I think I have written that the color fill on cutting planes does not work 
>>> on windows - I tried it again and it works great,
>>> We just worked in class with wxnviz last week and we did not have any 
>>> problems on 20+ computers and laptops
>>> running windows and Mac OSX, so that is fantastic, given how new the GUI is.
>>>
>>
>> I'm glad to hear that.
>>
>>> Also, this is the first year that I haven't seen many complaints about 
>>> import/export of raster and vector data,
>>> so that is a great improvement too.
>>> The only comment I have seen so far was lack of Browse button when 
>>> selecting the directory for v.out.ogr output,
>>> I am wondering whether it is intentional due to some technical issues or 
>>> just an oversight,
>>> given that r.out.gdal has such option.
>>
>> I don't know, the gui respects that the dsn option is string and not
>> file. There is probably some difference but someone would know this
>> better.
>>
>> Anna
>>
>>>
>>> Helena
>>>
>>>>>
>>>>> add volume still does not open dialog
>>>>
>>>> Maybe someone else (who is more familiar with PATH and Makefiles) could 
>>>> help?
>>>>
>>>> Anna
>>>>
>>>>>
>>>>> I am running Michaels Mac binary,
>>>>>
>>>>> Helena
>>>>>
>>>>>
>>>>>
>>>>> Helena Mitasova
>>>>> Associate Professor
>>>>> Department of Marine, Earth, and Atmospheric Sciences
>>>>> 2800 Faucette Drive, Rm. 1125 Jordan Hall
>>>>> North Carolina State University
>>>>> Raleigh, NC 27695-8208
>>>>> hmit...@ncsu.edu
>>>>>
>>>>> "All electronic mail messages in connection with State business which are 
>>>>> sent to or received by this account are subject to the NC Public Records 
>>>>> Law and may be disclosed to third parties.”
>>>>>
>>>>>
>>>>> ___
>>>>> grass-dev mailing list
>>>>> grass-dev@lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error and Warning in GUI

[Anna Kratochvílová]

Hi,

On Mon, Sep 17, 2012 at 4:26 AM, Helena Mitasova  wrote:
> in GRASS6.4.3 I noticed that an error message shows up in red with ERROR in 
> the GIS manager output window
> while warning just shows the text in blue but the word WARNING is missing (it 
> shows up when running this in shell)

It's good you noticed it, it was a typo [1], now it's working.

Anna

[1] http://trac.osgeo.org/grass/changeset/53204


> This is causing confusion - students do not know what the message means - is 
> that a problem or can they ignore it?
> Would it be possible to add the word WARNING so that the message is 
> consistent with the shell and with the
> ERROR message.
> here is an example of what I am talking about:
>
> r.average base=zipcodes cover=elevation out=elev_avgzip
> ERROR: option :  exists.
>
> r.average base=zipcodes cover=elevation out=elev_avgzip2
> r.stats:
> Cats for raster map  are either missing or have no 
> explicit labels. Using nsteps=255.
> r.recode:
> r.recode complete. Raster map  created.
>
> Thank you, Helena
>
>
> Helena Mitasova
> Associate Professor
> Department of Marine, Earth, and Atmospheric Sciences
> 2800 Faucette Drive, Rm. 1125 Jordan Hall
> North Carolina State University
> Raleigh, NC 27695-8208
> hmit...@ncsu.edu
>
> "All electronic mail messages in connection with State business which are 
> sent to or received by this account are subject to the NC Public Records Law 
> and may be disclosed to third parties.”
>
> On Aug 28, 2012, at 11:28 AM, Markus Neteler wrote:
>
>> On Fri, Aug 24, 2012 at 10:53 AM, Peter Löwe  wrote:
>> ...
>>> Maybe this would be a good place to collect such kind of info:
>>> http://grass.osgeo.org/wiki/GRASS_GIS_Performance
>>>
>>> FWIW I included a section on the limitation concerning "vectors with LOTS of
>>> attributes". I just ran into that concrete wall the other day.
>>
>> For the record, I have updated
>> http://grass.osgeo.org/wiki/GRASS_GIS_Performance#Maximum_Number_of_Attribute_Columns
>>
>> Note that it is a DB backend limit which subsequently constraints GRASS GIS. 
>> You
>> can use a recompiled SQLite backend to manage *many* columns (see link in
>> Wiki page above).
>>
>> best,
>> Markus
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS6.4.3svn d.rast -o, d.vect -c, Browse for v.out.ogr

[Anna Kratochvílová]

On Mon, Sep 10, 2012 at 3:09 AM, Helena Mitasova  wrote:
>>
>>
>>>
>>> d.rast -o landuse96_28m cat=1,2
>>> run in command console is interpreted as follows:
>>> Command 'd.rast -l -a -n -d -u -s -e -9 -6 -_ -2 -8 -m
>>> map=-o cat=1,2' failed
>>> Details: Sorry,  is not a valid flag
>>> Sorry,  is not a valid flag
>>> Sorry,  is not a valid flag
>>> Sorry,  is not a valid flag
>>> Sorry,  is not a valid flag
>>> Sorry,  is not a valid flag
>>> Sorry,  is not a valid flag
>>> Sorry, <9> is not a valid flag
>>> Sorry, <6> is not a valid flag
>>> Sorry, <_> is not a valid flag
>>> Sorry, <2> is not a valid flag
>>> Sorry, <8> is not a valid flag
>>> Sorry,  is not a valid flag
>>>
>>> d.rast landuse96_28m cat=1,2 -o works fine.
>>
>> I tried to fix it so it should work now. I hope I didn't break
>> something else, this is quite difficult to test.
>
> does this fix solve also the flags with d.vect? For example I get
> d.vect map=-c basin_50Kval

This should probably be  d.vect -c  map=basin_50Kval? This case works.
"d.vect map=-c basin_50Kval" is bad input and it would be difficult to
handle  all wrong inputs.

>
>> Command 'd.vect -b -a -s -i -n -_ -5 -0 -K -v -a -l map=-c'
>> failed
>> Details: Sorry,  is not a valid flag
>> Sorry,  is not a valid flag
>> Sorry,  is not a valid flag
>> Sorry, <_> is not a valid flag
>> Sorry, <5> is not a valid flag
>> Sorry, <0> is not a valid flag
>> Sorry,  is not a valid flag
>> Sorry,  is not a valid flag
>
> Thanks a lot.
>
> I think I have written that the color fill on cutting planes does not work on 
> windows - I tried it again and it works great,
> We just worked in class with wxnviz last week and we did not have any 
> problems on 20+ computers and laptops
> running windows and Mac OSX, so that is fantastic, given how new the GUI is.
>

I'm glad to hear that.

> Also, this is the first year that I haven't seen many complaints about 
> import/export of raster and vector data,
> so that is a great improvement too.
> The only comment I have seen so far was lack of Browse button when selecting 
> the directory for v.out.ogr output,
> I am wondering whether it is intentional due to some technical issues or just 
> an oversight,
> given that r.out.gdal has such option.

I don't know, the gui respects that the dsn option is string and not
file. There is probably some difference but someone would know this
better.

Anna

>
> Helena
>
>>>
>>> add volume still does not open dialog
>>
>> Maybe someone else (who is more familiar with PATH and Makefiles) could help?
>>
>> Anna
>>
>>>
>>> I am running Michaels Mac binary,
>>>
>>> Helena
>>>
>>>
>>>
>>> Helena Mitasova
>>> Associate Professor
>>> Department of Marine, Earth, and Atmospheric Sciences
>>> 2800 Faucette Drive, Rm. 1125 Jordan Hall
>>> North Carolina State University
>>> Raleigh, NC 27695-8208
>>> hmit...@ncsu.edu
>>>
>>> "All electronic mail messages in connection with State business which are 
>>> sent to or received by this account are subject to the NC Public Records 
>>> Law and may be disclosed to third parties.”
>>>
>>>
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] winGRASS 6.4.svn: Attribute manager not opening

[Anna Kratochvílová]

Hi,

On Sun, Sep 9, 2012 at 1:15 PM, Hamish  wrote:
> Hi,
>
> does this have to do with parsing the vector/$MAP/dbln file?
>
> There was an unfortunate thing in the 6.x format spec of that file where
> space was used as the delimiter and it was impossible to fix for spaces
> in the path, since the result would always be ambiguous. In GRASS 7 I
> changed the delim to '|', and AFAIR backported read-support for that back
> to grass6. If that sounds like the issue let me know and I'll dig out
> more details about it, and how to work around it so it works cleanly
> in all branches in a backwarks-forwards compatible way.
>
> Note that for the dbln file the C code looks for and substitutes for
>   $GISDBASE/$LOCATION_NAME/$MAPSET/
> on all platforms, they are simulated enviro variables and for file-
> system portability should be kept in the above form instead of replacing
> with a real path. (unless that's really what you want to do)
>

This doesn't seem related. I explained the problem in the mail above
but I can try to explain it more clearly if needed.

>
>> I recently added the fs parameter to be able to open data
>> which contain | character by changing the separator in
>> preferences.
>
> sorry, this email thread got lost in the pile. where/what specifically
> are you talking about there?
>

Here is the ticket:
http://trac.osgeo.org/grass/ticket/1633

Anna

>
> Hamish
>
> [sorry for the top posting, broken linewrap, and missing authors, too
> late to fight with yahoo tonight]
>
>> > when loading "roadsmajor" of NC on various windows
>> machines (with
>> > and without white space in the grassdata path, we get
>> >
>> > Error:
>> > 'columns' is not recognized as an internal or external
>> command,
>> > operable program or batch file
>> > [OK]
>> >
>> > Then the attrib. manager opens but it remains empty.
>> >
>> > Maybe here?
>> >
>> > dbmgr/manager.py
>> > ...
>> >
>> self.listOfCommands.append(('v.db.addcol',
>> >
>>
>>  { 'map' :
>> self.vectorName,
>> >
>>
>>'layer'   :
>> self.layer,
>> >
>>
>>'columns' : '%s %s' % (name,
>> ctype) }
>> >
>>
>>  ))
>> >
>> > No idea..
>> >
>> > Markus
>>
>> Problem occurs when calling this (line 194, dbmgr/manager.py
>> in grass64)
>>
>> ret = RunCommand('v.db.select',
>>
>>
>>quiet = True,
>>
>>
>>parent = self,
>>
>>
>>flags = 'c',
>>
>>
>>map = self.mapDBInfo.map,
>>
>>
>>layer = layer,
>>
>>
>>columns = ','.join(columns),
>>
>>
>>fs = fs,
>>
>>
>>where = where,
>>
>>
>>stdout = outFile)
>>
>> I recently added the fs parameter to be able to open data
>> which contain | character by changing the separator in
>> preferences. On
>> Windows it is causing splitting the whole command into 2
>> parts -
>> before and after pipe. As a result 'columns' parameter
>> (after pipe) is
>> treated like another command. As a temporal workaround you
>> can set the
>> separator to something different in preferences (more
>> characters are
>> accepted)  - this should work immediately. I can also
>> revert the
>> change.
>>
>> On Linux the characters in parameters are escaped properly
>> probably in
>> Popen but not on Windows. Anyone knows how to solve this
>> properly?
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS6.4.3svn d.rast -o, region in wxnviz

[Anna Kratochvílová]

Hi,

On Wed, Sep 5, 2012 at 6:01 AM, Helena Mitasova  wrote:
> So far everything seems to be running quite well in 6.4.3, except for some 
> cosmetics
> that I will collect and report together and the following two issues 
> (probably not quite bugs but
> a confusing behavior):
>
> wxnviz: if a new region is set, zoom to computational region adjusts the 
> display and nviz respects the new region, but wxnviz does not,
> I had to quit GRASS with new region to get wxnviz respect it.

In grass 7 this works but not in grass 6.x because when I backported
wxNviz I wasn't able to backport also the part related to resetting
the region (G_unset_region is needed). This would need some changes in
gis library which I don't want to do, the differences between 6.x and
7 are quite large.

>
> d.rast -o landuse96_28m cat=1,2
> run in command console is interpreted as follows:
> Command 'd.rast -l -a -n -d -u -s -e -9 -6 -_ -2 -8 -m
> map=-o cat=1,2' failed
> Details: Sorry,  is not a valid flag
> Sorry,  is not a valid flag
> Sorry,  is not a valid flag
> Sorry,  is not a valid flag
> Sorry,  is not a valid flag
> Sorry,  is not a valid flag
> Sorry,  is not a valid flag
> Sorry, <9> is not a valid flag
> Sorry, <6> is not a valid flag
> Sorry, <_> is not a valid flag
> Sorry, <2> is not a valid flag
> Sorry, <8> is not a valid flag
> Sorry,  is not a valid flag
>
> d.rast landuse96_28m cat=1,2 -o works fine.

I tried to fix it so it should work now. I hope I didn't break
something else, this is quite difficult to test.

>
> add volume still does not open dialog

Maybe someone else (who is more familiar with PATH and Makefiles) could help?

Anna

>
> I am running Michaels Mac binary,
>
> Helena
>
>
>
> Helena Mitasova
> Associate Professor
> Department of Marine, Earth, and Atmospheric Sciences
> 2800 Faucette Drive, Rm. 1125 Jordan Hall
> North Carolina State University
> Raleigh, NC 27695-8208
> hmit...@ncsu.edu
>
> "All electronic mail messages in connection with State business which are 
> sent to or received by this account are subject to the NC Public Records Law 
> and may be disclosed to third parties.”
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] winGRASS 6.4.svn: Attribute manager not opening

[Anna Kratochvílová]

On Tue, Sep 4, 2012 at 11:04 AM, Markus Neteler  wrote:
> Hi,
>
> when loading "roadsmajor" of NC on various windows machines (with
> and without white space in the grassdata path, we get
>
> Error:
> 'columns' is not recognized as an internal or external command,
> operable program or batch file
> [OK]
>
> Then the attrib. manager opens but it remains empty.
>
> Maybe here?
>
> dbmgr/manager.py
> ...
>self.listOfCommands.append(('v.db.addcol',
> { 'map' : self.vectorName,
>   'layer'   : self.layer,
>   'columns' : '%s %s' % (name, ctype) }
> ))
>
> No idea..
>
> Markus

Problem occurs when calling this (line 194, dbmgr/manager.py in grass64)

ret = RunCommand('v.db.select',
 quiet = True,
 parent = self,
 flags = 'c',
 map = self.mapDBInfo.map,
 layer = layer,
 columns = ','.join(columns),
 fs = fs,
 where = where,
 stdout = outFile)

I recently added the fs parameter to be able to open data which
contain | character by changing the separator in preferences. On
Windows it is causing splitting the whole command into 2 parts -
before and after pipe. As a result 'columns' parameter (after pipe) is
treated like another command. As a temporal workaround you can set the
separator to something different in preferences (more characters are
accepted)  - this should work immediately. I can also revert the
change.

On Linux the characters in parameters are escaped properly probably in
Popen but not on Windows. Anyone knows how to solve this properly?

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

Re: [GRASS-dev] g.extension continued problems

[Anna Kratochvílová]

Hi,

it works for me even though I don't have pandoc:

g.extension extension=g.copyall
svnurl=http://svn.osgeo.org/grass/grass-addons/grass7
Fetching  from GRASS-Addons SVN (be patient)...
Compiling...
/bin/sh: pandoc: not found
Installing...
Updating metadata file...
Installation of  successfully finished

Anna

On Tue, Sep 4, 2012 at 12:18 AM, Michael Barton  wrote:
> I thought that the discussion ended with this being optional not a 
> requirement. Is this something that all *users* must now install as a new 
> dependency or is this just something that binary maintainers have to mess 
> with? Dependencies are a big pain for Mac and Windows users.
>
> Also, as you imply, the lack of this should not affect whether or not the 
> extension is installed.
>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
> On Sep 3, 2012, at 3:07 PM, Markus Neteler 
>  wrote:
>
>> On Tue, Sep 4, 2012 at 12:02 AM, Michael Barton  
>> wrote:
>>> I just tried to install a script I added to addons yesterday as a test for
>>> my students. I did this in GRASS 7.
>>>
>>> Here is the result:
>>>
>>> Fetching  from GRASS-Addons SVN (be patient)...
>>> Compiling...
>>> /bin/sh: pandoc: command not found
>>
>> You need to install "pandoc" for the REST based new manual.
>> http://johnmacfarlane.net/pandoc/
>>
>> Of course GRASS 7 should be more friendly when pandoc does not exist!
>>
>> Markus
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] how to represent an argument as a variable in a grass python command

[Anna Kratochvílová]

On Sun, Sep 2, 2012 at 11:04 PM, Michael Barton  wrote:
> I'm trying to do a script that calls g.copy
>
> I want the user to be able to select which type of data to copy. So instead
> of specifying:
>
> grass.run_command('g.copy', rast='%s,%s' % (input, output))
>
> I'd like to something equivalent to:
>
> grass.run_command('g.copy', '%s=%s,%s' % (datatype, input, output))
>
> where datatype is the form of grass data to copy (eg, rast, vect, etc)
>
> The way I'd like to do this doesn't work. So what is the correct syntax
> here?

Create a dictionary first:

dataType = 'rast'
params = {dataType: '%s,%s' % (input, output)}
grass.run_command('g.copy', **params)

Maybe someone comes up with something better but this works.

Anna


>
> Thanks
> Michael
>
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] command dialog notebook styles

[Anna Kratochvílová]

On Wed, Aug 29, 2012 at 10:52 AM, Helmut Kudrnovsky  wrote:
> hi,
>
>>> fancygreen => all tabs with content, manual ok
>>> basicleft => all tabs with content, but no manual
>>
>>manual should work now for the 'list left' style (but i hope we can
>>come up with some better name...)
>
> the manual works now.
>
>>> the other two => all tabs empty, no manual

Please test it again, I've just did some changes which (I hope) should help.

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

Re: [GRASS-dev] command dialog notebook styles

[Anna Kratochvílová]

Hi,

On Mon, Aug 27, 2012 at 7:25 PM, Helmut Kudrnovsky  wrote:
>>One more question, all the tabs are empty? Command output and manual
>>tab are created separately so there could be some difference.
>
> fancygreen => all tabs with content, manual ok
> basicleft => all tabs with content, but no manual

manual should work now for the 'list left' style (but i hope we can
come up with some better name...)

>
> the other two => all tabs empty, no manual

I did some change (just a guess) so you can test again.

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

Re: [GRASS-dev] adding volume layer in 6.4.3 and 7 binaries

[Anna Kratochvílová]

Hi,

I get the same error on Linux, too (6.4 compiled today). In 7 it's ok.
I fixed only the error raising so that you can get the original
problem:

Unable to fetch interface description for command
'd.rast3d'.
Details: [Errno 2] No such file or directory

So it cannot find the command. I couldn't find any solution, maybe
someone else knows what's going on?
I found related ticket here [1].

Anna

[1] http://trac.osgeo.org/grass/ticket/1515

On Tue, Aug 28, 2012 at 6:11 AM, Helena Mitasova  wrote:
> Interestingly enough, I can add a volume and visualize it on my selfcompiled 
> grass7 from august 7
> and on grass6.4.3 compiled today I can add a volume as well, however I don't 
> get the 3D view mode,
> because of the error below (which I assume is my local problem, tcltk nviz 
> does not work either,
> I have seen that error before).
>
> Helena
>
> 3D view mode: 
> dlopen(/Users/helena/grassrel6/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.6.4.3svn.dylib,
>  10): no suitable image found.  Did find:
> 
> /Users/helena/grassrel6/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.6.4.3svn.dylib:
>  mach-o, but wrong architecture
> 
> /Users/helena/grassrel6/GRASS-6.4.app/Contents/MacOS/lib/libgrass_gis.6.4.3svn.dylib:
>  mach-o, but wrong architecture
>
> Helena Mitasova
> Associate Professor
> Department of Marine, Earth, and Atmospheric Sciences
> 2800 Faucette Drive, Rm. 1125 Jordan Hall
> North Carolina State University
> Raleigh, NC 27695-8208
> hmit...@ncsu.edu
>
> "All electronic mail messages in connection with State business which are 
> sent to or received by this account are subject to the NC Public Records Law 
> and may be disclosed to third parties.”
>
> On Aug 27, 2012, at 5:22 PM, Michael Barton wrote:
>
>> Just tried adding a 3D raster to GRASS 6.4.3 compiled last Friday (23 
>> August). It has the same error you note. This is a blocker for release.
>>
>> Michael
>> 
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>>
>> voice:480-965-6262 (SHESC), 480-727-9746 (CSDC)
>> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Aug 27, 2012, at 11:47 AM, Helena Mitasova  wrote:
>>
>>> In the Windows binaries for 6.4.3 and 7. and in Michael's binaries for
>>> 6.4.3 when I try to add a 3D raster
>>> to Map layers I get the following error (see bellow) and the dialog
>>> does not open.
>>> It works in GRASS7 I compiled some time ago.
>>> Michael, have you tried to add a 3D raster into any of your binaries
>>> versions of GRASS?
>>> Does it work for you?
>>>
>>> Thanks, Helena
>>>
>>>
>>> Traceback (most recent call last):
>>> File "/Applications/GRASS/GRASS-6.4.app/Contents/MacOS/etc
>>> /wxpython/lmgr/frame.py", line 1541, in OnAddRaster3D
>>>
>>> self.curr_page.maptree.AddLayer('3d-raster')
>>> File "/Applications/GRASS/GRASS-6.4.app/Contents/MacOS/etc
>>> /wxpython/lmgr/layertree.py", line 902, in AddLayer
>>>
>>> self.PropertiesDialog(layer, show = True)
>>> File "/Applications/GRASS/GRASS-6.4.app/Contents/MacOS/etc
>>> /wxpython/lmgr/layertree.py", line 1016, in PropertiesDialog
>>>
>>> completed = (self.GetOptData,layer,params))
>>> File "/Applications/GRASS/GRASS-6.4.app/Contents/MacOS/etc
>>> /wxpython/gui_core/forms.py", line 1841, in ParseCommand
>>>
>>> raise gcmd.GException(e)
>>> core.gcmd
>>> .
>>> GException
>>> On Sun, Aug 26, 2012 at 4:43 AM, Martin Landa  
>>> wrote:
 Hi,

 6.4.3 is planned for September. As I wrote earlier creating release
 branch for G7 at this stage of development is too early (from my POV).
 I would say that we could create this branch later in the beginning of
 2013. It's not really connected to GRASS 6.

 Martin

 2012/8/26 Michael Barton :
> OK. Then after 6.4.3.
>
> Even better
>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
> fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
> On Aug 26, 2012, at 1:26 AM, Martin Landa wrote:
>
>> 2012/8/25 Michael Barton :
>>> My suggestion was to start a GRASS 7 release branch and stop adding new
>>> features to 6.x *after* 6.4.4 stable is released. Too complicated to 
>>> work on
>>> 2 active release branches at the same time.
>>
>> why after 6.4.4? The next release is also stable release (6.4.3). Only
>> the second number in version determines stable and technical preview
>>

Re: [GRASS-dev] command dialog notebook styles

[Anna Kratochvílová]

One more question, all the tabs are empty? Command output and manual
tab are created separately so there could be some difference.

Thanks,
Anna

On Mon, Aug 27, 2012 at 6:52 PM, Anna Kratochvílová
 wrote:
> On Mon, Aug 27, 2012 at 5:52 PM, Helmut Kudrnovsky  wrote:
>>>is there any related wiki-page, where screenshots (i.e. windows, etc.) can
>> be uploaded?
>>
>> tested here in osgeo4w-wingrass7 in a win7-64bit-box.
>>
>> only listleft works, in the other two no input is possible.
>
> That's bad. I am not able to test it. Are you able to switch the tabs?
> Maybe it's some problem with refreshing. I tried to google some
> windows specific problems with wx.Notebook but I haven't found
> anything interesting.
>
> The current fancy style works ok, is it right?
>
> I will wait if the similar problem occurs on Mac to (Michael promised to test)
>
> Thanks for testing,
>
> Anna
>
>>
>> Helmut
>> http://osgeo-org.1560.n6.nabble.com/file/n4998104/notebookstyle_windows_listleft.png
>> notebookstyle_windows_listleft.png
>> http://osgeo-org.1560.n6.nabble.com/file/n4998104/notebookstyle_windows_basictop.png
>> notebookstyle_windows_basictop.png
>> http://osgeo-org.1560.n6.nabble.com/file/n4998104/notebookstyle_windows_basicleft.png
>> notebookstyle_windows_basicleft.png
>>
>> Helmut
>>
>>
>>
>> -
>> best regards
>> Helmut
>> --
>> View this message in context: 
>> http://osgeo-org.1560.n6.nabble.com/command-dialog-notebook-styles-tp4997929p4998104.html
>> Sent from the Grass - Dev mailing list archive at Nabble.com.
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] command dialog notebook styles

[Anna Kratochvílová]

On Mon, Aug 27, 2012 at 5:52 PM, Helmut Kudrnovsky  wrote:
>>is there any related wiki-page, where screenshots (i.e. windows, etc.) can
> be uploaded?
>
> tested here in osgeo4w-wingrass7 in a win7-64bit-box.
>
> only listleft works, in the other two no input is possible.

That's bad. I am not able to test it. Are you able to switch the tabs?
Maybe it's some problem with refreshing. I tried to google some
windows specific problems with wx.Notebook but I haven't found
anything interesting.

The current fancy style works ok, is it right?

I will wait if the similar problem occurs on Mac to (Michael promised to test)

Thanks for testing,

Anna

>
> Helmut
> http://osgeo-org.1560.n6.nabble.com/file/n4998104/notebookstyle_windows_listleft.png
> notebookstyle_windows_listleft.png
> http://osgeo-org.1560.n6.nabble.com/file/n4998104/notebookstyle_windows_basictop.png
> notebookstyle_windows_basictop.png
> http://osgeo-org.1560.n6.nabble.com/file/n4998104/notebookstyle_windows_basicleft.png
> notebookstyle_windows_basicleft.png
>
> Helmut
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.n6.nabble.com/command-dialog-notebook-styles-tp4997929p4998104.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS-user] command dialog notebook styles

[Anna Kratochvílová]

Hi Michael,

I hope you don't mind adding this discussion to mailing list.

On Mon, Aug 27, 2012 at 12:15 AM, Michael Barton  wrote:
> These look nice. I will try to test late in the week when I have time to
> recompile.
>
> A couple thoughts.
>
> Multiple options like this give users more flexibility for customizing the
> look of the program. And if it solves the hidden tab problem, that can be a
> benefit to use. On the other hand, adding too many options adds more
> complexity to an already very very complex GUI code, with more opportunities
> for something to go wrong.

Once the initial bugs are fixed (I hope there are not many) the code
should be quite stable because all notebooks have very similar or
identical API so   in the code you just switch classes representing
the notebook styles and that's all.

>
> The other thing to think about is that there is an advantage to having a
> consistent GRASS brand and look across all platforms. That was the idea
> behind the gradient green bar behind the tabs. (I forget who first suggested
> flatnotebook, but I liked them because they were distinctive and not as
> 'boring' as the normal rectangular ones that are on almost all other apps).
> Perhaps  there are better ways of switching pages than flatnotebook style.
> Having the tabs go down the left may be better for example, though it makes
> dialogs wider and hence eats up more screen real estate. Anyway, after some
> experimentation, even if switching to a new tab style there is some benefit
> to settling on a standard style that is the GRASS brand.

> Can flatnotebook do tabs on the left?

I'am afraid that it is not possible.

The point is to let the user choose what he wants. The current tabs
don't look boring but I'm sure a lot of people would prefer standard
'boring' notebook. And still there is the issue with the hidden tabs
which can be very confusing for not experienced user. Another question
is which style should be the default one, if the nice but little
confusing or the standard one?

Thanks for comments,
Anna
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] command dialog notebook styles

[Anna Kratochvílová]

Hi Carlos,

On Sun, Aug 26, 2012 at 7:55 PM, Carlos Grohmann
 wrote:
> Anna, those are great news!

I'm glad you like it.

>
> This is, IMO, a much-needed improvement in GRASS interface. Quite a while
> ago I posted some thoughts on GUI and User Experience for GRASS, and native
> tabs do make a big difference.

Where can I find it?

>
> Can this be applied to GIS manager as well?

Yes, but we must first understand how it should look like because
there are two level of tabs (top and bottom) so they probably should
look differently. Any suggestions are welcome.

Anna

>
> best
>
> Carlos
>
>
>
>
>
>
> On Sun, Aug 26, 2012 at 2:02 PM, Anna Kratochvílová 
> wrote:
>>
>> Hi all,
>>
>> I would like to inform you that you can now switch between different
>> command dialog styles in GRASS 7 (r52927). There are 4 styles, 3 of
>> them are new and they are providing platform native look. It should
>> solve the problem described in ticket #306 [1] (hidden tabs). Styles
>> can be changed in settings dialog - Appearance tab.
>>
>> Two styles use wx.Notebook with top or left tabs. The third one which
>> uses wx.ListBook is not yet finished. The default style is the current
>> fancy green FlatNotebook.
>>
>> It would be nice to add some icons to the tabs. So far I added only
>> icons to manual and options page to get idea how it could look like.
>> Unfortunately it is quite difficult to create icons which would
>> describe the tabs (required, optional, selection, ...). But except for
>> ListBook icons are not necessary. (Now icons are not used in fancy
>> green notebook because used style is not ready for icons.)
>>
>> The advantage of the two basic styles is that they inherit system
>> colors (since they are native). So it is better for users with unusual
>> themes which are not much supported by wxPython.
>>
>> Styles were tested on Ubuntu 10.04 (Gnome), information how styles
>> look like on Windows and Mac (including comparison to other
>> applications) is appreciated.
>>
>> Please, share your ideas about style names, icons and styles itself.
>> If you know how, you can also try wxPython demo and do your own
>> experiments with various notebooks.
>>
>> Note that this feature is experimental and even though it is change of
>> style some bugs which seem to be unrelated can appear.
>>
>> Anna and Vaclav
>>
>> ___
>> grass-user mailing list
>> grass-u...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
>
> --
> Prof. Carlos Henrique Grohmann
> Institute of Geosciences - Univ. of São Paulo, Brazil
> - Digital Terrain Analysis | GIS | Remote Sensing -
>
> http://carlosgrohmann.com
> 
> Can’t stop the signal.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] saving images from display in winGRASS6.4.2

[Anna Kratochvílová]

Hi,

according to the error message I guess this problem is fixed. Some
technical details: the problem was probably caused by
wx.BufferedPaintDC which was replaced by wx.BufferedDC.

Regards,
Anna

On Wed, Aug 22, 2012 at 8:13 PM, Helena Mitasova  wrote:
> in the current stable release I am getting the the following error
> when trying to save the image from the display. We did not have the
> problem in 6.4.1 and I am wondering whether it is fixed in 6.4.3,
>
> thanks Helena
>
> Traceback (most recent call last):
>   File "C:\Program Files (x86)\GRASS
> 6.4.2\etc\wxpython\gui_modules\mapdisp.py", line 1159, in
> SaveToFile
>
> width, height)
>   File "C:\Program Files (x86)\GRASS
> 6.4.2\etc\wxpython\gui_modules\mapdisp_window.py", line 575,
> in SaveToFile
>
> dc = wx.BufferedPaintDC(self, ibuffer)
>   File "C:\Program Files (x86)\GRASS 6.4.2\Python27\lib
> \site-packages\wx-2.8-msw-unicode\wx\_gdi.py", line 4990, in
> __init__
>
> _gdi_.BufferedPaintDC_swiginit(self,_gdi_.new_BufferedPaintD
> C(*args, **kwargs))
> wx._core
> .
> PyAssertionError
> :
> C++ assertion "wxAssertFailure" failed at
> ..\..\src\msw\dcclient.cpp(219) in wxPaintDC::wxPaintDC():
> wxPaintDC may be created only in EVT_PAINT handler!
>
> On Wed, Aug 22, 2012 at 10:27 AM, Martin Landa  wrote:
>> Hi,
>>
>> 2012/8/22 Sören Gebbert :
 just check new features implemented in grass7 and you will find out
 who from developers is focused on grass7. If _we_ would be really be
>>>
>>> I have a clear focus on grass7 and do not backport any new features or
>>
>> [...]
>>
>> I didn't what to note any names. I am sure that everyone is doing his
>> best. It's free software ;-) Yeap, Soeren is one of the most active
>> grass7 devs :-)
>>
>> Martin
>>
>> --
>> Martin Landa  * http://geo.fsv.cvut.cz/~landa
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> --
> Helena Mitasova
> Associate Professor
> Department of Marine, Earth and Atmospheric Sciences
> North Carolina State University
> 1125 Jordan Hall
> NCSU Box 8208
> Raleigh, NC 27695-8208
> http://skagit.meas.ncsu.edu/~helena/
>
> email: hmit...@ncsu.edu
> ph: 919-513-1327 (no voicemail)
> fax 919 515-7802
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 6.4.3 release planning

[Anna Kratochvílová]

Hi,

> * the ps.map gui composer in unreleased svn is currently using an eps
> mode to draw north arrow decorations instead of the 'point' instruction
> directly. the redundant eps north arrows should be removed before they
> are used in an official release and the method is locked in for backwards
> compatibility. Even if no one else cares about that, I do, so it is
> probably up to me to fix & convert the better qgis north arrows to the
> grass symbol format as needed.
>

I can fix this in the composer, of course. Adding north arrow would
show a dialog for adding points (this dialog is used for adding
graphics like points, lines, rectangles) which would be slightly
modified for north arrows (like changing the dialog title and so).
Here, it would help me if the directory structure of the symbols is
changed so that the arrows would be located in separate directory
(basic, extra, ..., north_arrow). This way I can show the user only
the north arrow symbols. Other option is not very elegant - I would
have to find all symbols from all directories containing words arrow
or compass.

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

Re: [GRASS-dev] [GRASS-user] new wxGUI feature: Map Swipe

[Anna Kratochvílová]

On Thu, Aug 16, 2012 at 10:19 PM, Markus Neteler  wrote:
> On Thu, Aug 16, 2012 at 10:00 PM, Helmut Kudrnovsky  wrote:
> ...
>> I've tested it here a little bit by using the nc-sample dataset and the
>> latest available osgeo4w-wingrass7.
>
> I have added a NC sample dataset based Landsat example to
> http://grass.osgeo.org/wiki/WxGUI_Map_Swipe
>
> One observation: if you hand-write a (not-existing) map name name,
> no error pops but and that "side" of the map swipe remains empty.

I added warning there.

Thanks
Anna

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

Re: [GRASS-dev] [GRASS-user] new wxGUI feature: Map Swipe

[Anna Kratochvílová]

On Thu, Aug 16, 2012 at 10:00 PM, Helmut Kudrnovsky  wrote:
> hi Anna,
>
>>I would like to backport it soon, of course. Is there a chance someone
>>could test it on Windows first? (adding dev list)
>
> great work!
>
> I've tested it here a little bit by using the nc-sample dataset and the
> latest available osgeo4w-wingrass7.
>
> the rasters are elevation and ortho_2001_t792_1m; the extent of these
> rasters aren't identical. zoom in works, zoom out seems to be fragile.

Thanks for testing. Zoom out should work the same way as in Map
Display. Could it be caused by the different extent? Also the question
is when you are comparing two maps with different extent should there
be some warning? Because it could confuse the user. On the other hand,
different extent of maps in Map Swipe is completely valid if you are
aware of it. For me it works ok.

Regards,
Anna

>
>
> from the wiki:
>
>>Possible enhancements:
>>
>>add simplified layer manager for each window so that you can add any maps
> (raster/vector) - would it be >useful?
>
> adding any map (raster/vector) would be a very usefull enhancement.
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.n6.nabble.com/Re-GRASS-user-new-wxGUI-feature-Map-Swipe-tp4995732p4995765.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] new wxGUI feature: Map Swipe

[Anna Kratochvílová]

On Thu, Aug 16, 2012 at 5:54 PM, Martin Landa  wrote:
> Ahoj Anna,
>
> 2012/8/16 Anna Kratochvílová :
>> This tool has been tested on Linux and Mac so far. Comments are welcome.
>
> very useful tool! I am very sure that I will use it when teaching
> remote sensing course at the CTU this semester :-)
>
> Thanks, Martin
>
> PS: Any plans for backport to GRASS 6.5?

I would like to backport it soon, of course. Is there a chance someone
could test it on Windows first? (adding dev list)

Anna

>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Empty default answer

[Anna Kratochvílová]

On Tue, Aug 14, 2012 at 2:52 PM, Luca Delucchi  wrote:
> Is it correct leave empty a default answer in a module?
> An example is in r.out.pov with zmod or objmod option

According to programming manual 'answer' is not required. Also see
[1]. Maybe I am missing something but I can't see the options zmod and
objmod for that module.

Anna

[1] 
http://grass.osgeo.org/programming7/gislib.html#Answer_member_of_the_Flag_and_Option_structures


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

[GRASS-dev] translated options in descriptions

[Anna Kratochvílová]

Hi all,

I would like to point out that there was a bug in many modules (around
30) which can appear only with localised grass (fixed r52637). It
produces only warning so probably it's harmless however developers
should avoid using option descriptions in this way:

-params->query->descriptions =
-   _("length;Select only lines or boundaries shorter"
- "/longer than threshold distance;"
- "dangle;Select dangles shorter/longer than " "threshold distance");

The problems appear when the translator translates the option and not
only its description. Translatable must be only the description like
this,

+desc_query = NULL;
+G_asprintf(&desc_query,
+   "length;%s;"
+  "dangle;%s",
+  _("Select only lines or boundaries shorter"
+"/longer than threshold distance"),
+  _("Select dangles shorter/longer than threshold distance"));
+params->query->descriptions = desc_query;

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

Re: [GRASS-dev] please help review osgeo live dvd summary docs

[Anna Kratochvílová]

On Tue, Jul 24, 2012 at 4:31 AM, Hamish  wrote:
> Helena wrote:
>> the quickstart looks very nice and I did not find any major
>> problems (but other may have a look too)
>>
>> I just have couple comments:

>> As for the legend and scale - we often have trouble moving
>> around the legend with mouse after moving around the scale -
>> even if I click on the legend the mouse still picks up the
>> scale - there is a way around it but it can be frustrating for
>> the first time users. It may be safer to position the legend
>> first and the scale second but even that may be tricky. This
>> may be the case only for mac users (or perhaps windows) so it
>> may work properly on Live DVD under linux.
>
> it's on all platforms, the trick (workaround) is to think of
> the d.legend and d.barscale renderings on the wx map canvase
> as printed on a plate of glass, which is of finite size. you
> can slide those two pieces of glass around, but if you go to
> the left of the map decoration you be beyond the left side of
> the piece of glass so dragging on nothing. likewise if you
> drag off the top or the bottom of the pane of glass it won't
> move it either (which top/bottom side that is different for
> the two decorations). And finally if the legend's plate of
> glass is on top of the barscale's one, you'll only be able to
> drag the top bit of glass around, so to move the one below you
> have to move the top one out of the way, then move the bottom
> one, then move the top one back again. A well developed sense
> of spatial relations helps your imagination get it right..
> The current mechanism needs to be replaced, I'm pretty sure
> there's a ticket open for this one too.
>

I think the only way to make it work is to create some new flag in the
d.barscale and d.legend modules which prints the size of the image.
Otherwise the GUI has no information about the size, especially for
d.barscale. Something like ps.map -b flag is needed, like Hamish did
before. Would it be possible, Hamish?

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

Re: [GRASS-dev] [GRASS-SVN] r52423 - grass/trunk/gui/wxpython/xml

[Anna Kratochvílová]

On Fri, Jul 20, 2012 at 4:17 PM, Martin Landa  wrote:
> Hi,
>
> 2012/7/20  :
>> Author: annakrat
>> Date: 2012-07-20 07:01:33 -0700 (Fri, 20 Jul 2012)
>> New Revision: 52423
>>
>> Modified:
>>grass/trunk/gui/wxpython/xml/menudata.xml
>> Log:
>> wxGUI/menudata: remove command name from menu when using custom dialog (not 
>> to confuse the user)
>> @@ -207,7 +208,6 @@
>>   Converts vector layers into a GRASS vector map using 
>> OGR.
>>   vector,import
>>   OnImportOgrLayers
>> - v.in.ogr
>> 
>
> hm, after this change it will be not possible to find `v.in.ogr` in
> Layer Manager's search tab (based on command name). On the other hand
> the users probably would expect autogenerated dialog for v.in.ogr not
> a real front-end. Anyway I would suggest to keep the `command` tag in
> this case to make them searchable via Layer Manager search engine
> (key: command).

ok, I wasn't aware of that. I added instead a condition (on handler
name) in the menu.py

Anna

>
> Martin
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] d.mon rendering more layers problem

[Anna Kratochvílová]

On Tue, Jul 10, 2012 at 9:58 AM, Martin Landa  wrote:
> Hi,
>
> 2012/7/10 Anna Kratochvílová :
>> when I try to render raster and vector layer into PNG file in grass7
>> with d.mon, only the last layer is visible - I can see only the
>> vector.
>
> probably missing GRASS_PNG_READ env variable, please try r52358.

Thanks a lot, it works now

Anna
>
> Martin
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] d.mon rendering more layers problem

[Anna Kratochvílová]

Hi,

when I try to render raster and vector layer into PNG file in grass7
with d.mon, only the last layer is visible - I can see only the
vector.
I use this code in python script:

os.environ['GRASS_TRANSPARENT'] = "TRUE"
grass.run_command('d.mon', start='png', output = "testFile.png",
width = 640, height = 480, overwrite = True)
grass.run_command('d.rast',  map = 'elevation')
grass.run_command('d.vect', map = 'roadsmajor', color = 'red')
grass.run_command('d.mon', stop = 'png')

Do I miss something or it's a bug?

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

Re: [GRASS-dev] python question

[Anna Kratochvílová]

Hi,

On Sat, Jun 23, 2012 at 9:48 PM, Michael Barton  wrote:
> This is probably simple but I'm missing something somewhere. How can I
> dynamically create variable names and then assign values to the variables? I
> need to do something along the lines of:
>
> for i in flist:
> 's%_new' % i = 10
>
> where flist is a list of strings (e.g., file names)
>
>

You can find answer here:

http://stackoverflow.com/questions/2320945/python-using-vars-to-assign-a-string-to-a-variable

example of using function vars is in wxpython/gui_core/toolbars.py, line 130

Anna

> Thanks
> Michael
>
> _
> C. Michael Barton
> Visiting Scientist, Integrated Science Program
> National Center for Atmospheric Research &
> University Consortium for Atmospheric Research
> 303-497-2889 (voice)
>
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] gettext warnings

[Anna Kratochvílová]

Hi,

I would like just to remind you of the warnings which you get after
'make pot' in ./locale. The warnings came from ./lib/python/temporal.
Here is the related ticket [1] and mail discussion [2].
This problem can be solved using:

 message = _("Selected map <%(map)s> is not in current mapset <%(mapset)s>. " %
{ 'map' : self.mapName,  'mapset' :
grass.gisenv()['MAPSET'] }

Perhaps we could add a note to the SUBMITTING_PYTHON document?

Anna


[1] http://trac.osgeo.org/grass/ticket/1677
[2] http://lists.osgeo.org/pipermail/grass-dev/2012-January/057674.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] stop button in GUI?

[Anna Kratochvílová]

Hi,

On Thu, May 24, 2012 at 10:04 AM, Michael Barton  wrote:
>
> There is a "stop" button in the GUI of all modules. When I press it, the
> GUI dialog returns to a state where I can reinitiate the module process. But
> looking in my system monitor, the old process is still continuing. Is this
> the case for all systems or just the Mac? If for all systems, the "stop"
> button seems somewhat misleading.
>
> Michael

to summarize: on Linux it is not working, on Windows I cannot test.
The important part is this Popen object (core/gcmd.py):
line 540:
self.module = Popen(args,
stdin = subprocess.PIPE,
stdout = subprocess.PIPE,
stderr = subprocess.PIPE,
shell = sys.platform == "win32",
env = self.env)

and then line 578:
self.module.kill()
which doesn't work. I tried to call terminate(), for my Ubuntu it
works, however I have no idea why. This change is in r52081 in grass7,
so Micheal or anyone else, you can test it. The problem might be in
calling this Popen from thread ( which seems to be not recommended
according to some internet discussions). This is all I can do because
I really don't understand this issue.

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

Re: [GRASS-dev] broken stuff in vector modules

[Anna Kratochvílová]

Hi,

On Wed, May 23, 2012 at 4:43 PM, Michael Barton  wrote:

> 2) To get around this, I thought I'd try to get the length of the line that
> connects each site point with its nearest waterway (a v.distance option).
> But when I tried to make a new table for this in the table manager, I find
> that I cannot access the "table description" section of the "manage layers"
> page in the attribute table manager. This is again because wx.StaticBox
> needs to be defined in a particular order or the Mac interface cannot access
> it. This has been a recurrent problem with wx.StaticBox. The StaticBox must
> be instantiated before any of its contents.
>

This should be fixed now. If you find this bug elsewhere, tell me or
you can fix it easily yourself.

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

Re: [GRASS-dev] GSoC introduction

[Anna Kratochvílová]

On Mon, Apr 2, 2012 at 6:54 PM, stepan.turek  wrote:
> Hello,
>
> I would like to introduce my topic for  GSoC.
>
> My proposal for GSoC is porting of module i.ortho.photo into GRASS 7. The
> module is  based on x monitors, which support was removed  from
> GRASS 7, so
> it  is needed to integrate the ortorectification into wxGUI. The
> x-monitor
> support is related to these imaginary functions:
>     photo.2image
>     photo.2target
>
> That would be core of my work in GSoC.
>
> Waiting for your feedback! Do you consider this topic to be suitable for
> GSoC?
>
> I already have some experience
> in developing in GRASS. This semester I have
> been working on my bachelors thesis, which is focused on implementation on
> WMS support into GRASS GIS and SAGA GIS. So far I have rewritten module
> r.in.wms. This or next week the module should be accessible for testing on
> GRASS
> Addons SVN with name r.in.wms2.
>
> Thanks,
>
> Stepan
>

Ahoj Stepane,

I was working with my collegue Vaclav on wxIClass which was based on
old i.class module (available only for X monitor) [1][2]. So don't
hesitate to ask us in case of some problems with wxGUI. Good luck with
your GSoC application.

Anna

[1] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/wxIClass
[2] http://grass.osgeo.org/wiki/WxIClass
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-user] error message from GRASS 7 on mac os

[Anna Kratochvílová]

2012/3/19 Michael Barton :
> Since wx.CallAfter does not solve this, the only sure-fire fix that I can 
> find is to either revert to the standard wx.SplashScreen or to replace line 
> 59 in wxgui.py with:
>
>        if SC and sys.platform != 'darwin':
>
> That way, at least the Macs default to the basic splash screen without the 
> errors. The AdvancedSplash does show the text "Starting GRASS GUI...", but 
> that is the only thing lost by reverting the old splash screen

I agree with the second solution (leaving the advanced splash screen
for other platforms). Please don't forget to add a comment in the code
about the reason. I suppose this problem might be fixed in the future.

Anna

>
> Michael
>
> On Mar 18, 2012, at 1:44 PM, Anna Kratochvílová wrote:
>
>> Hi,
>>
>> 2012/3/18 Michael Barton :
>>> I found the problem. It's the 'advanced splash screen' (in the agw package) 
>>> called fromwxgui.py.
>>>
>>> Although the advanced splash screen can do some additional things beyond 
>>> the normal splash screen, we don't really use much (or any?) of those 
>>> capabilities.
>>>
>>
>> I don't have any experience with it. You can try to use wx.CallAfter
>> (as advised in the wxwidgets bug report) when setting splash screen.
>>
>> Something like:
>>
>> def SetSplashScreen(self, splashScreen):
>>     splashScreen.Set...
>>     
>>
>>
>> if SC:
>>      splash = SC.AdvancedSplash(bitmap = introBmp, timeout = 2000,
>> parent = None, id = wx.ID_ANY)
>>      wx.CallAfter(self.SetSplashScreen, splash)
>>
>> Again, I really don't know what's going on. I think it's not GRASS gui
>> fault, problem seems to be in wxwidgets and Mac. The same for the next
>> error message (CFURLCreateWithString ...), I doubt anything can be
>> done by GRASS developers. Maybe some workaround exists but I can't
>> google anything now.
>>
>> Anna
>>
>>
>>> try:
>>>    import wx.lib.agw.advancedsplash as SC
>>> except ImportError:
>>>    SC = None
>>>
>>>
>>> ...
>>>
>>>        if SC:
>>>            splash = SC.AdvancedSplash(bitmap = introBmp,
>>>                                       timeout = 2000, parent = None, id = 
>>> wx.ID_ANY)
>>>            splash.SetText(_('Starting GRASS GUI...'))
>>>            splash.SetTextColour(wx.Colour(45, 52, 27))
>>>            splash.SetTextFont(wx.Font(pointSize = 15, family = wx.DEFAULT, 
>>> style = wx.NORMAL,
>>>                                       weight = wx.BOLD))
>>>            splash.SetTextPosition((150, 430))
>>>
>>>
>>>
>>> Every call to splash produces ": CGContextRestoreGState: invalid 
>>> context 0x0"
>>>
>>> Michael
>>>
>>> On Mar 18, 2012, at 12:53 AM, Anna Kratochvílová wrote:
>>>
>>>> 2012/3/17 Michael Barton :
>>>>> Anna,
>>>>>
>>>>> Where did you insert this? I can do a quick test. I'd be delighted if we
>>>>> could avoid those annoying error messages.
>>>>
>>>> Not sure what 'where' means, here [1] is the changeset. According to
>>>> this email [2] the error message 'CGContextRestoreGState: invalid
>>>> context' is supposed to show up immediately after wxGUI start. This
>>>> fix is just a guess, I really don't understand what's going on. Are
>>>> there any other annoying messages on Mac?
>>>>
>>>> Anna
>>>>
>>>> [1] http://trac.osgeo.org/grass/changeset/51089
>>>> [2] http://lists.osgeo.org/pipermail/grass-user/2012-March/063996.html
>>>>>
>>>>> Michael
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I added CallAfter as suggested (r51089), let's see if it helps.
>>>>>
>>>>> Anna
>>>>>
>>>>>
>>>>> _
>>>>> C. Michael Barton
>>>>> Visiting Scientist, Integrated Science Program
>>>>> National Center for Atmospheric Research &
>>>>> University Consortium for Atmospheric Research
>>>>> 303-497-2889 (voice)
>>>>>
>>>>> Director, Center for Social Dynamics & Complexity
>>>>> Profes

[GRASS-dev] wxgui example module

[Anna Kratochvílová]

Hi,

I would like to inform you that new wxGUI example module is available
in trunk (doc/gui/wxpython/example). Margherita requested better wxGUI
documentation, so I decided to write a simple example tool which does
nothing interesting; it's just a window with toolbars (like map
display), you can load raster and it shows information about it
(called r.univar). It is quite easy to write such modules thanks to
the code refactoring made during the development of wxIClass.
This example module should help new wxGUI developers, it covers
several tasks (calling module, loading maps, writing documentation
etc.) but it's still simple enough. If you think of something
important what shouldn't be omitted, I can add it of course.
Could someone suggest me where to add links to this example module on
GRASS wiki?

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

Re: [GRASS-dev] How can i change the title of grass gis map display window

[Anna Kratochvílová]

2011/12/28 Sandip Maity :
> Dear frnds,
>
> its not working. please tell me another way.
> thnanks and regards.
>
> Sandip
>
> On 12/28/11, Anna Kratochvílová  wrote:
>> On Wed, Dec 28, 2011 at 6:12 AM, Sandip Maity 
>> wrote:
>>> Dear frnds,
>>>
>>> I want to change the title "grass gis map display" in my own title.
>>> I am using GRASS 6.5 SVN.
>>> I changed the title in mapdisp.py.
>>> But not working.

Sorry, my fault, it's in wxpython/lmgr/layertree.py (in init method)

Anna

>>>
>>
>> Hi,
>>
>> mapdisp.py doesn't exist now (in G65 and G7), see [1]. Map Display
>> title can be changed in gui/wxpython/mapdisp/frame.py in
>> MapFrame.__init__ method.
>>
>> [1]
>> http://trac.osgeo.org/grass/wiki/wxGUIDevelopment#ChangingGUImodulesdirectorylayout
>>
>> Anna
>>
>>
>>> Please suggest the way.
>>> regards.
>>> sandip
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev