[GRASS-dev] [GRASS-SVN] r61255 - grass/trunk/gui/wxpython/core

On Mon, Jul 14, 2014 at 3:03 PM, <svn_grass@osgeo.org> wrote:

Author: wenzeslaus
Date: 2014-07-14 12:03:34 -0700 (Mon, 14 Jul 2014)
New Revision: 61255

Modified:
   grass/trunk/gui/wxpython/core/utils.py
Log:
wxGUI/core: use gray always, sync purple with lib/gis/color_str.c although
it is probably wrong

before: depending on dict ordering gray or grey was used, (un)checking
Transparent in GUI caused switching from gray to grey
purple: accoring to Wikipedia it is different from violet and was
correctly defined in the GUI before but this was not the same as in library

Modified: grass/trunk/gui/wxpython/core/utils.py

--- grass/trunk/gui/wxpython/core/utils.py 2014-07-14 18:27:46 UTC
(rev 61254)
+++ grass/trunk/gui/wxpython/core/utils.py 2014-07-14 19:03:34 UTC
(rev 61255)
@@ -945,29 +945,37 @@
     # update path
     if addonPath not in os.environ['PATH']:
         os.environ['PATH'] = addonPath + os.pathsep + os.environ['PATH']
-
-# From lib/gis/col_str.c, except purple which is mentioned
-# there but not given RGB values
+
+
+# predefined colors and their names
+# must be in sync with lib/gis/color_str.c
str2rgb = {'aqua': (100, 128, 255),
            'black': (0, 0, 0),
            'blue': (0, 0, 255),
            'brown': (180, 77, 25),
            'cyan': (0, 255, 255),
            'gray': (128, 128, 128),
+ 'grey': (128, 128, 128),
            'green': (0, 255, 0),
- 'grey': (128, 128, 128),
            'indigo': (0, 128, 255),
            'magenta': (255, 0, 255),
            'orange': (255, 128, 0),
- 'purple': (128, 0, 128),
            'red': (255, 0, 0),
            'violet': (128, 0, 255),
+ 'purple': (128, 0, 255),
            'white': (255, 255, 255),
            'yellow': (255, 255, 0)}
rgb2str = {}
-for (s,r) in str2rgb.items():
- rgb2str[ r ] = s
+for (s, r) in str2rgb.items():
+ rgb2str[r] = s
+# ensure that gray value has 'gray' string and not 'grey'
+rgb2str[str2rgb['gray']] = 'gray'
+# purple is defined as nickname for violet in lib/gis
+# (although Wikipedia says that purple is (128, 0, 128))
+# we will prefer the defined color, not nickname
+rgb2str[str2rgb['violet']] = 'violet'

Has somebody some idea about the purple and violet color definitions (in

lib, formerly in GUI, on Wikipedia) before backport to release branch 7.0?
I guess now is the time to change it.

Wikipedia

Violet is (127, 0, 255)
Purple is (128, 0, 128)

http://en.wikipedia.org/wiki/Purple
http://en.wikipedia.org/wiki/Violet_(color)

GRASS GIS

Violet (128, 0, 255)
Purple is the same as Violet (in the same manner as Grey is Gray)

http://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/color_str.c
http://trac.osgeo.org/grass/browser/grass/trunk/include/colors.h
http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/utils.py#L948

+

def color_resolve(color):
     if len(color) > 0 and color[0] in "0123456789":
         rgb = tuple(map(int, color.split(':')))

_______________________________________________
grass-commit mailing list
grass-commit@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit

On Tue, Oct 14, 2014 at 10:24 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:

On Mon, Jul 14, 2014 at 3:03 PM, <svn_grass@osgeo.org> wrote:

Author: wenzeslaus
Date: 2014-07-14 12:03:34 -0700 (Mon, 14 Jul 2014)
New Revision: 61255

Modified:
   grass/trunk/gui/wxpython/core/utils.py
Log:
wxGUI/core: use gray always, sync purple with lib/gis/color_str.c
although it is probably wrong

before: depending on dict ordering gray or grey was used, (un)checking
Transparent in GUI caused switching from gray to grey
purple: accoring to Wikipedia it is different from violet and was
correctly defined in the GUI before but this was not the same as in library

Modified: grass/trunk/gui/wxpython/core/utils.py

--- grass/trunk/gui/wxpython/core/utils.py 2014-07-14 18:27:46 UTC
(rev 61254)
+++ grass/trunk/gui/wxpython/core/utils.py 2014-07-14 19:03:34 UTC
(rev 61255)
@@ -945,29 +945,37 @@
     # update path
     if addonPath not in os.environ['PATH']:
         os.environ['PATH'] = addonPath + os.pathsep + os.environ['PATH']
-
-# From lib/gis/col_str.c, except purple which is mentioned
-# there but not given RGB values
+
+
+# predefined colors and their names
+# must be in sync with lib/gis/color_str.c
str2rgb = {'aqua': (100, 128, 255),
            'black': (0, 0, 0),
            'blue': (0, 0, 255),
            'brown': (180, 77, 25),
            'cyan': (0, 255, 255),
            'gray': (128, 128, 128),
+ 'grey': (128, 128, 128),
            'green': (0, 255, 0),
- 'grey': (128, 128, 128),
            'indigo': (0, 128, 255),
            'magenta': (255, 0, 255),
            'orange': (255, 128, 0),
- 'purple': (128, 0, 128),
            'red': (255, 0, 0),
            'violet': (128, 0, 255),
+ 'purple': (128, 0, 255),
            'white': (255, 255, 255),
            'yellow': (255, 255, 0)}
rgb2str = {}
-for (s,r) in str2rgb.items():
- rgb2str[ r ] = s
+for (s, r) in str2rgb.items():
+ rgb2str[r] = s
+# ensure that gray value has 'gray' string and not 'grey'
+rgb2str[str2rgb['gray']] = 'gray'
+# purple is defined as nickname for violet in lib/gis
+# (although Wikipedia says that purple is (128, 0, 128))
+# we will prefer the defined color, not nickname
+rgb2str[str2rgb['violet']] = 'violet'

Has somebody some idea about the purple and violet color definitions (in

lib, formerly in GUI, on Wikipedia) before backport to release branch 7.0?
I guess now is the time to change it.

Wikipedia

Violet is (127, 0, 255)
Purple is (128, 0, 128)

http://en.wikipedia.org/wiki/Purple
http://en.wikipedia.org/wiki/Violet_(color)

GRASS GIS

Violet (128, 0, 255)
Purple is the same as Violet (in the same manner as Grey is Gray)

http://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/color_str.c
http://trac.osgeo.org/grass/browser/grass/trunk/include/colors.h

http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/utils.py#L948

I cannot go through this again but perhaps somebody can have a look.
Backport this one and change the definitions in library. Or, I would be
fine with saying that this is known issue and fix it in 7.1.