You need to log in before you can comment on or make changes to this bug.
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.
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.
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.
updated version to 1.99
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.
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
Same thing on Fedora Core 1.
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.
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".
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!