2015-02-04 10:41 GMT+01:00 Markus Neteler <neteler@osgeo.org>:
I don't think that we should start a poll now (voting is happening on
PSC, for other cases we have no voting infrastructure in place).
Setting up a proper poll system is not that easy and requires time
(who can participate, keep poll open for some week(s) etc).
At time it is for RC2 only anyway which we need to get out asap.
I would like to suggest (facing to RC2, which has been already postponed) to:
1) backport current version of splash screen and startup banner as it's in trunk
2) backport also new version startup screen which has been improved in trunk
2015-02-06 14:27 GMT+01:00 Markus Neteler <neteler@osgeo.org>:
Despite all the take this take that discussions and a potential extra
simplified startup it gets into good shape now for RC2.
Should we consider the backport of these changes?
+1 (including new version of startup screen). Martin
Le vendredi 06 février 2015 à 14:28 +0100, Martin Landa a écrit :
I would like to suggest (facing to RC2, which has been already postponed) to:
1) backport current version of splash screen and startup banner as it's in trunk
2) backport also new version startup screen which has been improved in trunk
Then to release RC2, what do you think? Martin
Hi Martin and all,
whatever splash image will be chosen for the time being, please let me
know. I can then post an ultimate clean and optimised png file. For
example the current one (grassy world with black bg) is nearly 500 ko,
but when properly recorded it is only ca. 170 ko for a nearly
unnoticable loss of quality (see attached).
2015-02-06 14:40 GMT+01:00 Vincent Bain <bain@toraval.fr>:
whatever splash image will be chosen for the time being, please let me
know. I can then post an ultimate clean and optimised png file. For
example the current one (grassy world with black bg) is nearly 500 ko,
but when properly recorded it is only ca. 170 ko for a nearly
unnoticable loss of quality (see attached).
right, I can change it in trunk right now, should I used the attached image?
I don’t think that we should start a poll now (voting is happening on
PSC, for other cases we have no voting infrastructure in place).
Setting up a proper poll system is not that easy and requires time
(who can participate, keep poll open for some week(s) etc).
At time it is for RC2 only anyway which we need to get out asap.
I would like to suggest (facing to RC2, which has been already postponed) to:
backport current version of splash screen and startup banner as it’s in trunk
backport also new version startup screen which has been improved in trunk
Despite all the take this take that discussions and a potential extra
simplified startup it gets into good shape now for RC2.
Should we consider the backport of these changes?
+1 (including new version of startup screen). Martin
2015-02-04 10:41 GMT+01:00 Markus Neteler <neteler@osgeo.org>:
I don't think that we should start a poll now (voting is happening on
PSC, for other cases we have no voting infrastructure in place).
Setting up a proper poll system is not that easy and requires time
(who can participate, keep poll open for some week(s) etc).
At time it is for RC2 only anyway which we need to get out asap.
I would like to suggest (facing to RC2, which has been already postponed) to:
1) backport current version of splash screen and startup banner as it's in trunk
2) backport also new version startup screen which has been improved in trunk
Then to release RC2, what do you think? Martin
+1
The only caveat is that I still have that empty window showing up for a while before the image appears shortly before the window disappears.
Apparently the wx.Yield() et line 79 of gui/wxpython/wxgui.py does not have the immediate effect of displaying the image.
Le vendredi 06 février 2015 à 14:54 +0100, Martin Landa a écrit :
right, I can change it in trunk right now, should I used the attached image?
Attached is a clean version (light shades of grey were missing
underneath white lettering -> better readability with it)
Le vendredi 06 février 2015 à 16:55 +0100, Moritz Lennert a écrit :
The only caveat is that I still have that empty window showing up for
a
while before the image appears shortly before the window disappears.
Eventhough it's a very small file, may the lighter png file help reduce
this time of emptiness ?
No, that doesn't seem to help.
I think that this is more a question of program logic:
When I look at the example splashscreen code at [1], I see that the splash screen is defined as a separate class that is called from the wxApp's OnInit function and then calls the main GUI from its OnExit function. Using the example code here with the 400K version of the splash screen works perfectly.
I'm not familiar enough with wxPython and the wxGUI to adapt this quickly, but maybe this could inspire some of the wx gurus...
On Fri, Feb 6, 2015 at 11:32 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:
On 06/02/15 17:09, Vincent Bain wrote:
Le vendredi 06 février 2015 à 14:54 +0100, Martin Landa a écrit :
right, I can change it in trunk right now, should I used the attached
image?
Attached is a clean version (light shades of grey were missing
underneath white lettering -> better readability with it)
Le vendredi 06 février 2015 à 16:55 +0100, Moritz Lennert a écrit :
The only caveat is that I still have that empty window showing up for
a
while before the image appears shortly before the window disappears.
Eventhough it's a very small file, may the lighter png file help reduce
this time of emptiness ?
No, that doesn't seem to help.
I think that this is more a question of program logic:
When I look at the example splashscreen code at [1], I see that the splash
screen is defined as a separate class that is called from the wxApp's
OnInit function and then calls the main GUI from its OnExit function. Using
the example code here with the 400K version of the splash screen works
perfectly.
yes, but on the wiki page, they say:
Although this example will work fine, it overlooks the main reason
programmers add a splash screen; to give the user feedback while a program
is loading.
It first displays splash screen for 1 second and then start to load the
main frame. So this would basically make the gui start even longer.
I don't have problems as you describe so it's difficult to test anything. I
still don'y understand, did you have the same problems with the old splash
screen?
Anna
I'm not familiar enough with wxPython and the wxGUI to adapt this quickly,
but maybe this could inspire some of the wx gurus...
2015-02-06 17:32 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:
When I look at the example splashscreen code at [1], I see that the splash
screen is defined as a separate class that is called from the wxApp's OnInit
function and then calls the main GUI from its OnExit function. Using the
example code here with the 400K version of the splash screen works
perfectly.
I'm not familiar enough with wxPython and the wxGUI to adapt this quickly,
but maybe this could inspire some of the wx gurus...
I modified wxgui.py in trunk (r64489) accordingly. Testing highly welcome.
2015-02-06 17:32 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:
When I look at the example splashscreen code at [1], I see that the splash
screen is defined as a separate class that is called from the wxApp's OnInit
function and then calls the main GUI from its OnExit function. Using the
example code here with the 400K version of the splash screen works
perfectly.
I'm not familiar enough with wxPython and the wxGUI to adapt this quickly,
but maybe this could inspire some of the wx gurus...
I modified wxgui.py in trunk (r64489) accordingly. Testing highly welcome.
The splash screen now looks good, but I get:
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/wxgui.py", line 87, in OnExit
workspace = self.workspaceFile)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/lmgr/frame.py", line 122, in __init__
self._moduleTreeBuilder = LayerManagerModuleTree()
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/lmgr/menudata.py", line 66, in __init__
MenuTreeModelBuilder.__init__(self, fallback)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/core/menutree.py", line 66, in __init__
expAddons(xmlTree)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/core/toolboxes.py", line 274, in expandAddons
_expandRuntimeModules(root)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/core/toolboxes.py", line 515, in _expandRuntimeModules
desc, keywords = _loadMetadata(name)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/gui/wxpython/core/toolboxes.py", line 541, in _loadMetadata
task = gtask.parse_interface(module)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/task.py", line 509, in parse_interface
tree = etree.fromstring(get_interface_description(name))
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/task.py", line 493, in get_interface_description
"\n\nDetails: %(det)s") % {'cmd': cmd, 'det': e}
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 32: ordinal not in range(128)
And the GUI does not appear.
Don't know if this is related to your fix.
2015-02-06 19:56 GMT+01:00 Anna Petrášová <kratochanna@gmail.com>:
Although this example will work fine, it overlooks the main reason
programmers add a splash screen; to give the user feedback while a program
is loading.
this is right.
It first displays splash screen for 1 second and then start to load the main
frame. So this would basically make the gui start even longer.
I don't have problems as you describe so it's difficult to test anything. I
Same here, I wonder if to go back to the previous version of splashscreen.
still don'y understand, did you have the same problems with the old splash
screen?
2015-02-06 19:56 GMT+01:00 Anna Petrá¹ová <kratochanna@gmail.com>:
Although this example will work fine, it overlooks the main reason
programmers add a splash screen; to give the user feedback while a program
is loading.
this is right.
It first displays splash screen for 1 second and then start to load the main
frame. So this would basically make the gui start even longer.
I don't have problems as you describe so it's difficult to test anything. I
Same here, I wonder if to go back to the previous version of splashscreen.
I don't think that the splash screen significantly slows down the start of the GUI, but to solve that issue, if something like wx.Yield() does not work, it seems that the general recommendation is threading, so that the program can load in a separate thread.
still don'y understand, did you have the same problems with the old splash
screen?
I also didn't understand that. Martin
Yes, sorry, I see that I wasn't clear: I'm having the same problem with all versions of GRASS. I don't know if this is related to wxpython 3 ? Maybe wx.Yield() is handled differently now ?
I don't really know for how long this problem has existed, I've just become conscious of it through the discussions on the new splash screen.
But if I'm really the only one with the issue, maybe something's wrong in my config.
On Sat, Feb 7, 2015 at 6:06 AM, Moritz Lennert <mlennert@club.worldonline.be
wrote:
On 07/02/15 10:12, Martin Landa wrote:
Hi,
2015-02-06 19:56 GMT+01:00 Anna Petrášová <kratochanna@gmail.com>:
Although this example will work fine, it overlooks the main reason
programmers add a splash screen; to give the user feedback while a
program
is loading.
this is right.
It first displays splash screen for 1 second and then start to load the
main
frame. So this would basically make the gui start even longer.
I don't have problems as you describe so it's difficult to test
anything. I
Same here, I wonder if to go back to the previous version of splashscreen.
I don't think that the splash screen significantly slows down the start of
the GUI, but to solve that issue, if something like wx.Yield() does not
work, it seems that the general recommendation is threading, so that the
program can load in a separate thread.
I am not sure how to do that, generally GUI should be always in the main
thread. We could try to make the start faster by importing some parts of
gui only when they are needed, but I am not sure if that will cause
significant speed up.
still don'y understand, did you have the same problems with the old
splash
screen?
I also didn't understand that. Martin
Yes, sorry, I see that I wasn't clear: I'm having the same problem with
all versions of GRASS. I don't know if this is related to wxpython 3 ?
Maybe wx.Yield() is handled differently now ?
I don't really know for how long this problem has existed, I've just
become conscious of it through the discussions on the new splash screen.
But if I'm really the only one with the issue, maybe something's wrong in
my config.
I didn't have any problem with or without wxPython 3, but I have a new fast
laptop. I would keep the new splash screen in trunk, maybe not put it in
release since it changes start up mechanism and that should be tested more.
On Sat, Feb 7, 2015 at 4:01 AM, Moritz Lennert <mlennert@club.worldonline.be
wrote:
On 07/02/15 09:44, Martin Landa wrote:
Hi,
2015-02-06 17:32 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:
When I look at the example splashscreen code at [1], I see that the
splash
screen is defined as a separate class that is called from the wxApp's
OnInit
function and then calls the main GUI from its OnExit function. Using the
example code here with the 400K version of the splash screen works
perfectly.
I'm not familiar enough with wxPython and the wxGUI to adapt this
quickly,
but maybe this could inspire some of the wx gurus...
I modified wxgui.py in trunk (r64489) accordingly. Testing highly welcome.
The splash screen now looks good, but I get:
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-
unknown-linux-gnu/gui/wxpython/wxgui.py", line 87, in OnExit
workspace = self.workspaceFile)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-
unknown-linux-gnu/gui/wxpython/lmgr/frame.py", line 122, in __init__
self._moduleTreeBuilder = LayerManagerModuleTree()
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-
unknown-linux-gnu/gui/wxpython/lmgr/menudata.py", line 66, in __init__
MenuTreeModelBuilder.__init__(self, fallback)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-
unknown-linux-gnu/gui/wxpython/core/menutree.py", line 66, in __init__
expAddons(xmlTree)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-
unknown-linux-gnu/gui/wxpython/core/toolboxes.py", line 274, in
expandAddons
_expandRuntimeModules(root)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-
unknown-linux-gnu/gui/wxpython/core/toolboxes.py", line 515, in
_expandRuntimeModules
desc, keywords = _loadMetadata(name)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-
unknown-linux-gnu/gui/wxpython/core/toolboxes.py", line 541, in
_loadMetadata
task = gtask.parse_interface(module)
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-
unknown-linux-gnu/etc/python/grass/script/task.py", line 509, in
parse_interface
tree = etree.fromstring(get_interface_description(name))
File "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-
unknown-linux-gnu/etc/python/grass/script/task.py", line 493, in
get_interface_description
"\n\nDetails: %(det)s") % {'cmd': cmd, 'det': e}
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 32:
ordinal not in range(128)
And the GUI does not appear.
Don't know if this is related to your fix.
not really, it is related to addons loading. I don't understand the
UnicodeDecodeError, do you by any chance use some where non ascii
characters in addon path?
2015-02-06 17:09 GMT+01:00 Vincent Bain <bain@toraval.fr>:
Attached is a clean version (light shades of grey were missing
underneath white lettering -> better readability with it)
Eventhough it's a very small file, may the lighter png file help reduce
this time of emptiness ?
2015-02-07 14:16 GMT+01:00 Anna Petrášová <kratochanna@gmail.com>:
not really, it is related to addons loading. I don't understand the
UnicodeDecodeError, do you by any chance use some where non ascii characters
in addon path?
right, could you try to launch your addons from terminal? I can
reproduce this error, eg.
i.edge
i.edge: error while loading shared libraries:
libgrass_gis.7.0.0svn.so: cannot open shared object file: No such file
or directory
I don't know why this error was skipped with old splashscreen.
On Sat, Feb 7, 2015 at 2:28 PM, Martin Landa <landa.martin@gmail.com> wrote:
2015-02-07 20:24 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
> right, could you try to launch your addons from terminal? I can
> reproduce this error, eg.
>
> i.edge
> i.edge: error while loading shared libraries:
> libgrass_gis.7.0.0svn.so: cannot open shared object file: No such file
> or directory
>
> I don't know why this error was skipped with old splashscreen.
quick attempt to fix it in r64499 (would need more investigation). Martin
Are you sure it's caused by the splash screen loading change? Can you
confirm that the previous version is working? I don't have any problems.