[GRASS-dev] default GUI

Hi,

I changed in r39278 default GUI to wxGUI for GRASS 6.5. With which
default GUI should come GRASS 6.4.0?

Cheers, Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Martin Landa wrote:

I changed in r39278 default GUI to wxGUI for GRASS 6.5. With which
default GUI should come GRASS 6.4.0?

Part of me says that the wx GUI is still beta. OTOH, gis.m hasn't
exactly been devoid of issues either (Colin's release announcement
indicates that more spaces-in-paths bugs have been fixed recently).

What's the timescale for a 6.4.0 release? Is there enough time to
decouple the wx vdigit and nviz modules into separate programs? That
would eliminate the most likely source of major problems.

--
Glynn Clements <glynn@gclements.plus.com>

Hi,

2009/9/22 Glynn Clements <glynn@gclements.plus.com>:

[...]

What's the timescale for a 6.4.0 release? Is there enough time to
decouple the wx vdigit and nviz modules into separate programs? That
would eliminate the most likely source of major problems.

I don't think that there is enough time to do that. First 6.4.0 RC
12/2008, the last (RC5) 7/2009, now we have end of September - it's
seems to me as very very long time for RC stage. I was hoping that we
could release 6.4.0 in April 2009 , then in June, ... and now in
October. To have one year for RCs seems to me as too unacceptable
time... I would be happy to see 6.4.0 out and discuss if we would be
able to change release politics (releases more often, less RCs, etc.)

Initially I was not thinking about wxGUI as default for 6.4.0. Few
days ago some of devs/users started speaking about that. That's not up
me to decide, I cannot compare stability/usability of wxGUI versus
TCL/TK GUI. One of problem of the wxGUI are extensions which are not
separated from the main program (e.g. local copy of PseudoDC is used
when vector digitizer is available otherwise PseudoDC from wxPython is
used which can cause problems sometimes, etc.).

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Glynn:

> What's the timescale for a 6.4.0 release?

Martin:

I don't think that there is enough time to do that.

I agree. Last few fixes then let's release.

First 6.4.0 RC 12/2008, the last (RC5) 7/2009, now we
have end of September - it's seems to me as very very
long time for RC stage.

granted.

but just think of what a nicer result it is and how much better
a product we will ship. for many users (wingrass) this will
be their first try with GRASS. if it came off as buggy and
half-baked they would think the whole package is like that
and not just a few glitches in the MS-facade.

I'm really happy to have the python libraries in good shape now;
if we released in April we would have been stuck with the old..
Same with a number of core module bugs on WinGrass (eg v.?.ogr).

I would be happy to see 6.4.0 out

I think you speak for all of us.

A blocker-blocker is the WinGrass 'g.version -c' bug. We can't
release without an in-program way to show the user the license.
AFAIK only the gis.m help->about gets to to the GPL; the command
line and wx help->about are both broken in different ways.

the other RC bugs are fewer and fewer, some are fixed awaiting
confirmation,
  https://trac.osgeo.org/grass/report/13

(I can finish off the rel. ann. in a day once it looks imminent)

and discuss if we would be able to change release politics
(releases more often, less RCs, etc.)

ok this one went really quite slow but we all had a rather
busy year AFAICT. I agree that faster RCs would be nice, but
where we really needed them (wingrass), when the RCs started
to fall out of date Colin and JEF have both provided interim
svn snapshots. I am not sure about more or fewer RCs, I think
those speak for themselves if they are ready or not. (rc5 ready
on *nix for a long time; but not ms-win, unsurprising) For my
2c I am happy with the philosophy and the especially the result.

The downside with it taking so long is that the powerusers/devels
are no longer using the release version for their day-to-day,
and so the best testers/fixers are not looking at the release
version, focus moves away, and old bugs stagnate. C'est la vie.

