Bug 424 - [Chameleon - Widget] LegendTemplate widget conflicts with LayerManager2
: [Chameleon - Widget] LegendTemplate widget conflicts with LayerManager2
Status: CLOSED FIXED
: Chameleon
Widget
: 1.99
: PC Windows XP
: P1 major
: 1.99 beta 3
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2004-05-28 13:21 by
Modified: 2004-11-02 12:50 (History)


Attachments


Note

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


Description From 2004-05-28 13:21:54
The LegendTemplate widget currently contains code to control layer visibility,
there is no way to turn this off.  The impact is that if the legend template
does not contain the appropriate layer visibility checkboxes, or it is used in
conjunction with a popup widget that does change layer visibility, then
unexpected things happen to layer visibility (like changes made in popups are lost).

The proposed change is to add an attribute to the legendtemplate widget that
would control whether the widget will attempt to set layer visibility or not. 
Turning this off would fix interaction with other widgets, or with templates
that don't contain layer visibility controls at all.
------- Comment #1 From 2004-05-28 13:22:15 -------
fix for the next beta release
------- Comment #2 From 2004-07-05 12:18:07 -------
Please set the target.
------- Comment #3 From 2004-07-07 15:22:01 -------
*** Bug 423 has been marked as a duplicate of this bug. ***
------- Comment #4 From 2004-09-29 12:25:56 -------
thinking about this, perhaps a more flexible change would be to expose the name
of the form variable to use for controlling layer and group visibility.  This
would default to 'legendlayername' (the current hardcoded value for layers) and
'legendgroupname' (the current hardcoded value for groups).

setting one or both to an empty string would effectively turn off layer
visibility processing.

This would also allow use of multiple templates that would present information
in different ways without interferring.

Comments?
------- Comment #5 From 2004-10-06 11:16:59 -------
on second thought I think I will just introduce the original proposed change for
now.
------- Comment #6 From 2004-10-06 11:25:32 -------
implemented new attribute:

CONTROLVISIBILITY="[true|false]"
not required
default is true

if set to FALSE then the widget will not attempt to control visibility.
------- Comment #7 From 2004-10-25 14:02:24 -------
Verified on windows  when looking at bug 764. Which was a duplicate of this
one.
------- Comment #8 From 2004-10-28 10:18:16 -------
I have a question.  I set the "controlvisibility" attribute to "false" the
"legendtemplate" widget in the "sample_enhanced.html" and in the
"tools_enhanced.html" templates.  I'm expecting no control visibility for either
widgets (in "sample_enhanced.html" and in the "tools_enhanced.html" templates).
 But the "legendtemplate" widget in the "tools_enhanced.html" widget is still
controlling the visibility.  What is the expected result?

Also what is the expecting result if both widgets have "controlvisibility" set
to "true"?  Actually only the widget in the "sample_enhanced.html" template has
control over visibility.
------- Comment #9 From 2004-10-28 12:10:32 -------
The controlvisibility parameter was not being used in non-embedded mode, I have
committed a fix for this.  The expected result if two legend templates are used
in  the same application and both control visibility is undefined and depends on
a number of factors, including:

* do both templates include checkboxes (named legendlayername[])?
* is one embedded and one not?
* what order are they in the template?

These will affect which layers get turned on / off.  The original problem with
this was that the embedded legend superceded the popup legend.  The layer state
became mismatched between the application (which would retain the state of the
embedded template) and the popup (which thought it had changed the layer state).

This should be noted in the documentation for the legend template widget I guess.
------- Comment #10 From 2004-11-01 15:57:55 -------
norm this bug need to be verified and closed by Linux :) Windows has already
been done  using beta 3 20041022
------- Comment #11 From 2004-11-02 12:50:26 -------
Verified on Fedora Core 2.