Hi, I would also add that this idea has the benefit to support multiple SelectFeature at the same time, not just those 4 states. Multiple SelectFeature Control could play together.
Julien Amos Hayes wrote: > 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 > -- Julien-Samuel Lacroix Mapgears http://www.mapgears.com/ _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
