Summary: | [Chameleon] TOOLSET Parameter Rules | ||
---|---|---|---|
Product: | Chameleon | Reporter: | Chris Thorne <cthorne@dmsolutions.ca> |
Component: | Widget | Assignee: | Paul Spencer <pspencer@dmsolutions.ca> |
Status: | CLOSED FIXED | ||
Severity: | normal | CC: | chameleon-dev@lists.maptools.org |
Priority: | P3 | ||
Version: | 1.99 | ||
Target Milestone: | 1.99 beta 2 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
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!