Re: [GRASS-dev] cp -r vs -R in make

2016-01-26 Thread Glynn Clements 

Anna Petrášová wrote:

> cp: the -H, -L, and -P options may not be specified with the -r option.
> 
> make: *** [install] Error 1
> 
> 
> It seems cp -r (lowercase r) is not portable, see [1]. Mac cp man page says:
> 
> Historic versions of the cp utility had a -r option. This implementation
> supports that option; how-ever, however, ever, its use is strongly
> discouraged, as it does not correctly copy special files, symbolic links,
> or fifo's.
> 
> lowercase r is used on couple of places, mainly include/Make/Install.make.
> So my question is if anyone thinks there are some valid reasons for using
> lowercase r.

"cp" probably shouldn't be used at all.

Executable files should be installed with $(INSTALL), non-executable
files with $(INSTALL_DATA).

In either case, they should only be used to copy a rule's prerequisite
to its target (i.e. no unconditional "bulk" copies in the body of an
unrelated rule), as in:

destination: source
$(INSTALL_DATA) $< $@

If the number of files is large, $(wildcard ...) and $(patsubst ...) 
should be used to construct a list of targets which should then be
made prerequisites of the Makefile's "default" rule, with the
installation performed by a pattern rule.

The only places "cp" is used in the actual GRASS source tree (not
including "addons") are in Install.make, the "install" targets of a
couple of other *.make files, and the "update-po" target in
locale/Makefile. None of these are part of the actual build process.

(I just removed the one in simlib; Rules.make already has a pattern
rule for installing headers).

FWIW, the "portable" solution for recursive copies has historically
been to use "tar c ... | tar x ...".

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

[GRASS-dev] [GRASS GIS] #2877: r.mapcalc allow neigbourhood modifier to accept expression or NAME

2016-01-26 Thread GRASS GIS 
#2877: r.mapcalc allow neigbourhood modifier to accept expression or NAME
-+-
 Reporter:  marisn   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.1.0
