Hi
I was wondering if the wxPython GUI is going to deal with problems the
tcl/tk GUI can't - when there is a set of pre-defined parameters to
choose from and the user should be able to decide about the order of them.
An example is v.type [1], for which in the tcl/tk GUI you can specify
the order of types only one way, eg. 'type=point,centroid', but
'type=centroid,point' is impossible to achieve.
[1]http://intevation.de/rt/webrt?serial_num=2969
Maciek
On 5/22/07 2:44 PM, "Maciej Sieczka" <tutey@o2.pl> wrote:
Hi
I was wondering if the wxPython GUI is going to deal with problems the
tcl/tk GUI can't - when there is a set of pre-defined parameters to
choose from and the user should be able to decide about the order of them.An example is v.type [1], for which in the tcl/tk GUI you can specify
the order of types only one way, eg. 'type=point,centroid', but
'type=centroid,point' is impossible to achieve.[1]http://intevation.de/rt/webrt?serial_num=2969
Maciek
I agree that this is an annoying problem that makes v.type almost unusable
from the autogenerated GUI. wxPython as a platform won't inherently be able
to improve this, because the autogenerated dialogs can only display what is
included in the parser strings of the C-command. BUT... this is a very good
time to think of a better way to get this formatted in the C module so that
the dialogs generated in wxPython (and even TclTk) can be useable.
One suggestion that I have at the moment is that, instead of being coded so
that they end up as check boxes, the possible values for type (line,
boundary, etc) should not be coded as values and "type" should simply be a
text entry. Then the user can simply type in which combination she/he wants
(e.g., line,boundary).
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
Maciej Sieczka wrote:
I was wondering if the wxPython GUI is going to deal with problems the
tcl/tk GUI can't - when there is a set of pre-defined parameters to
choose from and the user should be able to decide about the order of
them.An example is v.type [1], for which in the tcl/tk GUI you can specify
the order of types only one way, eg. 'type=point,centroid', but
'type=centroid,point' is impossible to achieve.
maybe use a wrapper script that has the possible combinations as flags?
point -> centroid
[*] centroid -> point
line -> boundary
boundary -> line
standy by.. I'll write one.
Hamish
Maciej Sieczka wrote:
> I was wondering if the wxPython GUI is going to deal with problems
> the tcl/tk GUI can't - when there is a set of pre-defined parameters
> to choose from and the user should be able to decide about the order
> of them.
>
> An example is v.type [1], for which in the tcl/tk GUI you can
> specify the order of types only one way, eg. 'type=point,centroid',
> but 'type=centroid,point' is impossible to achieve.
>
> [1]http://intevation.de/rt/webrt?serial_num=2969
Hamish:
maybe use a wrapper script that has the possible combinations as
flags?point -> centroid
[*] centroid -> point
line -> boundary
boundary -> linestandy by.. I'll write one.
gui/tcltk/gis.m/script/v.type.sh
added in 6.3cvs + Tcl gui menu updated. I'll backport to 6.2 if others
report success. The help page link disappears, but the v.type help
page isn't much to read anyway. Uses /bin/sh, so not for native Windows.
to keep the option list short, point->kernel etc. are not supported
directly, you have to go point->centroid, centroid->kernel.
I notice a small bug in the GUI module window. After selecting an item
from a pulldown list, it doesn't visually update the command line string
along the bottom until you click something else. Clicking [Run] or
[Copy] updates it, so no functional error, but it would be nice if that
could be refreshed by the menu selection process. (tcl tk 8.3)
Hamish
Michael Barton wrote:
> I was wondering if the wxPython GUI is going to deal with problems the
> tcl/tk GUI can't - when there is a set of pre-defined parameters to
> choose from and the user should be able to decide about the order of them.
>
> An example is v.type [1], for which in the tcl/tk GUI you can specify
> the order of types only one way, eg. 'type=point,centroid', but
> 'type=centroid,point' is impossible to achieve.
>
> [1]http://intevation.de/rt/webrt?serial_num=2969I agree that this is an annoying problem that makes v.type almost unusable
from the autogenerated GUI. wxPython as a platform won't inherently be able
to improve this, because the autogenerated dialogs can only display what is
included in the parser strings of the C-command. BUT... this is a very good
time to think of a better way to get this formatted in the C module so that
the dialogs generated in wxPython (and even TclTk) can be useable.
The problem isn't with the information in the module, but with the
fact that the GUI mistakenly assumes that the order is irrelevant for
options with "opt->multiple == YES && opt->options != NULL".
[A related issue is that it assumes that each option will occur at
most once, when this doesn't have to be the case.]
IOW, the GUI assumes that the value is a set when it's really a list.
Now, it would be useful for the module to be able to assert that the
value really is a set rather than a list, so that the GUI can offer
more specific interfaces, but there's no reason why the GUI cannot
just assume lists rather than sets.
--
Glynn Clements <glynn@gclements.plus.com>
It might well be possible to parse the existing interface description
better. Perhaps Daniel will be able to look at it more. But, it's hard to
imagine how to create a set of check boxes in such a way to generate a
variable set of type pairs (line,boundary, point,centroid). Perhaps, it
would be easiest to create an options list of permissible pairs (i.e.,
point,area won't work) that the user can select from. This means that the
values would have to be specified differently in the values list of the
original module. The only down side to this is that it doesn't permit
multiple type pairs to be run simultaneously (e.g.,
point,centroid,line,boundary). I'm not sure whether it makes sense to have
more than 2 type pairs at the most.
Michael
On 5/22/07 10:52 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
The problem isn't with the information in the module, but with the
fact that the GUI mistakenly assumes that the order is irrelevant for
options with "opt->multiple == YES && opt->options != NULL".[A related issue is that it assumes that each option will occur at
most once, when this doesn't have to be the case.]IOW, the GUI assumes that the value is a set when it's really a list.
Now, it would be useful for the module to be able to assert that the
value really is a set rather than a list, so that the GUI can offer
more specific interfaces, but there's no reason why the GUI cannot
just assume lists rather than sets.
__________________________________________
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
Can't these just be options/flags for v.type? The user could set one or
more.
Michael
On 5/22/07 9:33 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
maybe use a wrapper script that has the possible combinations as flags?
point -> centroid
[*] centroid -> point
line -> boundary
boundary -> linestandy by.. I'll write one.
__________________________________________
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
Hamish:
> maybe use a wrapper script that has the possible combinations as
> flags?
Michael Barton wrote:
Can't these just be options/flags for v.type? The user could set one
or more.
This makes for a lot of flags.
And how to set flags as mutually exclusive radio buttons not checkboxes?
point -> centroid
[*] centroid -> point
line -> boundary
boundary -> line
kernel -> centroid
centroid -> kernel
face -> boundary
boundary -> face
kernel -> point
point -> kernel
face -> line
line -> face
or add two options:
from=[list]
to=[list]
then testing of to/from compatibility in the code?
I don't think allowing multiple operations in the same run is so clear.
(type=line,boundary,point,centroid)
??
Hamish
Hamish wrote:
gui/tcltk/gis.m/script/v.type.sh
Cool!
added in 6.3cvs + Tcl gui menu updated. I'll backport to 6.2 if others
report success. The help page link disappears,
Too bad.
but the v.type help page isn't much to read anyway.
Uses /bin/sh, so not for native Windows.
to keep the option list short, point->kernel etc. are not supported
directly, you have to go point->centroid, centroid->kernel.
How much longer would the list be if centroid->kernel etc. were added?
I notice a small bug in the GUI module window. After selecting an item
from a pulldown list, it doesn't visually update the command line string
along the bottom until you click something else. Clicking [Run] or
[Copy] updates it, so no functional error, but it would be nice if that
could be refreshed by the menu selection process. (tcl tk 8.3)
Same on tcl/tk 8.4, for several months now.
Maciek
Michael Barton wrote:
It might well be possible to parse the existing interface description
better. Perhaps Daniel will be able to look at it more. But, it's hard to
imagine how to create a set of check boxes in such a way to generate a
variable set of type pairs (line,boundary, point,centroid).
You can't do it with check boxes alone.
A common interface for editing lists is with two list boxes, one
containing the available options, and one containing the edited list.
In addition, there are buttons to add an option to the list, remove an
option, and to move options up or down. Some of this functionality may
also be available by dragging items within and between the list boxes.
If you have the restriction that an option can only appear once,
adding it to the list removes it from the set of available options,
and removing it from the list returns it to the set of available
options.
An example can be found in the Windows XP explorer (file manager), via
the "View -> Toolbars -> Customize..." menu option.
--
Glynn Clements <glynn@gclements.plus.com>
Hi coworkers
I have a Fedora core 6 computer, with grass 5.4. When I try to run
v.digit, g.region, r.in.gdal the program shows these messages:
v.digit: error while loading shared libraries: libproj.so.0: cannot open
shared object file: No such file or directory
g.region: error while loading shared libraries: libproj.so.0: cannot
open shared object file: No such file or directory
r.in.gdal: error while loading shared libraries: libgdal.so.1: cannot
open shared object file: No such file or directory
I had downloaded the RPM resource libproj.so.0()(64bit)
proj-4.5.0-1.fc6.x86_64.html Cartographic projection software (PROJ.4)
Fedora Extras 6 for x86_64, but when I try to intall it, the dialog box
says "It's already installed", however the errors in grass continue.
Thanks for help me.
Juan Diego Giraldo Osorio
Universidad Politécnica de Cartagena
España
HB:
> to keep the option list short, point->kernel etc. are not supported
> directly, you have to go point->centroid, centroid->kernel.
MS:
How much longer would the list be if centroid->kernel etc. were added?
No so long. All combination now present in cvs.
Hamish
Juan Diego Giraldo Osorio wrote:
I have a Fedora core 6 computer, with grass 5.4. When I try to run
v.digit, g.region, r.in.gdal the program shows these messages:v.digit: error while loading shared libraries: libproj.so.0: cannot
open shared object file: No such file or directoryg.region: error while loading shared libraries: libproj.so.0: cannot
open shared object file: No such file or directoryr.in.gdal: error while loading shared libraries: libgdal.so.1: cannot
open shared object file: No such file or directoryI had downloaded the RPM resource libproj.so.0()(64bit)
proj-4.5.0-1.fc6.x86_64.html Cartographic projection software (PROJ.4)
Fedora Extras 6 for x86_64, but when I try to intall it, the dialog
box says "It's already installed", however the errors in grass
continue.
try:
locate libproj
locate libgdal
you may need to add symlinks to "libproj.so.0" and "libgdal.so.1" from
whatever filenames they are installed as. However ...
The GRASS 5 binary may be too old to assume that the PROJ and GDAL
libraries will be compatible with what the binary package expects. If
you want to use GRASS 5.4 with newer PROJ and GDAL, you may have to
recompile it by hand.
Hamish
I've only done a limited amount of work on the autogenerated properties
dialogs. Daniel has done much more on wxgrass and Cedrick did most of the
updates to the TclTk one. So with that disclaimer...
This is certainly a nice interface (JMP stats uses it too). The issue is
that the autogenerated dialogs depend on the xml interface hints to create
their GUI. There would need to be some kind consistent hint in the module
code to prompt either gui to build and populate the correct kind of widgets
appropriately.
From my look at the xml generated by v.type, it doesn't seem to do a very
good job at this currently, resulting in a minimally functional
autogenerated dialog. Maybe there are hints there that I'm not
understanding. But it looks like we could do with better interface hints
with this module (at least having values as acceptable type pairs rather
than as single types would make it easier) and then finding a way to
transform them into a better interface.
That said, are there other modules that could benefit from the same kind of
interface, or is this the only one? I can't think of any, but it's still
early and there are 300+ modules.
Michael
On 5/23/07 12:46 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
It might well be possible to parse the existing interface description
better. Perhaps Daniel will be able to look at it more. But, it's hard to
imagine how to create a set of check boxes in such a way to generate a
variable set of type pairs (line,boundary, point,centroid).You can't do it with check boxes alone.
A common interface for editing lists is with two list boxes, one
containing the available options, and one containing the edited list.
In addition, there are buttons to add an option to the list, remove an
option, and to move options up or down. Some of this functionality may
also be available by dragging items within and between the list boxes.If you have the restriction that an option can only appear once,
adding it to the list removes it from the set of available options,
and removing it from the list returns it to the set of available
options.An example can be found in the Windows XP explorer (file manager), via
the "View -> Toolbars -> Customize..." menu option.
__________________________________________
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:
are there other modules that could benefit from the same kind of
interface, or is this the only one?
After a quick look:
v.clean - differenet order of cleaning tools might produce a deifferent
output.
g.list, g.mlist - one might care eg. if his rasters or vectors come
listed first.
r.report - same possible concern as above, in regard to units.
Maybe some other modules apply.
Out of these above v.clean is serious.
Maciek
Thanks.
Michael
On 5/23/07 2:09 PM, "Maciej Sieczka" <tutey@o2.pl> wrote:
Michael Barton wrote:
are there other modules that could benefit from the same kind of
interface, or is this the only one?After a quick look:
v.clean - differenet order of cleaning tools might produce a deifferent
output.g.list, g.mlist - one might care eg. if his rasters or vectors come
listed first.r.report - same possible concern as above, in regard to units.
Maybe some other modules apply.
Out of these above v.clean is serious.
Maciek
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
>> It might well be possible to parse the existing interface description
>> better. Perhaps Daniel will be able to look at it more. But, it's hard to
>> imagine how to create a set of check boxes in such a way to generate a
>> variable set of type pairs (line,boundary, point,centroid).
>
> You can't do it with check boxes alone.
>
> A common interface for editing lists is with two list boxes, one
> containing the available options, and one containing the edited list.
> In addition, there are buttons to add an option to the list, remove an
> option, and to move options up or down. Some of this functionality may
> also be available by dragging items within and between the list boxes.
>
> If you have the restriction that an option can only appear once,
> adding it to the list removes it from the set of available options,
> and removing it from the list returns it to the set of available
> options.
>
> An example can be found in the Windows XP explorer (file manager), via
> the "View -> Toolbars -> Customize..." menu option.I've only done a limited amount of work on the autogenerated properties
dialogs. Daniel has done much more on wxgrass and Cedrick did most of the
updates to the TclTk one. So with that disclaimer...This is certainly a nice interface (JMP stats uses it too). The issue is
that the autogenerated dialogs depend on the xml interface hints to create
their GUI. There would need to be some kind consistent hint in the module
code to prompt either gui to build and populate the correct kind of widgets
appropriately.From my look at the xml generated by v.type, it doesn't seem to do a very
good job at this currently, resulting in a minimally functional
autogenerated dialog. Maybe there are hints there that I'm not
understanding. But it looks like we could do with better interface hints
with this module (at least having values as acceptable type pairs rather
than as single types would make it easier) and then finding a way to
transform them into a better interface.That said, are there other modules that could benefit from the same kind of
interface, or is this the only one? I can't think of any, but it's still
early and there are 300+ modules.
In the absence of additional information, you need to use the above
interface for any option with ->multiple==YES and ->options!=NULL.
I.e. everywhere that multiple checkboxes are currently being used.
--interface-description etc can only output the information which they
have available, i.e. the fields in the Flag and Option structures.
At present, there is no way for a module to indicate that it doesn't
care about the order. All of the autogenerated GUIs (including the
basic --ui implementation in lib/gis/gui.tcl) simply assume this to be
true, which falls down with v.type (and quite possibly other modules).
Similarly, there is no way to indicate that certain combinations are
valid. AFAICT, the only realistic solution is to make each valid
combination a distinct option, e.g.:
type_opt->options = "point/centroid,centroid/point,line/boundary,boundary/line,...";
BTW, with the existing mechanism, v.type should probably have:
type_opt->key_desc="from,to";
to indicate that the options have to come in pairs.
Ultimately, there are two issues here.
1. The GUI doesn't allow the user to specify the order of options.
This is a bug.
2. The Option structure doesn't have any way to indicate whether the
order is important, or whether options can appear multiple times. This
is a wish.
Even if #2 is dealt with, #1 still has to be dealt with for the case
where the module indicates that the order really is important. Once #1
is dealt with, #2 is just an issue of providing more specific
interfaces. A list interface can be used for both lists and sets, but
a set interface won't work for lists.
--
Glynn Clements <glynn@gclements.plus.com>
Maciej Sieczka wrote:
> but the v.type help page isn't much to read anyway.
> Uses /bin/sh, so not for native Windows.> to keep the option list short, point->kernel etc. are not supported
> directly, you have to go point->centroid, centroid->kernel.How much longer would the list be if centroid->kernel etc. were added?
AFAICT, there are 12 valid combinations:
centroid->kernel
centroid->point
kernel->centroid
kernel->point
point->centroid
point->kernel
boundary->face
boundary->line
face->boundary
face->line
line->boundary
line->face
--
Glynn Clements <glynn@gclements.plus.com>
Hamish wrote:
> > maybe use a wrapper script that has the possible combinations as
> > flags?Michael Barton wrote:
> Can't these just be options/flags for v.type? The user could set one
> or more.This makes for a lot of flags.
And how to set flags as mutually exclusive radio buttons not checkboxes?
point -> centroid
[*] centroid -> point
line -> boundary
boundary -> line
kernel -> centroid
centroid -> kernel
face -> boundary
boundary -> face
kernel -> point
point -> kernel
face -> line
line -> faceor add two options:
from=[list]
to=[list]then testing of to/from compatibility in the code?
I don't think allowing multiple operations in the same run is so clear.
(type=line,boundary,point,centroid)
Each type can only be converted at most once, so the most general case
is 6 x 3-way choices, i.e.
(*) point -> centroid
( ) point -> kernel
( ) point -> point (i.e. leave untouched)
(*) kernel -> centroid
( ) kernel -> point
( ) kernel -> kernel (i.e. leave untouched)
...
Multiple operations shouldn't be a problem; you just need to test the
original type, not the resulting type, so selecting both
point->centroid and centroid->kernel doesn't convert
point->centroid->kernel.
IOW, a "case" statement or an if/else-if/else-if/else structure rather
than sequential "if" statements.
--
Glynn Clements <glynn@gclements.plus.com>
Why can't these simply be the valid options allowed for type and listed in
interface description in this way (or something acceptable to the module).
Wouldn't that generate a pulldown combobox with these combinations to select
from?
Michael
On 5/23/07 5:24 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Maciej Sieczka wrote:
but the v.type help page isn't much to read anyway.
Uses /bin/sh, so not for native Windows.to keep the option list short, point->kernel etc. are not supported
directly, you have to go point->centroid, centroid->kernel.How much longer would the list be if centroid->kernel etc. were added?
AFAICT, there are 12 valid combinations:
centroid->kernel
centroid->point
kernel->centroid
kernel->point
point->centroid
point->kernelboundary->face
boundary->line
face->boundary
face->line
line->boundary
line->face
__________________________________________
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