fwiw, I forget how long all the 5.0.0pre releases took, I'm
pretty sure it was a bunch more than a year. And 5.1/5.7->6.0
was what, like 3 years at least? 5.0->5.4 3yrs? Hey, we are
gaining speed! We could probably plot something meaningless
from the news history page there :slight_smile:

Initially I was not thinking about wxGUI as default for
6.4.0. Few days ago some of devs/users started speaking
about that.

May I humbly suggest to make that a release goal for 6.4.1 in
~two months time. Hopefully with all C++/wx issues solved and
it will have had lots more testing. 'til then Wx will be heavily
advertised with this release & so should see plenty of exposure.

regards,
Hamish

Although I have softly suggested to use wxGUI for GRASS64 release
I don't really have a strong opinion on that - I was teaching with TclTk GUI
for two semesters, this semester we use wxGUI and both
have their own issues.

One thing I found is that people who learn GRASS
with TclTk GUI have hard time using wxGUI for whatever reason
(not me - I am used to CLI and I think wxGUI is much better).
You just don't find your buttons where they used to be
and that drives people crazy.
Interestingly enough, as Michael has mentioned some time ago,
the old, colorful and somewhat amateurish looking icons are more
popular with some people than the more professional new icons.
So, I would not expect too many people switching to wxGUI with GRASS65
once GRASS64 is out with TclTk GUI - it may need to wait for GRASS7
(which may eventually work better).

As for the long RC cycle - we had that before (I would even say it has always been
like that). It really depends on what you
focus on - if you do a lot of new development work at the same time
when working on RC candidates, that certainly prolongs the cycle.
And Hamish is right - getting winGRASS has consumed some extra time
but it is quite important,

Helena

On Sep 22, 2009, at 6:13 AM, Hamish wrote:

Glynn:

What's the timescale for a 6.4.0 release?

Martin:

I don't think that there is enough time to do that.

I agree. Last few fixes then let's release.

First 6.4.0 RC 12/2008, the last (RC5) 7/2009, now we
have end of September - it's seems to me as very very
long time for RC stage.

granted.

but just think of what a nicer result it is and how much better
a product we will ship. for many users (wingrass) this will
be their first try with GRASS. if it came off as buggy and
half-baked they would think the whole package is like that
and not just a few glitches in the MS-facade.

I'm really happy to have the python libraries in good shape now;
if we released in April we would have been stuck with the old..
Same with a number of core module bugs on WinGrass (eg v.?.ogr).

I would be happy to see 6.4.0 out

I think you speak for all of us.

A blocker-blocker is the WinGrass 'g.version -c' bug. We can't
release without an in-program way to show the user the license.
AFAIK only the gis.m help->about gets to to the GPL; the command
line and wx help->about are both broken in different ways.

the other RC bugs are fewer and fewer, some are fixed awaiting
confirmation,
  https://trac.osgeo.org/grass/report/13

(I can finish off the rel. ann. in a day once it looks imminent)

and discuss if we would be able to change release politics
(releases more often, less RCs, etc.)

ok this one went really quite slow but we all had a rather
busy year AFAICT. I agree that faster RCs would be nice, but
where we really needed them (wingrass), when the RCs started
to fall out of date Colin and JEF have both provided interim
svn snapshots. I am not sure about more or fewer RCs, I think
those speak for themselves if they are ready or not. (rc5 ready
on *nix for a long time; but not ms-win, unsurprising) For my
2c I am happy with the philosophy and the especially the result.

The downside with it taking so long is that the powerusers/devels
are no longer using the release version for their day-to-day,
and so the best testers/fixers are not looking at the release
version, focus moves away, and old bugs stagnate. C'est la vie.

fwiw, I forget how long all the 5.0.0pre releases took, I'm
pretty sure it was a bunch more than a year. And 5.1/5.7->6.0
was what, like 3 years at least? 5.0->5.4 3yrs? Hey, we are
gaining speed! We could probably plot something meaningless
from the news history page there :slight_smile:

Initially I was not thinking about wxGUI as default for
6.4.0. Few days ago some of devs/users started speaking
about that.

