Re: [GRASS-dev] [GRASS GIS] #1742: WXGUI layer manager window doesn't show all menubar entries

[GRASS GIS]

#1742: WXGUI layer manager window doesn't show all menubar entries
-+--
 Reporter:  marisn   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-releasebranch64  
 Keywords:  menu |Platform:  Linux
  Cpu:  Unspecified  |  
-+--

Comment(by cmbarton):

 This wish/issue has been around since the TclTk menus. The screenshot
 attached shows what appears to be a low resolution, small monitor,
 creating a small layer manager with large type. This is exacerbated by
 long menu entries in German. I agree with Hamish that while we definitely
 want GRASS to work across multiple languages, we should not make the
 interface worse for the majority to satisfy a minority of users. So we
 need to understand the true extent of this problem. So here are a few
 questions and comments.

 1. The current menu words in English were picked because they were
 relatively short. Rather than direct translation to another language, can
 the same concepts be expressed in shorter words? It is the concepts that
 are important, not the actual words used in the menus. This is something
 those who work on the translations can best consider and answer.

 2. On the smaller monitor of my MacBook Air, the absolute (i.e., in mm)
 size of the type is smaller because more pixels are crammed into smaller
 screen real estate. Is this primarily a problem on small monitors with
 average or lower resolutions (e.g., notebook computers)?

 If so, we need to think about whether this is the main GRASS user
 audience. While it would be nice to run GRASS on a notebook (and a number
 of student do so here) those platforms are not really very good for GIS
 work. While it is really great that GRASS works on such platforms, I'm
 reluctant to optimize the GUI for such platforms.

 The menu structure (horizontal menu bar, pull down menu item lists, sub-
 menus) is very traditional. However, this in and of itself tends to be
 best at optimizing limited screen real estate (i.e, small displays). A top
 level list of menu items can be horizontal, vertical, or in a rectangular
 matrix. All current displays are longer horizontally than they are
 vertically. So, especially for long words, you can get more textual
 information while using up less available screen space in a horizontal
 menu than in either of the other 2 options, because each menu entry only
 takes up the width of the menu word. For a  vertical set of menus, each
 entry takes up the space of the longest word in the entire menu. Block
 matrices are similarly affected.

 One solution is to allow the user to alter the menu font size in the
 preferences. It could then be set for different display environments by
 the user. Another solution is to replace the words in the top level menu
 with more icons. The possible draw back is that icons may not be easily
 understandable to novice users (see below). But with mouse over text, they
 can be learned relatively easily.

 3. Currently, it is relatively easy to find and access all functions in
 GRASS--in spite of the fact that it is a very complex program with
 hundreds of modules--because of the current menu design. Early in the
 current GUI design process, one of the devs (I don't remember which one)
 noted that good menu design should keep all selections within a maximum of
 3 levels of nesting (top menu, pull-down, and sub-menu). This has been a
 very good principle to follow. One of the complaints I regularly hear
 about Arc is how difficult it is to find different functions, being nested
 in menus, leading to tool boxes, leading to dialogs and more menus.

 The current GUI attempts to group functions according to work flow.
 Functions for making and altering maps are in the menus, functions for
 arranging maps for viewing are in the layer manager. Functions for
 interacting with displayed maps are in the map display windows. I'm in
 favor of experimenting with new designs for ways to access different
 functions. But the top priorities in any GUI should be ease of access,
 transparency in signaling, and facilitating work flows. Users should be
 able to find and identify the tools they need as quickly and as easily as
 possible as they need them. So I remain skeptical of tool boxes and don't
 like the idea that users will need to access yet another interface (e.g.,
 hierarchical module list)  from the primary interface to find a needed
 function. As much as possible should be accessible at a glance, while
 minimizing the loss of total screen space--which is best used to display
 maps.

 These are just some musings. We need to be innovative but for the GUI keep
 in mind novice rather than expert users.

-- 
Ticket

Re: [GRASS-dev] [GRASS GIS] #306: hidden tabs are hard to spot in wxGUI module windows

[GRASS GIS]

#306: hidden tabs are hard to spot in wxGUI module windows
-+--
 Reporter:  msieczka |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  major|   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-develbranch6 
 Keywords:  tabs |Platform:  All  
  Cpu:  All  |  
-+--

Comment(by wenzeslaus):

 The default module dialog style is now 'basic top' (r57212).

 For GRASS 7, this should be fixed for all platforms.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

[Vaclav Petras]

On Mon, Aug 26, 2013 at 10:24 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> - #1742 (menus hidden in non-english languages): It seems that the only
> solution besides complete redesign has been to simply make the default
> width of the layer manager larger. If everyone agrees this seems like a
> simple fix.


Hi, I forgot to update [1] the ticked after the community sprint in Prague
(now updated). The new conception could be following:
* Main menu bar only for the main items (e.g. `g.region`) or even only for
settings and GUI window control (adding layers, opening windows).
* For finding and running a module, user should use the module tree in
the search modules tab. Here we can have a long list of basic groups
(toolboxes) such as Raster, Imagery etc.

In other words, in order to solve this issue, I vote for removal of
Database, Imagery and Volumes. According to #1742 [2] we need to remove at
least two items to get the German menu right.

Vaclav

[1] http://trac.osgeo.org/grass/ticket/1742#comment:13
[2]
http://trac.osgeo.org/grass/attachment/ticket/1742/grass_layer_manager_width.png
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1742: WXGUI layer manager window doesn't show all menubar entries

[GRASS GIS]

#1742: WXGUI layer manager window doesn't show all menubar entries
-+--
 Reporter:  marisn   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-releasebranch64  
 Keywords:  menu |Platform:  Linux
  Cpu:  Unspecified  |  
-+--
Changes (by wenzeslaus):

  * keywords:  => menu


Comment:

 == Possible solutions ==

 ''update for comment:10''

 === Shorter menu ===

 Toolboxes XMLs now (after r57187, r57188 and r57199) provide possibility
 to have different tree for ''main menu bar'' and for the ''module tree''
 in module search tab. It is not yet in documentation but it's the same as
 previous version but now there are two files (main_menu and module_tree)
 used by GUI.

 We can reduce the number of main entries in main menu: remove Database,
 Imagery or Volumes item because they are in the module tree. This is a
 change in philosophy of wxGUI of course. However, it's no so big because
 Temporal (framework) item was newer in the menu, it's only in the module
 tree (the same applies also for special Addons and Custom toolboxes
 items).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1662: Caching bug in 3D raster library with large data

[GRASS GIS]

#1662: Caching bug in 3D raster library with large data
-+--
 Reporter:  huhabla  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Raster3D | Version:  svn-trunk
 Keywords:  3D raster, tiles, cache  |Platform:  Linux
  Cpu:  x86-32   |  
-+--

Comment(by annakrat):

 Here is the backtrace:

 {{{
 #0  0xb7f7c3ac in Rast3d_cache_hash_name2index (h=0x8051f98,
 name=1715470336) at cachehash.c:114
 #1  0xb7f7adf7 in Rast3d_cache_elt_ptr (c=0x805a0f0, name=1715470336) at
 cache1.c:469
 #2  0xb7f7b04c in Rast3d_cache_load (c=0x805a0f0, name=1715470336) at
 cache1.c:517
 #3  0xb7f7c08b in Rast3d_flush_all_tiles (map=0x8054028) at cache.c:310
 #4  0x0804bd57 in test_large_file_random (depths=20, rows=5400,
 cols=10800, tile_size=32) at test_put_get_value_large_file.c:283
 #5  0x0804b421 in unit_test_put_get_value_large_file (depths=20,
 rows=5400, cols=10800, tile_size=32) at test_put_get_value_large_file.c:39
 #6  0x08049c34 in main (argc=2, argv=0xbfffedd4) at test_main.c:160
 }}}

 Thank you for the instructions, here they are for completeness:

 {{{
 gdb test.g3d.lib

 r unit=large
 . segfault
 bt
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

[Glynn Clements]

Moritz Lennert wrote:

> - Two concern Windows code page issues (#995, #1288) for which I don't 
> really know what a possible solution would be (is it possible to create 
> a launcher for GRASS in Python, without using .bat at all ?)

If the Python interpreter is registered, you should just be able to
execute the grass70.py script.

Failing that, you can create a shortcut which executes a specific
python.exe (or pythonw.exe) with the path to the grass.py script as an
argument.

Failing that, a .bat/.cmd file should work fine, so long as it just
executes grass70.py via Python, and doesn't try to do anything else. 

The short version is: batch files can't handle non-ASCII characters. 
The longer version is that each locale has two distinct codepages, and
cmd.exe itself tends to assume that everything uses the locale's OEM
codepage while most programs use the locale's ANSI codepage. If you
use any character which isn't the same in both, you lose.

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

Re: [GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by martinl):

 Replying to [comment:6 glynn]:
 > Replying to [ticket:1778 pvanbosgeo]:
 > > Normally when you type a command, e.g., g.region, without parameters,
 a new window for that command opens.
 > >
 > > This does not seem to work for a few commands at the moment. Three
 ones that seem to be affected are g.region, g.rename and g.copy.
 >
 > This is normal. If a command doesn't have any required options,
 executing the command without parameters will not open a parameter dialog.
 You can force a parameter dialog to be displayed using the --ui switch.

 I would call it rather "current behaviour". It's probably confusing to the
 user. Is there any reason why the dialog is not open in this case?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:5 mlennert]:

 > ISTR that there is an option to mark several parameters as "at least one
 of these is required", but I can't find how to do this in the programmer's
 manual.

 No such feature exists at present, although it has been discussed on
 occasion.

 The only thing that has changed between 6.x and 7.0 in this regard is that
 in 7.0, flags have a ->suppress_required field. If set, the parser won't
 complain about "required" options not being provided if the flag is used.
 This is useful for flags which perform a "show current status" function
 for modules which normally have required options.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [ticket:1778 pvanbosgeo]:
 > Normally when you type a command, e.g., g.region, without parameters, a
 new window for that command opens.
 >
 > This does not seem to work for a few commands at the moment. Three ones
 that seem to be affected are g.region, g.rename and g.copy.

 This is normal. If a command doesn't have any required options, executing
 the command without parameters will not open a parameter dialog. You can
 force a parameter dialog to be displayed using the --ui switch.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1662: Caching bug in 3D raster library with large data

[Sören Gebbert]

Sorry for replying directly to the list, but the grass trac server
seems to be down or very, very busy.

Replying to [comment:4 annakrat]:
> I tested it on 32Bit Ubuntu and I get a segmentation fault after 100% is 
> finished. Should I test something else?

Many thanks for the test.

Can you please run the test in the gnu debugger (gdb) again, so that i
can get an idea of what the reason for the segfault is? You can
create a backtrace after the segfault occurred with "bt" in the gdb
session.

Example:

{{{
gdb test.g3d.lib

r unit=large
. segfault
bt
}}}

Can you then please provide the output of the backtrace command "bt"?

2013/8/26 GRASS GIS :
> #1662: Caching bug in 3D raster library with large data
> -+--
>  Reporter:  huhabla  |   Owner:  grass-dev@…
>  Type:  defect   |  Status:  new
>  Priority:  critical |   Milestone:  7.0.0
> Component:  Raster3D | Version:  svn-trunk
>  Keywords:  3D raster, tiles, cache  |Platform:  Linux
>   Cpu:  x86-32   |
> -+--
>
> Comment(by annakrat):
>
>  I tested it on 32Bit Ubuntu and I get a segmentation fault after 100% is
>  finished. Should I test something else?
>
> --
> Ticket URL: 
> GRASS GIS 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1662: Caching bug in 3D raster library with large data

[GRASS GIS]

#1662: Caching bug in 3D raster library with large data
-+--
 Reporter:  huhabla  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Raster3D | Version:  svn-trunk
 Keywords:  3D raster, tiles, cache  |Platform:  Linux
  Cpu:  x86-32   |  
-+--

Comment(by annakrat):

 I tested it on 32Bit Ubuntu and I get a segmentation fault after 100% is
 finished. Should I test something else?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1662: Caching bug in 3D raster library with large data

[GRASS GIS]

#1662: Caching bug in 3D raster library with large data
-+--
 Reporter:  huhabla  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Raster3D | Version:  svn-trunk
 Keywords:  3D raster, tiles, cache  |Platform:  Linux
  Cpu:  x86-32   |  
-+--

Comment(by huhabla):

 The test case for this error has been integrated in the raster3d unit test
 suite:

 {{{
 test.g3d.lib unit=large
 }}}

 The raster3d test suite must be compiled by hand. Simply switch into the
 lib/raster3d/test directory and type make. A new module will be created
 with the name "test.g3d.lib".

 {{{
 GRASS 7.0.svn
 (nc_spm_08_grass7):~/src/grass7.0/grass_trunk/lib/raster3d/test >
 test.g3d.lib help

 Description:
  Performs unit and integration tests for the g3d library

 Usage:
  test.g3d.lib [-uial] [unit=string] [integration=string] [depths=value]
[rows=value] [cols=value] [tile_size=value] [--verbose] [--quiet]

 Flags:
   -u   Run all unit tests
   -i   Run all integration tests
   -a   Run all unit and integration tests
   -l   Switch zip compression on
  --v   Verbose module output
  --q   Quiet module output

 Parameters:
  unit   Choose the unit tests to run
 options: coord,putget,large
   integration   Choose the integration tests to run
 options:
depths   The number of depths to be used for the large file put/get
 value test
 default: 20
  rows   The number of rows to be used for the large file put/get
 value test
 default: 5400
  cols   The number of columns to be used for the large file
 put/get value test
 default: 10800
 tile_size   The tile size in kilo bytes to be used for the large file
 put/get value test. Set the tile size to 2048 and the number of
 row*cols*depths > 13 to reproduce the tile rle error.
 default: 32
 }}}

 I have no 32Bit Linux system to test this issue, but i think it is related
 to the 32Bit address space of the operating system and therefore not a
 bug.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

[Moritz Lennert]

On 26/08/13 08:56, Markus Neteler wrote:

Hi devs,
we should consider to get the preview (!) release out for the FOSS4G
conference in Nottingham in September.


+1

I would love to use it for teaching also, but need a +/- official 
version to get it accepted from our computer room managers.



The wxGUI refactoring done by Anna and Vaclav (sponsored by Fondazione
Edmund Mach) is also in SVN. We should identify the preview blockers
now.


https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&order=priority&priority=critical&priority=blocker&col=id&col=summary&col=priority&col=status&col=type&col=milestone&col=component&milestone=7.0.0

Main blocker IMHO is still the Python and script launching issues (#580 
and #1871, which are related). We did advance a bit, mainly looking at 
the possible solution of using the Python Launcher [1], but then I left 
on vacation and I don't think things have advanced since then. I believe 
that solution is worth some more detailed study and testing.


For other two blockers:

- One has a patch applied that needs testing (#1941, Japanese locale)
- The other (#2017, compilation of osgf library) cannot be reproduced by 
those that have tried. Can others try to reproduce ?


Concerning the critical ones:

- Two concern Windows code page issues (#995, #1288) for which I don't 
really know what a possible solution would be (is it possible to create 
a launcher for GRASS in Python, without using .bat at all ?)


- #1778 concerning modules not launcing GUIs is linked to there being 
not one single required option in these modules. The question raised was 
whether there is a possibility to make at a choice of at least one out 
of a group of options required.


- #1662 has not been confirmed by anyone. Maybe Sören could provide the 
test data.


- #1742 (menus hidden in non-english languages): It seems that the only 
solution besides complete redesign has been to simply make the default 
width of the layer manager larger. If everyone agrees this seems like a 
simple fix.


- #1844 seems to me a mix of different issues, but at least part of it 
seems to be related to the python script issues. I just tried with 
sqlite and it also hung, so this might actually be quite serious.


- #2034 concerns issues on MacOSX apparently linked to the choice of 
Python and wxPython versions. Cannot comment on that.


Moritz

[1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html

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

[GRASS-dev] [GRASS GIS] #2060: Unable to make a deepcopy of a pygrass Module object

[GRASS GIS]

#2060: Unable to make a deepcopy of a pygrass Module object
---+
 Reporter:  huhabla|   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  7.0.0
Component:  Python | Version:  unspecified  
 Keywords:  pygrass, Module, deepcopy  |Platform:  All  
  Cpu:  All|  
---+
 I am trying to make copies of a single pygrass.modules.Module() object
 using copy.deepcopy:

 {{{
 >>> import grass.pygrass as pg
 >>> m = pg.modules.Module("g.region", flags="p", run_=False)
 >>> m.run()
 projection: 99 (Lambert Conformal Conic)
 zone:   0
 datum:  nad83
 ellipsoid:  a=6378137 es=0.006694380022900787
 north:  80
 south:  0
 west:   0
 east:   120
 nsres:  10
 ewres:  10
 rows:   8
 cols:   12
 cells:  96
 >>> import copy
 >>> n = copy.deepcopy(m)
 >>> n.run()
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/soeren/src/grass7.0/grass_trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/pygrass/modules/interface/module.py", line 282, in
 run
 if self.inputs['stdin'].value:
 KeyError: 'stdin'
 }}}

 But it fails with a key error. Looks like (thanks for Pietro's
 investigation) that the _getattr_ function in
 grass.pygrass.modules.interface.typedict may be the problem.[1]

 [1] http://www.peterbe.com/plog/must__deepcopy__

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2060: Unable to make a deepcopy of a pygrass Module object

[GRASS GIS]

#2060: Unable to make a deepcopy of a pygrass Module object
---+
 Reporter:  huhabla|   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  7.0.0
Component:  Python | Version:  svn-trunk
 Keywords:  pygrass, Module, deepcopy  |Platform:  All  
  Cpu:  All|  
---+
Changes (by huhabla):

  * version:  unspecified => svn-trunk


-- 
Ticket URL: 
GRASS GIS 

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