Hi,
due to traveling I would like to tag GRASS 6.2.0RC2 later today
as last release candidate.
Still an outstanding TODO is the fix v.digit/toolbox.tcl for tcl8.3.
Hamish apparently solved it but we don't know how.
Release details are here:
http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan
After the 18th of October we can then release GRASS 6.2.0.
Markus
So does that mean, that nviz volume support has been
tested on different scale datasets and will work now?
The website still lists that as an open issue.
GRASS has outstanding voxel capabilities and it would
be so nice to have this working in 6.2 ...
Benjamin
Markus Neteler wrote:
Hi,
due to traveling I would like to tag GRASS 6.2.0RC2 later today
as last release candidate.Still an outstanding TODO is the fix v.digit/toolbox.tcl for tcl8.3.
Hamish apparently solved it but we don't know how.Release details are here:
http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_PlanAfter the 18th of October we can then release GRASS 6.2.0.
Markus
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Hi Benjamin,
Benjamin Ducke wrote on 10/05/2006 10:48 AM:
So does that mean, that nviz volume support has been
tested on different scale datasets and will work now?
unfortunately not.
The website still lists that as an open issue.
Right: it is an open issue.
GRASS has outstanding voxel capabilities and it would
be so nice to have this working in 6.2 ...
True. Unfortunately it was broken earlier this year and nobody
is able to track it down...
Markus
I'm just getting to one of my GRASS digests from yesterday (didn't have much
time to look at email). It turns out that bwidget LabelFrame is not just a
drop in replacement for the tk 8.4 labelframe. For one thing, LabelFrame
seems buggy in the version of bwidgets that GRASS uses and the frame border
will not draw with a label there. Second the options are slightly different.
If you want to replace the labelframe statement in toolbox.tcl (ca. Line
223) with the following and see what happens, I guess go ahead. On my Mac,
running x11, it creates the label but does not draw the box, no matter what
I do. This is problematic, but maybe it at least runs on 8.3. Again, I can't
say if there are any other 8.4 features that won't run on 8.3, so I'm not
sure it's worth it anyway.
I don't know what happens on Mac Aqua or Windows. I'm tied up most of the
rest of the day and so can't test further.
LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
-text [G_msg "mouse button actions (left, right, center)"]
Cheers
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Markus Neteler <neteler@itc.it>
Date: Thu, 5 Oct 2006 09:03:46 +0200
To: GRASS developers list <grass-dev@grass.itc.it>
Subject: [GRASS-dev] GRASS 6.2.0RC2 forthcomingHi,
due to traveling I would like to tag GRASS 6.2.0RC2 later today
as last release candidate.Still an outstanding TODO is the fix v.digit/toolbox.tcl for tcl8.3.
Hamish apparently solved it but we don't know how.Release details are here:
http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_PlanAfter the 18th of October we can then release GRASS 6.2.0.
Markus
Michael Barton wrote:
It turns out that bwidget LabelFrame is not just a drop in replacement
for the tk 8.4 labelframe. For one thing, LabelFrame seems buggy in
the version of bwidgets that GRASS uses and the frame border will not
draw with a label there. Second the options are slightly different.
Yes, I can't get a frame border either. Thanks for translating the options.
There are (Very Good) bwidget instructions and demo.tcl in the GRASS 5
source code. (hopefully you found them?)
[should we copy into GRASS 6 lib/external/bwidget?
252K demo/
368K BWman/
]
cd grass-5.4.0/src/libes/bwidget/demo/
wish demo.tcl
in the demo the LabelFrames borders work correctly, so I think it is
something we are overlooking (???).
If you want to replace the labelframe statement in toolbox.tcl (ca.
Line 223) with the following and see what happens,
I do want to replace it for 6.2,
On my Mac, running x11, it creates the label but does not draw the
box, no matter what I do. This is problematic, but maybe it at least
runs on 8.3.
As it works in demo/demo.tcl, I think it's a fixable bug on our behalf.
( somewhere :-/ window parent/child relationship? lack of content?)
Again, I can't say if there are any other 8.4 features that won't run
on 8.3, so I'm not sure it's worth it anyway.
.. but but but .. are there bwidget replacements for those we can use?
=== (lib/external/bwidget/README.grass) ========
only requires 2 lines of code in your Tcl/Tk script to use the new widgets.
Some of the new widgets include
seems to me that there should be replacements, and we don't (really)
have to worry about finding any we don't know about until we get an
error report. And then it's a (hopefully) quick fix. We are pretty
sure this is the only v.digit problem, and pretty sure that d.m is ok
(so I'm not as worried about gis.m).
LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
-text [G_msg "mouse button actions (left, right, center)"]
works for me (besides missing border). I expect it will work on all
platforms (I can't see why it wouldn't).
An immediate solution: adding "-background HoneyDew" makes the
"-relief groove -borderwidth 1" failure less important.
thanks,
Hamish
Working my way up through digest email. Is the demo that has a border using
the same (old) version of bwidgets that we do? If so, I'll try to look at
the code and see what it's doing that I didn't see.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Hamish <hamish_nospam@yahoo.com>
Date: Sun, 8 Oct 2006 22:03:34 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: tcltk 8.3 and v.digit toolboxMichael Barton wrote:
It turns out that bwidget LabelFrame is not just a drop in replacement
for the tk 8.4 labelframe. For one thing, LabelFrame seems buggy in
the version of bwidgets that GRASS uses and the frame border will not
draw with a label there. Second the options are slightly different.Yes, I can't get a frame border either. Thanks for translating the options.
There are (Very Good) bwidget instructions and demo.tcl in the GRASS 5
source code. (hopefully you found them?)[should we copy into GRASS 6 lib/external/bwidget?
252K demo/
368K BWman/
]cd grass-5.4.0/src/libes/bwidget/demo/
wish demo.tclin the demo the LabelFrames borders work correctly, so I think it is
something we are overlooking (???).If you want to replace the labelframe statement in toolbox.tcl (ca.
Line 223) with the following and see what happens,I do want to replace it for 6.2,
On my Mac, running x11, it creates the label but does not draw the
box, no matter what I do. This is problematic, but maybe it at least
runs on 8.3.As it works in demo/demo.tcl, I think it's a fixable bug on our behalf.
( somewhere :-/ window parent/child relationship? lack of content?)Again, I can't say if there are any other 8.4 features that won't run
on 8.3, so I'm not sure it's worth it anyway... but but but .. are there bwidget replacements for those we can use?
=== (lib/external/bwidget/README.grass) ========
only requires 2 lines of code in your Tcl/Tk script to use the new widgets.
Some of the new widgets includeOn mouse over help balloons
Tabbed notebook panes - like worksheets in Excel
Directory tree listing
Combination box or drop down option list
Progress bar
Many othersseems to me that there should be replacements, and we don't (really)
have to worry about finding any we don't know about until we get an
error report. And then it's a (hopefully) quick fix. We are pretty
sure this is the only v.digit problem, and pretty sure that d.m is ok
(so I'm not as worried about gis.m).LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
-text [G_msg "mouse button actions (left, right, center)"]works for me (besides missing border). I expect it will work on all
platforms (I can't see why it wouldn't).An immediate solution: adding "-background HoneyDew" makes the
"-relief groove -borderwidth 1" failure less important.thanks,
Hamish
Still catching up with a lot of traffic over past 24 hours.
I'll look at the demo file, but giving the frame a honeydew background is a
good substitute if that fails.
We already use bwidgets for most of the widgets listed below. Only in a few
cases (generally noted in the bwidgets docs) have there been new tk widgets
that supercede these. The more complicated issue is changes to existing
TclTk widgets and other syntax. This is only a gism issue as you point out.
It's not that substitutes can't be found or worked out, it's just that I
don't have much in the way of time to do it, and it's additionally difficult
since I'm running 8.4--as are most people who can test. I've already had to
put wxGRASS aside for a month (and am already forgetting what I learned this
past summer) while doing necessary bug fixes on TclTk 8.4 code for 6.2 and
6.3. So I'm not against it as long as it doesn't degrade the UI, I just
don't want to be the person who has to make gism work with 8.3.
On the other hand, as you note, v.digit needs to work with both old and new
GUI. So as long as we maintain d.m, I agree that v.digit should be backward
compatible. So let's get this one set and see what happens next.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Hamish <hamish_nospam@yahoo.com>
Date: Sun, 8 Oct 2006 22:03:34 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolboxMichael Barton wrote:
It turns out that bwidget LabelFrame is not just a drop in replacement
for the tk 8.4 labelframe. For one thing, LabelFrame seems buggy in
the version of bwidgets that GRASS uses and the frame border will not
draw with a label there. Second the options are slightly different.Yes, I can't get a frame border either. Thanks for translating the options.
There are (Very Good) bwidget instructions and demo.tcl in the GRASS 5
source code. (hopefully you found them?)[should we copy into GRASS 6 lib/external/bwidget?
252K demo/
368K BWman/
]cd grass-5.4.0/src/libes/bwidget/demo/
wish demo.tclin the demo the LabelFrames borders work correctly, so I think it is
something we are overlooking (???).If you want to replace the labelframe statement in toolbox.tcl (ca.
Line 223) with the following and see what happens,I do want to replace it for 6.2,
On my Mac, running x11, it creates the label but does not draw the
box, no matter what I do. This is problematic, but maybe it at least
runs on 8.3.As it works in demo/demo.tcl, I think it's a fixable bug on our behalf.
( somewhere :-/ window parent/child relationship? lack of content?)Again, I can't say if there are any other 8.4 features that won't run
on 8.3, so I'm not sure it's worth it anyway... but but but .. are there bwidget replacements for those we can use?
=== (lib/external/bwidget/README.grass) ========
only requires 2 lines of code in your Tcl/Tk script to use the new widgets.
Some of the new widgets includeOn mouse over help balloons
Tabbed notebook panes - like worksheets in Excel
Directory tree listing
Combination box or drop down option list
Progress bar
Many othersseems to me that there should be replacements, and we don't (really)
have to worry about finding any we don't know about until we get an
error report. And then it's a (hopefully) quick fix. We are pretty
sure this is the only v.digit problem, and pretty sure that d.m is ok
(so I'm not as worried about gis.m).LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
-text [G_msg "mouse button actions (left, right, center)"]works for me (besides missing border). I expect it will work on all
platforms (I can't see why it wouldn't).An immediate solution: adding "-background HoneyDew" makes the
"-relief groove -borderwidth 1" failure less important.thanks,
Hamish
I went through the GRASS 5.4 source code and looked at all the bwidget demo
files and tried all permutations of LabelFrame from there. It all comes out
the same on my Mac with x11. I don't know what is up, but I can't get a
border to show up no matter what I do. Maybe it does in 8.3 but not in 8.4.
Maybe it's something else in the v.digit code.
I guess just add -bg honeydew2 to the options and call it good. This looks
nice and gives the same delineation of the mouse buttons as the labelframe
border.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Michael Barton <michael.barton@asu.edu>
Date: Sun, 08 Oct 2006 12:16:43 -0700
To: Hamish <hamish_nospam@yahoo.com>
Cc: <grass-dev@grass.itc.it>
Conversation: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
Subject: Re: [GRASS-dev] Re: tcltk 8.3 and v.digit toolboxStill catching up with a lot of traffic over past 24 hours.
I'll look at the demo file, but giving the frame a honeydew background is a
good substitute if that fails.We already use bwidgets for most of the widgets listed below. Only in a few
cases (generally noted in the bwidgets docs) have there been new tk widgets
that supercede these. The more complicated issue is changes to existing TclTk
widgets and other syntax. This is only a gism issue as you point out. It's not
that substitutes can't be found or worked out, it's just that I don't have
much in the way of time to do it, and it's additionally difficult since I'm
running 8.4--as are most people who can test. I've already had to put wxGRASS
aside for a month (and am already forgetting what I learned this past summer)
while doing necessary bug fixes on TclTk 8.4 code for 6.2 and 6.3. So I'm not
against it as long as it doesn't degrade the UI, I just don't want to be the
person who has to make gism work with 8.3.On the other hand, as you note, v.digit needs to work with both old and new
GUI. So as long as we maintain d.m, I agree that v.digit should be backward
compatible. So let's get this one set and see what happens next.Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbartonFrom: Hamish <hamish_nospam@yahoo.com>
Date: Sun, 8 Oct 2006 22:03:34 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolboxMichael Barton wrote:
It turns out that bwidget LabelFrame is not just a drop in replacement
for the tk 8.4 labelframe. For one thing, LabelFrame seems buggy in
the version of bwidgets that GRASS uses and the frame border will not
draw with a label there. Second the options are slightly different.Yes, I can't get a frame border either. Thanks for translating the options.
There are (Very Good) bwidget instructions and demo.tcl in the GRASS 5
source code. (hopefully you found them?)[should we copy into GRASS 6 lib/external/bwidget?
252K demo/
368K BWman/
]cd grass-5.4.0/src/libes/bwidget/demo/
wish demo.tclin the demo the LabelFrames borders work correctly, so I think it is
something we are overlooking (???).If you want to replace the labelframe statement in toolbox.tcl (ca.
Line 223) with the following and see what happens,I do want to replace it for 6.2,
On my Mac, running x11, it creates the label but does not draw the
box, no matter what I do. This is problematic, but maybe it at least
runs on 8.3.As it works in demo/demo.tcl, I think it's a fixable bug on our behalf.
( somewhere :-/ window parent/child relationship? lack of content?)Again, I can't say if there are any other 8.4 features that won't run
on 8.3, so I'm not sure it's worth it anyway... but but but .. are there bwidget replacements for those we can use?
=== (lib/external/bwidget/README.grass) ========
only requires 2 lines of code in your Tcl/Tk script to use the new widgets.
Some of the new widgets includeOn mouse over help balloons
Tabbed notebook panes - like worksheets in Excel
Directory tree listing
Combination box or drop down option list
Progress bar
Many othersseems to me that there should be replacements, and we don't (really)
have to worry about finding any we don't know about until we get an
error report. And then it's a (hopefully) quick fix. We are pretty
sure this is the only v.digit problem, and pretty sure that d.m is ok
(so I'm not as worried about gis.m).LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
-text [G_msg "mouse button actions (left, right, center)"]works for me (besides missing border). I expect it will work on all
platforms (I can't see why it wouldn't).An immediate solution: adding "-background HoneyDew" makes the
"-relief groove -borderwidth 1" failure less important.thanks,
Hamish
[6.3cvs and 6.2 branch updated to use bwidget's LabelFrame + bg color]
Michael Barton wrote:
Still catching up with a lot of traffic over past 24 hours.
I'm still trying to catch up with last month..
We already use bwidgets for most of the widgets listed below.
ok, it was a new discovery for me.
It's not that substitutes can't be found or worked out, it's just that
I don't have much in the way of time to do it, and it's additionally
difficult since I'm running 8.4--as are most people who can test.
Well, fwiw it only takes me a minute for me to swich in Debian, and I
don't mind living in 8.3. (I had upgraded to 8.4 to test incompatibility
with NVIZ!)
So I'm not against it as long as it doesn't degrade the UI, I just
don't want to be the person who has to make gism work with 8.3.
No worries, the project can deal with these things as they come up. If
any new code goes in, it would be nice if it wasn't known to be 8.4+
only though. (but hopefully all new code will be wx so it won't matter)
On the other hand, as you note, v.digit needs to work with both old
and new GUI. So as long as we maintain d.m, I agree that v.digit
should be backward compatible.
After 6.2.0, why should we maintain d.m? I don't think we have the
manpower to maintain 3 GUIs (see above "trying to catch up..")
Moreover, after 6.2.0 should gis.m be maintained in a minimal "legacy
support" mode until the wx gui is ready?
I went through the GRASS 5.4 source code and looked at all the bwidget
demo files and tried all permutations of LabelFrame from there. It all
comes out the same on my Mac with x11. I don't know what is up, but I
can't get a border to show up no matter what I do. Maybe it does in
8.3 but not in 8.4. Maybe it's something else in the v.digit code.
I had no luck with 8.3. I tried and making a few line demo app which
only contained a frame, but didn't quite get how to get the parent/
child relationship established; my text always drew outside the box.
(so the box was empty / so no box).
I guess just add -bg honeydew2 to the options and call it good. This
looks nice and gives the same delineation of the mouse buttons as the
labelframe border.
done. also switched the order of the (left, right, center) text, as
center was on the right! It might be cleaner to put those words above
each button instead of in the title, but it's fairly self-explanitory
and I'm not too worried about it.
thanks for your help,
Hamish
From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 9 Oct 2006 16:14:47 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: tcltk 8.3 and v.digit toolboxWell, fwiw it only takes me a minute for me to swich in Debian, and I
don't mind living in 8.3. (I had upgraded to 8.4 to test incompatibility
with NVIZ!)So I'm not against it as long as it doesn't degrade the UI, I just
don't want to be the person who has to make gism work with 8.3.No worries, the project can deal with these things as they come up. If
any new code goes in, it would be nice if it wasn't known to be 8.4+
only though. (but hopefully all new code will be wx so it won't matter)
Thanks. This is a big help.
On the other hand, as you note, v.digit needs to work with both old
and new GUI. So as long as we maintain d.m, I agree that v.digit
should be backward compatible.After 6.2.0, why should we maintain d.m? I don't think we have the
manpower to maintain 3 GUIs (see above "trying to catch up..")
Moreover, after 6.2.0 should gis.m be maintained in a minimal "legacy
support" mode until the wx gui is ready?
I am very much in favor of this. I can just barely maintain one GUI and work
on a 2nd--though there is real hope that more people will be able to help on
the wx side.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
From: Hamish <hamish_nospam@yahoo.com>
After 6.2.0, why should we maintain d.m? I don't think we have the
manpower to maintain 3 GUIs (see above "trying to catch up..")
Moreover, after 6.2.0 should gis.m be maintained in a minimal "legacy
support" mode until the wx gui is ready?
I am very much in favor of this. I can just barely maintain one GUI and work
on a 2nd--though there is real hope that more people will be able to help on
the wx side.
I agree d.m should not be developed any further but *please* don't
remove it. gis.m is not ready for production yet (it has still problems
with handling the region) and the wx one, although sounds great and
promising, will long not be ready either. Again, please don't remove d.m.
Maciek