May I humbly suggest to make that a release goal for 6.4.1 in
~two months time. Hopefully with all C++/wx issues solved and
it will have had lots more testing. 'til then Wx will be heavily
advertised with this release & so should see plenty of exposure.

regards,
Hamish

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

Martin, Michael,

you may have some advice or fix on this:

after accidentally typing any d.* command (e.g. d.legend)
into Cmd line an error message pops up

layer type <rastleg> not supported yet

This message is causing two major problems:

1. even if you delete the offending d.* command and use the appropriate icon
provided for the task the error message keeps popping up and the best way
to get rid of various erratic behaviors is to quit GRASS. This happens
with d.rast and other d.* commands as well.
Would it be possible to manage this situation in a better way?

2. The message itself is very confusing - people think that you simple
cannot draw a legend because this capability has not been implemented yet.
How about changing it to something
"d.* commands should be run from GUI, see wxGUI Help"
or maybe others can come up with something better?

Helena

Hi,

2009/9/22 Helena Mitasova <hmitaso@unity.ncsu.edu>:

Although I have softly suggested to use wxGUI for GRASS64 release
I don't really have a strong opinion on that - I was teaching with TclTk GUI
for two semesters, this semester we use wxGUI and both
have their own issues.

you can use original icons also in wxGUI, but right wxGUI comes by
default with new icons.

One thing I found is that people who learn GRASS
with TclTk GUI have hard time using wxGUI for whatever reason
(not me - I am used to CLI and I think wxGUI is much better).
You just don't find your buttons where they used to be
and that drives people crazy.

All attempts to change something need its time;-) Anyway I got
impression that wxGUI is better choice for newcomers over TCL/TK GUI
or pure CLI.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

On Tue, Sep 22, 2009 at 8:00 AM, Martin Landa <landa.martin@gmail.com> wrote:

2009/9/22 Glynn Clements <glynn@gclements.plus.com>:

[...]

What's the timescale for a 6.4.0 release? Is there enough time to
decouple the wx vdigit and nviz modules into separate programs? That
would eliminate the most likely source of major problems.

I don't think that there is enough time to do that. First 6.4.0 RC
12/2008, the last (RC5) 7/2009, now we have end of September - it's
seems to me as very very long time for RC stage. I was hoping that we
could release 6.4.0 in April 2009 , then in June, ... and now in
October. To have one year for RCs seems to me as too unacceptable
time...

Or the other way round? We started the 6.4.0 RC business too early...
In any case, despite frustrations about the long release cycle, I would
say that the achieved quality improvements are obvious and unavoidable
to reach stability.

I would be happy to see 6.4.0 out and discuss if we would be
able to change release politics (releases more often, less RCs, etc.)

Yes. And/or start later the RC separation.

Initially I was not thinking about wxGUI as default for 6.4.0. Few
days ago some of devs/users started speaking about that. That's not up
me to decide, I cannot compare stability/usability of wxGUI versus
TCL/TK GUI. One of problem of the wxGUI are extensions which are not
separated from the main program (e.g. local copy of PseudoDC is used
when vector digitizer is available otherwise PseudoDC from wxPython is
used which can cause problems sometimes, etc.).

What do you think about Glynn's latest comment?

Markus

Hi,

2009/9/26 Markus Neteler <neteler@osgeo.org>:

[...]

Initially I was not thinking about wxGUI as default for 6.4.0. Few
days ago some of devs/users started speaking about that. That's not up
me to decide, I cannot compare stability/usability of wxGUI versus
TCL/TK GUI. One of problem of the wxGUI are extensions which are not
separated from the main program (e.g. local copy of PseudoDC is used
when vector digitizer is available otherwise PseudoDC from wxPython is
used which can cause problems sometimes, etc.).

What do you think about Glynn's latest comment?

unfortunately till November I have no time for the wxGUI development.
I will be happy if someone will improve the current design as Glynn
mentioned.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa