Bug 104 - [Chameleon] TOOLSET Parameter Rules
: [Chameleon] TOOLSET Parameter Rules
Status: CLOSED FIXED
: Chameleon
Widget
: 1.99
: PC Windows 2000
: P3 normal
: 1.99 beta 2
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2003-11-12 11:13 by
Modified: 2004-07-14 11:48 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-11-12 11:13:24
Ok, from what I understand of the role for the TOOLSET parameter is to group
buttons together. When a button is selected and the user can keep on using this
selected tool until another button is selected in the group. 

My first comment/question when would there be times where an application would
have multiple groups of TOOLSET? Wouldn't this cause button selection conflicts?

There can only be one grouping in a single application. If this is true, then
widgets with this parameter should really only have a TRUE|FALSE parameter,
where FALSE is the default when not found in the widget definition.

My second comment deals with what widgets need the TOOLSET parameter. Currently,
the widgets that have this widget are:

ZoomIN, ZoomOUT, Compasspoint, boundingboxpopup, keymap, panmap, query,
recenter, ruler, zoomalllayers, zoomselectedlayers, zoomvisiblelayers

(There could be other widgets, but I only looked in the current Widget HTML
document.)

My comment is that the TOOLSET parameter should really only be applied to
buttons or widgets that require direct interaction with the map, or have a two
step process in order to make a user request. 
For example,

ZOOMIN -> requires that you select the button then you either drag a rectangle
or click on the map to zoom. With the TOOLSET turned on the user can do this
multiple times.

Other widgets that would use the TOOLSET parameter are: Query, ruler, panmap,
recenter and the current ZOOMOUT widget. 

Note: If a new ZoomOUT widget is created where the user does not have to click
the map to zoom out, rather that it takes the current extent of the map and
zooms out by default x2, or uses the ZOOMFactor widget value. ( see bug 25 )

The TOOLSET should only be an option for these “two step widgets” so that the
user can skip the first step if they are planning on using the button multiple
times in a row. The others like Compasspoint, Zoomalllayers are a one-click
process and really should be unselected (which they are) once the request has
been passed to the application.
------- Comment #1 From 2003-11-12 13:23:26 -------
TOOLSET is required as is.  The new Region of Interest widgets make use of this.
 There is a ROI manager that controls how a new ROI is combined with previous
ROIs ... it can be in one of three separate modes - Normal (replace), Add, and
Subtract.  These buttons are mutually exclusive and form a group that is
independent of the navigation buttons.

I agree with the comment that the toolset should only be used on tools that it
makes sense for.  The toolset is a common attribute that is included by default
in all widgets that have that kind of button interface.  I am redesigning how
buttons work to include a type of button that is a single click button, these
widgets will be reworked to use this new type of button.
------- Comment #2 From 2004-04-06 12:06:29 -------
there are now more widgets that have their own toolset, the navtools that apply
to the dynamic keymap widget.

All buttons are now treated the same way and it is possible to put any button
into a toolset.  For some buttons, however, this can cause problems like an
endless loop of submits.  For those widgets, they should ignore the toolset
parameter (and the documentation should reflect that).

To be done for 1.99: review all widgets and determine if they should ignore
toolset or not, fix them and update documentation to indicate that toolset is
ignored.
------- Comment #3 From 2004-04-08 08:40:39 -------
updated version to 1.99
------- Comment #4 From 2004-04-16 10:01:23 -------
modified most non-navigational widgets (specifically ones that are popups) from
being part of a toolset even if set in the widget attributes.  Now only widgets
that can be part of a toolset are allowed to be part of a toolset.
------- Comment #5 From 2004-06-22 17:34:34 -------
I was able to add a toolset parameter to boundingbox widget to:

http://localhost/chameleon/samples/sample_ogc.phtml

and that botton joined the toolset, when it shouldn't because it is a popup.

this was confurmed using beta 2 2004-06-20
------- Comment #6 From 2004-06-28 16:31:22 -------
Same thing on Fedora Core 1.
------- Comment #7 From 2004-07-08 13:51:11 -------
Fixed a problem that is caused by PHP's reference-by-value system that caused
the 'unregistering' of the toolset to not work correctly.  This change affected
many widgets.  Note that it is still possible to set a TOOLSET attribute on
these widgets, but it should be ignored.  The way to validate this is to try to
set a toolset (for instance the same as the zoomin button) and then activate the
tool, the zoomin button should stay selected.
------- Comment #8 From 2004-07-14 11:39:17 -------
Verified on Fedora Core 2 Chameleon 20040709.

I used the "sample_ogc.phtml" application and I modified the "nav_basic.html"
template.  I added the "toolset="Navigation"" attribute to "ZoomIn", "ZoomOut"
and "BoundingBoxPopup".  "ZoomIn" button stays selected eventhough I click "Zoom
to Bounding Box or Point".
------- Comment #9 From 2004-07-14 11:48:50 -------
verified on beta 2 20040709 windows, by 

1) selecting the zoomin in button and then selecting the fullextent button. The
zoomin button should still be the active button once the fullextent has be set.

2) then selected the bounding box popup, and verified that the zoomin button was
still active. Zoomed in, then changed the extents using the bouding box, then
zoomed in again. 

Works great!