Sorry, that should have read 'the 4 states to worry about'. Also, I can envision a case where you do multiple selection by dragging a box. In that case, you might go from state 1 to state 4 without going through 2 and 3. Either way, it should be possible to change state from any to any and have the styles keep up.
-- Amos Hayes Geomatics and Cartographic Research Centre Carleton University [email protected] +1.613.520.2600x8179 On 23-Jan-09, at 3:42 PM, Amos Hayes wrote: > Hi Alexandre. > > I like the idea of a stack of styles. > > If we use select (clicked) and hover (moused over) as distinct > terms, then the 4 styles to worry about are: > > 1. Not selected and not hovering (normal) > 2. Not selected but hovering (user is exploring with the mouse) > 3. Selected and hovering (user has made a selection and mouse is > over the selected feature) > 4. Selected but not hovering (user has made a selection but is now > somewhere else with the mouse) > > It should be possible to style each of these feature states > differently. Any style stacking code would have to be able to go > from one to four and back again. Application developers will also > want a way to put the feature directly into any one of those states. > > Hope that helps. > > -- > Amos Hayes > Geomatics and Cartographic Research Centre > Carleton University > [email protected] > +1.613.520.2600x8179 > > On 23-Jan-09, at 3:10 PM, Alexandre Dube wrote: > >> Hi devs, >> >> Eric was right : >> >> <<< >> >> A first note. The current select feature implementation should >> accomodate this use case: two controls on the same layer, one working >> on click and the other on hover, only one of them actually changing >> the feature style. This is achievable by registering a >> beforefeatureselected listener, and have this listener return false. >> Adding beforefeatureunselected might help fully accomodate that use >> case. >> >> Now if we want the two controls to do feature styling, we need the >> stuff I mentioned previously - per-control selectedFeatures arrays >> and >> events. But this is unfortunately not sufficient. Use case: two >> controls, one working on click and the other on hover, both doing >> feature styling but with different render intents. If we have this >> sequence "mouse goes over feature, mouse clicks feature, mouse goes >> out of feature", then the feature ends up being rendered with the >> "default" render intent, while it's still selected from the click >> control's perspective. In most cases, this isn't desirable I think. >> >> At this point I don't have a solution to the above issue. >> >>>>> >> >> An idea that could resolve this issue : features could have a stack >> of >> renderIntent instead of a normal string value. Instead of >> assigning new >> renderIntent value, it would stack in renderIntents array. Instead >> of >> reseting to "default", it would remove the last renderIntent in the >> stack. When the stack is empty, the "default" renderIntent is >> applied. >> >> That could work. I'll try this and come back with more details. >> >> Alexandre >> >> Alexandre Dube wrote: >>> Hi devs, >>> >>> I would like to propose some changes about the SelectFeature >>> control. >>> >>> First, I'll introduce what I want to do : I want to change the color >>> of a feature while the mouse is over it without selecting it. I >>> managed >>> to do this by building a customized control similar to the >>> SelectFeature >>> control named HighlightFeature. I shared the code and some people >>> showed interest in this feature. In fact, it was a good enough to >>> be >>> added to trunk but there was a problem : it's too similar to the >>> SelectFeature control. >>> >>> My first new option was to modify the SelectFeature control to be >>> able >>> to select and highlight. That's what I did, but I hit a wall : I >>> needed >>> to add more new events "beforefeaturehighlighted", >>> "featurehighlighted", >>> etc. a new array of highlightedFeatures, etc... That also became a >>> pain because it was yet an other duplication of something already >>> existant ( similair "select" feature events, an array of selected >>> features, etc....) >>> >>> SO, that brings me to this solution, the first one Eric Lemoine >>> proposed : an array of selectedFeatures and select events for the >>> control ( without removing the ones of the layer ). Doing that, one >>> vector layer could have multiple select feature controls that >>> would know >>> which feature it has selected, they could all have a different >>> renderIntent value ( this is already possible ) or their own style. >>> Then, the user could interact directly with the desired control's >>> selectedFeatures. >>> >>> My example : One SelectFeature that select on click, has the default >>> render intent "select", on which I register a "featureselected" to >>> display a form to fill. And one other SelectFeature that select on >>> hover, has a custom render intent "temporary" to have a different >>> color >>> and an event registered to "featureselected" to display a quick >>> popup of >>> the infos of the hovered feature. >>> >>> Even my DeleteFeature control I created a couple of weeks ago could >>> work by using an other SelectFeature control and using its own >>> featureSelected array. >>> >>> I'll make thoses small changes, an example and propose this as an >>> enhancement. What do you think ? >>> >>> Regards, >>> >>> >> >> >> -- >> Alexandre Dubé >> Mapgears >> www.mapgears.com >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://openlayers.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