Component:  Raster   |Version:  svn-trunk
 Keywords:  r.mapcalc|CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 It seems that r.mapcalc map[row,col] accepts only integers as row and col.
 It would be useful (in rare cases) to specify row or col as an expression
 or name that results in integer.

 Here are some examples that should work:
 {{{
 map[-1, ncols() - 1]
 map[sampler_x_map, sampler_y_map]
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r67535: pygrass: change dirname in set_path()

2016-01-26 Thread Markus Neteler 
On Mon, Jan 25, 2016 at 9:05 PM, Vaclav Petras  wrote:
> In r67669 I moved the functions to grass.script.utils to avoid ctypes
> dependency. Backwards compatibility is kept. Documentation says depreciated.
> Old functions can be removed in 8.0.
>
> https://trac.osgeo.org/grass/changeset/67669

For the record, added to
https://trac.osgeo.org/grass/wiki/Grass8Planning

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

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

2016-01-26 Thread Maris Nartiss 
Done.

It was all the time in locale/README, although there are no Python examples.

AFAIK there still is one missing thing for the Python part - plural
form support. Unfortunately I haven't found time to look into it as I
did with C part.

Let me know if I can be helpful,
Māris.


2016-01-25 17:45 GMT+02:00 Vaclav Petras :
>
> On Sun, Jan 24, 2016 at 3:09 AM,  wrote:
>>
>> Log:
>> Add comments for translators to help differentiating between similar
>> words.
>> Comment must be on preceding line to string!
>>
>>
>> Modified: grass/trunk/gui/wxpython/gis_set.py
>> ===
>> --- grass/trunk/gui/wxpython/gis_set.py 2016-01-23 22:16:31 UTC (rev
>> 67646)
>> +++ grass/trunk/gui/wxpython/gis_set.py 2016-01-24 08:09:17 UTC (rev
>> 67647)
>> @@ -165,24 +165,30 @@
>>  self.bbrowse = wx.Button(parent = self.gisdbase_panel, id =
>> wx.ID_ANY,
>>   label = _(""))
>>  self.bmapset = wx.Button(parent = self.mapset_panel, id =
>> wx.ID_ANY,
>> +# GTC New mapset
>>   label = _(""))
>
>
>
> Would you mind extending submitting guidelines accordingly?
>
> Thanks,
> Vaclav
>
> https://trac.osgeo.org/grass/wiki/Submitting/Python
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.out.ascii "where" not working

2016-01-26 Thread Andy Wickert 
Hi Grass Developers,

I'm running GRASS 7.1-dev on Ubuntu, and the "where" keyword is being
ignored; all of the data are being exported regardless of what I choose.
Could anyone verify that this is the case?

Thanks,

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

Re: [GRASS-dev] Layer Manager notebook

2016-01-26 Thread Vincent Bain 
Hi,

perhaps the tab widget does not support it, but could the label "long
name" be provided by a mouse-over tip ?

Vincent.


Le mardi 26 janvier 2016 à 08:56 +0100, Moritz Lennert a écrit :
> On 26/01/16 03:02, Anna Petrášová wrote:
> > Hi,
> >
> > I plan to change the style of the Layer Manager tabs in the bottom of
> > the window from wx.FlatNotebook to wx.Notebook. The results look like this:
> >
> > https://drive.google.com/file/d/0B1j-R6U3_Ct9RFd1V3JSbDRjdGc/view?usp=sharing
> >
> > Reasons include:
> > * FlatNotebook behaves strangely on Ubuntu 15+ with wxpython3 wxGTK,
> > switching tabs doesn't work well
> > * FlatNotebook rendering glitch on MacOSX with wxpython 3 (visible in
> > the screenshot)
> > * FlatNotebook causes crashing when switching from 3D to 2D on MacOSX
> > with wxpython 3 http://trac.wxwidgets.org/ticket/16357
> > * FlatNotebook probably causes loosing focus when switching to command
> > console
> > * FlatNotebook probably causes some GDK critical warnings on Ubuntu
> >
> > Overall, by using native widget (wx.Notebook) we avoid many glitches.
> 
> +1
> 
> > However, the appearance will be different for different OS. I personally
> > don't have problem with that, but I would suggest applying this to Mac
> > and Linux, not Windows, because on Windows it looks ugly and since we
> > still use wxpython 2.8, the described glitches don't apply there. Opinions?
> 
> I think that ideally, whenever possible, we should avoid having 
> different treatments for different OS's. But if you all think that the 
> windows version looks too ugly (I'm quite insensitive to such issues, so 
> not a good judge), then +1 as long as windows is still wxpython 2.8.
> 
> >
> >
> > Related to this, any opinion on making the labels of the tabs shorter?
> 
> For me they can be as short as you want, as I know what they are about, 
> but we have to try to think like a GRASS newbie, here. So, my 
> reflections in detail:
> 
> >
> > Map layers -> Layers
> 
> +1
> 
> > Command console -> Console
> > Search modules -> Search
> 
> For these two I'm not sure if the short version is clear enough on what 
> these are about: will most users understand what a 'Console' is ? At 
> what is it you can search there ?
> 
> > Data catalogue -> Catalogue
> 
> +1
> 
> > Python shell -> Python
> 
> Again, not sure if just 'Python' is enough to make it clear.
> 
> IIUC, the reason for shortening is essentially OSX, or ? Wouldn't it be 
> possible to just slightly reduce font size ?
> 
> Moritz
> ___
> 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] #2876: r.sun (mode 1): data are not timestamped correctly

2016-01-26 Thread GRASS GIS 
#2876: r.sun (mode 1): data are not timestamped correctly
-+-
  Reporter:  fabriziosossan  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  Raster  |Version:  6.4.5
Resolution:  |   Keywords:  r.sun
   CPU:  x86-64  |   Platform:  Linux
-+-
Changes (by wenzeslaus):

 * milestone:   => 7.0.3


Comment:

 Formally it looks good to me. Can you please comment on it, so we can put
 it to the source code with explanation?

 And slightly related to that, are you willing to share some of your
 results? There are many options how to do that depending on your methods,
 but a very interesting one is an actual Python code which does the
 comparison.

 For those who are in doubts: r.sun2 in 6.4 branch is r.sun in 7.0 branch.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] trunk: sphinxdoclib broken

2016-01-26 Thread Markus Neteler 
Hi,

on the Debian build server the following problem appeared in trunk
(relbranch is fine):

make sphinxdoclib
...
SPHINXBUILD: Found 
SPHINXAPIDOC: Found 
SPHINXBUILD: Using 
GISRC=/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/demolocation/.grassrc71
GISBASE=/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu
PATH="/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/bin:/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/bin:/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/scripts:$PATH"
PYTHONPATH="/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/etc/python:/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/gui/wxpython:$PYTHONPATH"
LD_LIBRARY_PATH="/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/bin:/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/bin:/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/scripts:/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/lib:/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/lib:"
LC_ALL=C sphinx-build -b html -d _build/doctrees   -c . src/
/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/docs/html/libpython
Running Sphinx v1.2.3

Exception occurred:
  File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
The full traceback has been saved in /tmp/sphinx-err-S54551.log, if
you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error
message can be provided next time.
A bug report can be filed in the tracker at
. Thanks!
Makefile:71: recipe for target 'libpythonhtml' failed
make[1]: *** [libpythonhtml] Error 1
make[1]: Leaving directory
'/home/neteler/grass7_svn_head_bin_snapshot/trunk/lib/python/docs'
include/Make/Sphinx.make:47: recipe for target 'sphinxdoclib' failed
make: *** [sphinxdoclib] Error 2



neteler@osgeo6:~/grass7_svn_head_bin_snapshot/trunk$ cat
/tmp/sphinx-err-S54551.log
# Sphinx version: 1.2.3
# Python version: 2.7.9
# Docutils version: 0.12 release
# Jinja2 version: 2.7.3
# Loaded extensions:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sphinx/cmdline.py", line 253, in main
warningiserror, tags, verbosity, parallel)
  File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line
