Maybe I misunderstand this process, but I'm confused by this suggestion.
Why take the wxPython GUI out of the GRASS 7 trunk? My understanding is that
we can develop for 6.4 in the 6.4 branch, and as needed develop for 7 in
that branch. Because the GUI operates at a relatively high level--i.e.,
simply a wrapper for GRASS commands in most cases, there will be much that
can simply be done in parallel or via porting across branches
My suggestion would be to take /gui/tcltk out of trunk and leave
/gui/wxpython in. It's the TclTk interface that is going away.
Related to that, I guess we need to think about where the wxPython NVIZ
replacement you are starting to work on will go--6.4 or 7?
Michael
On 4/27/08 7:29 AM, "grass-dev-request@lists.osgeo.org"
<grass-dev-request@lists.osgeo.org> wrote:
Date: Sun, 27 Apr 2008 15:02:57 +0200
From: "Martin Landa" <landa.martin@gmail.com>
Subject: Re: [GRASS-dev] GRASS 7 development started
To: "Markus Neteler" <neteler@osgeo.org>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID:
<f8fe65c40804270602h369de89dm5aca0cf0b332bd8f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
related task --- development of wxPython should continue in
develbranch_6 (for 6.4 release). To avoid confusion I suggest to
remove gui/wxpython from trunk. Any objections?
Regards, Martin
2008/4/27 Markus Neteler <neteler@osgeo.org>:
Today the development of GRASS 6.4 has been moved out into
an own development branch. SVN trunk is now dedicated to GRASS 7
development which includes major refactoring of the code and
improvements to data formats etc.
What does that mean?
- Developers, users, who want to continue to develop GRASS 7:
- do nothing, continue to use and work on SVN trunk
- Developers, users, who want to continue to develop GRASS 6.4:
- Switch our local copy of GRASS-SVN from trunk to "develbranch_6":
cd /path/to/your/local/copy/trunk
svn switch grass - Revision 74509: /grass/branches/develbranch_6 .
This switch will preserve local, uncommited changes.
Please help to make the relevant updated to Web/trac/Wiki pages.
Happy hacking,
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org grass-dev Info Page
--
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Related to that, I guess we need to think about where the wxPython NVIZ
replacement you are starting to work on will go--6.4 or 7?
Just a technical note: Remember that Google will expect to get a tar ball at the end of the summer, please make sure you can easily make a tar ball of your code. Thanks.
2008/4/27 Michael Barton <michael.barton@asu.edu>:
Martin
Maybe I misunderstand this process, but I'm confused by this suggestion.
the reason is to avoid having wxGUI source code in two different
places (trunk and develbranch_6). Then we would be forced to backport
relevant changes from trunk to develbranch_6, etc. Note that changes
in grass7 codebase (now trunk) make in the first period grass7 quite
unusable/highly unstable (from the user's point of view). There is no
need to have wxGUI in trunk in that period. You can always copy
gui/wxpython from develbranch_6 to your local copy of trunk. After
releasing 6.4 and having trunk (grass7) a bit stable the wxGUI code
will be copied to trunk and development of wxGUI will continue in
grass7.
The current wxGUI development is focused on 6.4. From this point of
view I suggest to have wxGUI code only in develbranch_6 for that
period.
Why take the wxPython GUI out of the GRASS 7 trunk? My understanding is that
we can develop for 6.4 in the 6.4 branch, and as needed develop for 7 in
that branch. Because the GUI operates at a relatively high level--i.e.,
simply a wrapper for GRASS commands in most cases, there will be much that
can simply be done in parallel or via porting across branches
The problem here is that trunk will be highly unstable when
development of grass7 starts. I just would like to avoid to have wxGUI
code in two places for that period. Well, wxGUI development can remain
in trunk, but then it should be removed from develbranch_6 -- to avoid
backporting issue. In this perspective it is better move wxGUI
development to develbranch_6. Moreover there will be
releasebranch_6_4.
My suggestion would be to take /gui/tcltk out of trunk and leave
/gui/wxpython in. It's the TclTk interface that is going away.
Related to that, I guess we need to think about where the wxPython NVIZ
replacement you are starting to work on will go--6.4 or 7?
I think at least in the next months (may-august) to develop wxNVIZ in
develbranch_6 (regardless when releasebranch_64 will be created).
2008/4/27 Wolf Bergenheim <wolf+grass@bergenheim.net>:
On 27.04.2008 18:17, Michael Barton wrote:
> Related to that, I guess we need to think about where the wxPython NVIZ
> replacement you are starting to work on will go--6.4 or 7?
>
Just a technical note: Remember that Google will expect to get a tar ball
at the end of the summer, please make sure you can easily make a tar ball of
your code. Thanks.
the reason is to avoid having wxGUI source code in two different
places (trunk and develbranch_6). Then we would be forced to backport
relevant changes from trunk to develbranch_6, etc. Note that changes
in grass7 codebase (now trunk) make in the first period grass7 quite
unusable/highly unstable (from the user's point of view). There is no
need to have wxGUI in trunk in that period. You can always copy
gui/wxpython from develbranch_6 to your local copy of trunk.
Maybe I misunderstand this process, but I'm confused by this suggestion.
Why take the wxPython GUI out of the GRASS 7 trunk? My understanding is that
we can develop for 6.4 in the 6.4 branch, and as needed develop for 7 in
that branch. Because the GUI operates at a relatively high level--i.e.,
simply a wrapper for GRASS commands in most cases, there will be much that
can simply be done in parallel or via porting across branches
My suggestion would be to take /gui/tcltk out of trunk and leave
/gui/wxpython in. It's the TclTk interface that is going away.
This makes sense to me too. I thought development of wxpython GUI in 6.x would stop now - that it being developed there was just because we didn't have a separate repository for 7.x. My understanding has been:
TclTk GUI = legacy stable GUI for 6.x
WxPython GUI = futuristic development GUI for 7.x
(I don't meant to imply the wxpython GUI isn't working nicely and usable with 6.x now, just that I thought that was a "side-effect"...) I guess this is from an "outsider's perspective" really, as I haven't been working on the GUI apart from a few bugfixes to gis.m. But having it like this also makes it very clear and logical from a user's perspective which is important in relation to the expectations they will have from different versions of GRASS IMHO.
2008/4/28 Paul Kelly <paul-grass@stjohnspoint.co.uk>:
Michael:
> Maybe I misunderstand this process, but I'm confused by this suggestion.
>
> Why take the wxPython GUI out of the GRASS 7 trunk? My understanding is
that
> we can develop for 6.4 in the 6.4 branch, and as needed develop for 7 in
> that branch. Because the GUI operates at a relatively high level--i.e.,
> simply a wrapper for GRASS commands in most cases, there will be much that
> can simply be done in parallel or via porting across branches
>
> My suggestion would be to take /gui/tcltk out of trunk and leave
> /gui/wxpython in. It's the TclTk interface that is going away.
>
Paul:
This makes sense to me too. I thought development of wxpython GUI in 6.x
would stop now - that it being developed there was just because we didn't
have a separate repository for 7.x. My understanding has been:
TclTk GUI = legacy stable GUI for 6.x
WxPython GUI = futuristic development GUI for 7.x
I agree with you, anyway I still incline to use for wxGUI development
develbranch_6 for the short period. My initial idea was:
1) to remove gui/wxpython from trunk (or just to 'freeze', i.e. don't
backport from develbranch_6) and use develbranch_6 for wxGUI
development
2) after creating releasebranch_6_4 move wxGUI development to trunk a
backport to develbranch_6/releasebranch_6_4 only bugfixes (depends how
much will be trunk "stable")
(I don't meant to imply the wxpython GUI isn't working nicely and usable
with 6.x now, just that I thought that was a "side-effect"...) I guess this
is from an "outsider's perspective" really, as I haven't been working on the
GUI apart from a few bugfixes to gis.m. But having it like this also makes
it very clear and logical from a user's perspective which is important in
relation to the expectations they will have from different versions of GRASS
IMHO.
This sounds OK to me--though I admit to not following the detailed
intricacies of version control.
Michael
On 4/28/08 7:41 AM, "Martin Landa" <landa.martin@gmail.com> wrote:
Hi,
2008/4/28 Paul Kelly <paul-grass@stjohnspoint.co.uk>:
Michael:
Maybe I misunderstand this process, but I'm confused by this suggestion.
Why take the wxPython GUI out of the GRASS 7 trunk? My understanding is
that
we can develop for 6.4 in the 6.4 branch, and as needed develop for 7 in
that branch. Because the GUI operates at a relatively high level--i.e.,
simply a wrapper for GRASS commands in most cases, there will be much that
can simply be done in parallel or via porting across branches
My suggestion would be to take /gui/tcltk out of trunk and leave
/gui/wxpython in. It's the TclTk interface that is going away.
Paul:
This makes sense to me too. I thought development of wxpython GUI in 6.x
would stop now - that it being developed there was just because we didn't
have a separate repository for 7.x. My understanding has been:
TclTk GUI = legacy stable GUI for 6.x
WxPython GUI = futuristic development GUI for 7.x
I agree with you, anyway I still incline to use for wxGUI development
develbranch_6 for the short period. My initial idea was:
1) to remove gui/wxpython from trunk (or just to 'freeze', i.e. don't
backport from develbranch_6) and use develbranch_6 for wxGUI
development
2) after creating releasebranch_6_4 move wxGUI development to trunk a
backport to develbranch_6/releasebranch_6_4 only bugfixes (depends how
much will be trunk "stable")
(I don't meant to imply the wxpython GUI isn't working nicely and usable
with 6.x now, just that I thought that was a "side-effect"...) I guess this
is from an "outsider's perspective" really, as I haven't been working on the
GUI apart from a few bugfixes to gis.m. But having it like this also makes
it very clear and logical from a user's perspective which is important in
relation to the expectations they will have from different versions of GRASS
IMHO.
Martin
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University