107, in __init__
confoverrides or {}, self.tags)
  File "/usr/lib/python2.7/dist-packages/sphinx/config.py", line 229,
in __init__
execfile_(filename, config)
  File "/usr/lib/python2.7/dist-packages/sphinx/util/pycompat.py",
line 105, in execfile_
exec code in _globals
  File "conf.py", line 45, in 
grass_version = core.version()['version']
  File 
"/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 1518, in version
data = parse_command('g.version', flags='rge', errors='ignore')
  File 
"/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 501, in parse_command
res = read_command(*args, **kwargs)
  File 
"/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 458, in read_command
process = pipe_command(*args, **kwargs)
  File 
"/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 433, in pipe_command
return start_command(*args, **kwargs)
  File 
"/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 377, in start_command
return Popen(args, **popts)
  File 
"/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 74, in __init__
subprocess.Popen.__init__(self, args, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
neteler@osgeo6:~/grass7_svn_head_bin_snapshot/trunk$ sphinx-
sphinx-apidoc  sphinx-autogen sphinx-build   sphinx-quickstart
neteler@osgeo6:~/grass7_svn_head_bin_snapshot/trunk$ sphinx-apidoc --version
Sphinx (sphinx-apidoc) 1.2.3


Any ideas? Recently it worked.

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

Re: [GRASS-dev] trunk: sphinxdoclib broken

2016-01-26 Thread Vaclav Petras 
On Tue, Jan 26, 2016 at 11:21 AM, Markus Neteler  wrote:

> ...
>   File "/usr/lib/python2.7/dist-packages/sphinx/util/pycompat.py",
> line 105, in execfile_
> exec code in _globals
>   File "conf.py", line 45, in 
> grass_version = core.version()['version']
>   File
> "/home/neteler/grass7_svn_head_bin_snapshot/trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
> line 1518, in version
> data = parse_command('g.version', flags='rge', errors='ignore')
> ...
> subprocess.Popen.__init__(self, args, **kwargs)
>   File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
> ...
>
> Any ideas?
>

It looks like it can't find g.version.

I'm getting different error but the traceback doesn't refer to anything
with GRASS:

$ make sphinxdoclib
# Sphinx version: 1.2.3
# Python version: 2.7.10
# Docutils version: 0.12 release
# Jinja2 version: 2.8
...
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sphinx/cmdline.py", line 254, in
main
app.build(force_all, filenames)
  File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line 220,
in build
self.builder.build_update()
...
  File "/usr/lib/python2.7/dist-packages/sphinx/pycode/__init__.py", line
204, in for_module
obj = cls.for_file(source, modname)
  File "/usr/lib/python2.7/dist-packages/sphinx/pycode/__init__.py", line
187, in for_file
obj = cls(fileobj, modname, filename)
  File "/usr/lib/python2.7/dist-packages/sphinx/pycode/__init__.py", line
224, in __init__
self.code = self.source.read().decode(self.encoding)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 8451:
ordinal not in range(128)

Which reminds me of #2875. Do we have somewhere a unicode & Python 3
related issue? (Unrelated to the g.version problem.)

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

Re: [GRASS-dev] wingrass daily builds layout

2016-01-26 Thread Anna Petrášová 
Hi Martin,

On Mon, Jan 18, 2016 at 7:38 AM, Martin Landa 
wrote:

> Hi,
>
> 2016-01-17 14:31 GMT+01:00 Markus Neteler :
> > +1 to the new layout.
>
> I changed the layout, updated build scripts, `g.extension`, website
> and also set up redirection links for 7.0.3RC2 to be sure that
> `g.extension` will work also there.
>
> Ma
>

addons for  7.0.3RC2 work but not for latest stable 7.0.2 because of the
layout change...

Anna


> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/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] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-26 Thread GRASS GIS 
#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-

Comment (by wenzeslaus):

 Replying to [comment:6 glynn]:
 > Replying to [ticket:2873 wenzeslaus]:
 >
 > > The `GRASS_EXECUTABLE` does not have to be set if `grass` is on the
 path or, in theory, if it is in on some standard path
 >
 > IMHO, this "solution" is yet more duct tape on top of the existing heap.

 I'll try to prepare some patch without this workaround which will expect
 `grass` executable, Python pakcages and libraries already on path. The API
 is the easy part here I guess.

 > Any real solution would start by simply deleting the GRASS startup
 script then figuring out what needs to be done to make everything still
 work without it.
 >
 > It should not be necessary to "start" GRASS.

 Back when you suggested that in #580 it seemed strange to me, but now I
 think it would be much better than the current situation.

 > On Unix, GRASS modules and libraries should be installed in system
 directories. Python packages should go in Python's site-packages
 directory. Environment variables should be set in /etc/profile (or
 whatever mechanism the distribution uses, e.g. /etc/profile.d).

 I can see this working for dynamic libraries and Python packages and I
 think this would be good enough for now, but how this would work for
 modules? For example, I have 141 PCL tools installed (`pcl_*`) but we have
 >500 modules plus addons which actually have to be on a separate site. It
 would be good to get opinions from some packagers.

 Anyway, dynamic libraries and Python packages in system paths are place to
 start. Can the compile/install process be set to this now?

 > GISRC should have a system-wide default setting such as
 $(HOME)/.grass/rc. Users who never need more than one session at a time
 can just use that file always, changing the database, location or mapset
 with g.mapset.

 For me this is different because it is related to the data being used and
 I'm not so convinced about it in comparison to the need for ready to use
 runtime environment. I often work in more then one Mapset and I actually
 use Mapset locks to see where I have already open sessions. However, I can
 see that for many users permanent connection to given Mapset plus a
 additional sessions (GISRCs) upon request (starting GRASS application or
 API in some special way) might work, although particular details matter a
 lot here.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] cp -r vs -R in make

2016-01-26 Thread Anna Petrášová 
On Tue, Jan 26, 2016 at 7:28 AM, Glynn Clements 
wrote:

>
> Anna Petrášová wrote:
>
> > cp: the -H, -L, and -P options may not be specified with the -r option.
> >
> > make: *** [install] Error 1
> >
> >
> > It seems cp -r (lowercase r) is not portable, see [1]. Mac cp man page
> says:
> >
> > Historic versions of the cp utility had a -r option. This implementation
> > supports that option; how-ever, however, ever, its use is strongly
> > discouraged, as it does not correctly copy special files, symbolic links,
> > or fifo's.
> >
> > lowercase r is used on couple of places, mainly
> include/Make/Install.make.
> > So my question is if anyone thinks there are some valid reasons for using
> > lowercase r.
>
> "cp" probably shouldn't be used at all.
>
> Executable files should be installed with $(INSTALL), non-executable
> files with $(INSTALL_DATA).
>
> In either case, they should only be used to copy a rule's prerequisite
> to its target (i.e. no unconditional "bulk" copies in the body of an
> unrelated rule), as in:
>
> destination: source
> $(INSTALL_DATA) $< $@
>
> If the number of files is large, $(wildcard ...) and $(patsubst ...)
> should be used to construct a list of targets which should then be
> made prerequisites of the Makefile's "default" rule, with the
> installation performed by a pattern rule.
>
> The only places "cp" is used in the actual GRASS source tree (not
> including "addons") are in Install.make, the "install" targets of a
> couple of other *.make files, and the "update-po" target in
> locale/Makefile. None of these are part of the actual build process.
>
> (I just removed the one in simlib; Rules.make already has a pattern
> rule for installing headers).
>
> FWIW, the "portable" solution for recursive copies has historically
> been to use "tar c ... | tar x ...".
>

Thanks for the information on this. However, for now, I just fixed one of
the usages in Script.make (by changing -r to -R) to be able to install the
addon, since I can't fix it properly.

Anna

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

Re: [GRASS-dev] Layer Manager notebook

2016-01-26 Thread Anna Petrášová 
On Tue, Jan 26, 2016 at 2:56 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 26/01/16 03:02, Anna Petrášová wrote:
>
>> Hi,
>>
>> I plan to change the style of the Layer Manager tabs in the bottom of
>> the window from wx.FlatNotebook to wx.Notebook. The results look like
>> this:
>>
>>
>> https://drive.google.com/file/d/0B1j-R6U3_Ct9RFd1V3JSbDRjdGc/view?usp=sharing
>>
>> Reasons include:
>> * FlatNotebook behaves strangely on Ubuntu 15+ with wxpython3 wxGTK,
>> switching tabs doesn't work well
>> * FlatNotebook rendering glitch on MacOSX with wxpython 3 (visible in
>> the screenshot)
>> * FlatNotebook causes crashing when switching from 3D to 2D on MacOSX
>> with wxpython 3 http://trac.wxwidgets.org/ticket/16357
>> * FlatNotebook probably causes loosing focus when switching to command
>> console
>> * FlatNotebook probably causes some GDK critical warnings on Ubuntu
>>
>> Overall, by using native widget (wx.Notebook) we avoid many glitches.
>>
>
> +1
>
> However, the appearance will be different for different OS. I personally
>> don't have problem with that, but I would suggest applying this to Mac
>> and Linux, not Windows, because on Windows it looks ugly and since we
>> still use wxpython 2.8, the described glitches don't apply there.
>> Opinions?
>>
>
> I think that ideally, whenever possible, we should avoid having different
> treatments for different OS's. But if you all think that the windows
> version looks too ugly (I'm quite insensitive to such issues, so not a good
> judge), then +1 as long as windows is still wxpython 2.8.


Done in r67679.


>
>
>>
>> Related to this, any opinion on making the labels of the tabs shorter?
>>
>
> For me they can be as short as you want, as I know what they are about,
> but we have to try to think like a GRASS newbie, here. So, my reflections
> in detail:
>
>
>> Map layers -> Layers
>>
>
> +1
>
> Command console -> Console
>> Search modules -> Search
>>
>
> For these two I'm not sure if the short version is clear enough on what
> these are about: will most users understand what a 'Console' is ? At what
> is it you can search there ?
>

I would think console is pretty clear, but that's just my feeling. I agree
Search is ambiguous, although it might not be a huge problem for users.

>
> Data catalogue -> Catalogue
>>
>
this was supposed to be catalog

>
> +1
>
> Python shell -> Python
>>
>
> Again, not sure if just 'Python' is enough to make it clear.
>
> IIUC, the reason for shortening is essentially OSX, or ? Wouldn't it be
> possible to just slightly reduce font size ?


Not just Mac, in my case last tab is hidden but I can see a small arrow
showing that there is another tab. We don't have to decide this now, I was
thinking about this for some time and I was wondering if others agree we
need this.


Thanks,
Anna

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

Re: [GRASS-dev] Layer Manager notebook

2016-01-26 Thread Anna Petrášová 
On Tue, Jan 26, 2016 at 3:02 AM, Vincent Bain  wrote:

> Hi,
>
> perhaps the tab widget does not support it, but could the label "long
> name" be provided by a mouse-over tip ?
>

No, that's not supported. I doubt people would use the tooltip anyway, you
can just switch the tab and see.

Anna

>
> Vincent.
>
>
> Le mardi 26 janvier 2016 à 08:56 +0100, Moritz Lennert a écrit :
> > On 26/01/16 03:02, Anna Petrášová wrote:
> > > Hi,
> > >
> > > I plan to change the style of the Layer Manager tabs in the bottom of
> > > the window from wx.FlatNotebook to wx.Notebook. The results look like
> this:
> > >
> > >
> https://drive.google.com/file/d/0B1j-R6U3_Ct9RFd1V3JSbDRjdGc/view?usp=sharing
> > >
> > > Reasons include:
> > > * FlatNotebook behaves strangely on Ubuntu 15+ with wxpython3 wxGTK,
> > > switching tabs doesn't work well
> > > * FlatNotebook rendering glitch on MacOSX with wxpython 3 (visible in
> > > the screenshot)
> > > * FlatNotebook causes crashing when switching from 3D to 2D on MacOSX
> > > with wxpython 3 http://trac.wxwidgets.org/ticket/16357
> > > * FlatNotebook probably causes loosing focus when switching to command
> > > console
> > > * FlatNotebook probably causes some GDK critical warnings on Ubuntu
> > >
> > > Overall, by using native widget (wx.Notebook) we avoid many glitches.
> >
> > +1
> >
> > > However, the appearance will be different for different OS. I
> personally
> > > don't have problem with that, but I would suggest applying this to Mac
> > > and Linux, not Windows, because on Windows it looks ugly and since we
> > > still use wxpython 2.8, the described glitches don't apply there.
> Opinions?
> >
> > I think that ideally, whenever possible, we should avoid having
> > different treatments for different OS's. But if you all think that the
> > windows version looks too ugly (I'm quite insensitive to such issues, so
> > not a good judge), then +1 as long as windows is still wxpython 2.8.
> >
> > >
> > >
> > > Related to this, any opinion on making the labels of the tabs shorter?
> >
> > For me they can be as short as you want, as I know what they are about,
> > but we have to try to think like a GRASS newbie, here. So, my
> > reflections in detail:
> >
> > >
> > > Map layers -> Layers
> >
> > +1
> >
> > > Command console -> Console
> > > Search modules -> Search
> >
> > For these two I'm not sure if the short version is clear enough on what
> > these are about: will most users understand what a 'Console' is ? At
> > what is it you can search there ?
> >
> > > Data catalogue -> Catalogue
> >
> > +1
> >
> > > Python shell -> Python
> >
> > Again, not sure if just 'Python' is enough to make it clear.
> >
> > IIUC, the reason for shortening is essentially OSX, or ? Wouldn't it be
> > possible to just slightly reduce font size ?
> >
> > Moritz
> > ___
> > 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] #2877: r.mapcalc allow neigbourhood modifier to accept expression or NAME

2016-01-26 Thread GRASS GIS 
#2877: r.mapcalc allow neigbourhood modifier to accept expression or NAME
--+-
  Reporter:  marisn   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.1.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by glynn):

 Replying to [ticket:2877 marisn]:
 > It seems that r.mapcalc map[row,col] accepts only integers as row and
 col. It would be useful (in rare cases) to specify row or col as an
 expression or name that results in integer.

 Arbitrary offsets for the column are probably feasible, but still likely
 to involve a fair amount of work.

 Arbitrary offsets for the rows aren't feasible without a complete re-write
 due to the row-by-row nature of r.mapcalc. Even with such a re-write, they
 could require storing a significant portion of the map (possibly all of
 it) in memory (if the row offset is different for each column, then you
 need as many rows in memory as there are columns).

 In that situation, you may as well use grass.script.array (or similar) to
 make the map available as a numpy array and get the benefits of using a
 real programming language.

--
Ticket URL: 
GRASS GIS 

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