Hi Eric. Yes, I realize that and would love to see it.
Since interaction use cases were part of the conversation, I just thought you might be interested in an example of a select/hover/ styling use case that a built-in solution should be able to address. It seems to me it would be a very common use of a dual-mode capable control. -- Amos Hayes Geomatics and Cartographic Research Centre Carleton University [email protected] +1.613.520.2600x8179 On 21-Jan-09, at 12:17 PM, Eric Lemoine wrote: > Hi Amos > > What we're trying to do here is come up with code design that doesn't > require creating new controls. > > Eric > > 2009/1/21, Amos Hayes <[email protected]>: >> >> We've had to implement separate select and hover functionality on top >> of select feature. If you like, have a look at this work in progress: >> >> http://atlas.gcrc.carleton.ca/kitikmeot/ >> >> -- >> Amos Hayes >> Geomatics and Cartographic Research Centre >> Carleton University >> [email protected] >> +1.613.520.2600x8179 >> >> On 21-Jan-09, at 8:34 AM, Alexandre Dube wrote: >> >>> Hey Eric, Ivan, >>> >>> That issue could occur if both controls would actually change the >>> renderIntent of the feature ( without actually selecting the >>> feature ). >>> >>> Let's assume that you can only have one feature hovered at a time ( >>> only one feature can be hovered by the mouse). That said, we could >>> have >>> its renderIntent copied to a this.oldRenderIntent local property, >>> then >>> on "beforefeatureunselected" restore the feature with its old >>> renderIntent. What do you think ? Simple but that could work. >>> >>> Also, can we agree on this : 2 SelectFeature controls both doing >>> selection by click or both by hover are not compatible with multiple >>> styling, so let's forget about this for now. >>> >>> I'll definitively have to try all this soon. >>> >>> Alexandre >>> >>> Eric Lemoine wrote: >>>> Hi >>>> >>>> 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. >>>> >>>> Eric >>>> >>>> 2009/1/20, Alexandre Dube <[email protected]>: >>>> >>>>> Hi Ivan, Eric, >>>>> >>>>> I was actually thinking a similar idea. The more I thought about >>>>> it, >>>>> the more I thought about copying/pasting the SelectFeature >>>>> control, make >>>>> some changes to the copy and name it HighlightFeature. But Eric's >>>>> idea >>>>> is much better. >>>>> >>>>> Having the control itself know which feature it has selected + >>>>> having >>>>> its own events could enable the possibility of having multiple >>>>> SelectFeature controls for a single layer. Having both >>>>> selecting on >>>>> hover and/or click won't matter except for the style and the >>>>> renderIntent applied to the selected feature. I guess the last >>>>> declared >>>>> control would have the last word of determining those... >>>>> >>>>> About that, what if we want 2 different colors for each ctrl ? >>>>> Having >>>>> 2 selectfeature ctrls doing the same thing ( hover and click ) is >>>>> not >>>>> very logic, but let's say one select on hover, the other on click, >>>>> it >>>>> would be nice be able to have 2 different styles for each action. >>>>> But >>>>> how could we do that ? (I guess I don't fully understand the whole >>>>> renderIntent stuff yet... Could we specify a specific >>>>> renderIntent for >>>>> the selectFeature ? Could "select" be the default value and we >>>>> could be >>>>> able to set our own ?) To do so without changing the renderIntent >>>>> of >>>>> the feature is to change its style only, without selecting it. >>>>> >>>>> Ivan's idea (selectOnHover:false) sounds good. I'd like to see >>>>> the >>>>> code and try it. Ivan, could you share what you've done ? At the >>>>> same >>>>> time, I'd like to try to add events to the control and its >>>>> selectedFeatures array, like Eric said. >>>>> >>>>> Finally, I would like to know more about what you think about all >>>>> this. >>>>> >>>>> Best regards, >>>>> >>>>> Alexandre >>>>> >>>>> Ivan Grcic wrote: >>>>> >>>>>> On Mon, Jan 19, 2009 at 10:19 PM, Eric Lemoine >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On Mon, Jan 19, 2009 at 3:30 PM, Alexandre Dube <[email protected] >>>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Eric, >>>>>>>> >>>>>>>> I took a look at the SelectFeature control. Now I understand >>>>>>>> what you >>>>>>>> meant and it makes sense. Also, it's also making sense to have >>>>>>>> this >>>>>>>> control >>>>>>>> have the possibility to highlight on hover or on click. >>>>>>>> >>>>>>>> "beforefeaturehighlighted" and "featurehighlighted" events make >>>>>>>> sense, >>>>>>>> but >>>>>>>> a "featureunhighlighted" (or some other term meaning that the >>>>>>>> feature >>>>>>>> was >>>>>>>> highlighted and is now no more) would also be useful. >>>>>>>> >>>>>>>> >>>>>>> Alexandre, >>>>>>> >>>>>>> The more I think about this highlight feature control the more I >>>>>>> think >>>>>>> there's no room for both a select feature and a highlight >>>>>>> feature >>>>>>> controls. >>>>>>> >>>>>>> >>>>>>> >>>>>> Same opinion here. We already have a bunch of controls, and now >>>>>> adding >>>>>> two very similar ones... >>>>>> >>>>>> Currently im using slightly modified SelectFeature control, i >>>>>> added >>>>>> one more option to it: selectOnHover, thats how i quickly solved >>>>>> the >>>>>> problem of only highlighting feature without selecting it. >>>>>> >>>>>> If selectOnHover is true, feature is selected&higlighted (select >>>>>> method is called) on hover, if its false feature is only >>>>>> higlighted, >>>>>> not selected. >>>>>> >>>>>> >>>>>> >>>>>>> What causes people trouble is that they can't use two select >>>>>>> feature >>>>>>> controls, one in hover mode and the other in click mode. This is >>>>>>> because once a feature is hovered it is selected, and cannot be >>>>>>> selected again when it is clicked. >>>>>>> >>>>>>> Maybe we could modify the select feature control so that (1) it >>>>>>> optionally uses its own selectedFeatures array, as opposed to >>>>>>> relying >>>>>>> on the layer's, and (b) defines its own "beforefeatureselected", >>>>>>> "featureselected" and "featureunselected" event types. In this >>>>>>> way, >>>>>>> one should be able to use two select feature controls, and get >>>>>>> "featureselected" events, from the first control when features >>>>>>> are >>>>>>> hovered and from the second control when features are clicked. >>>>>>> >>>>>>> Tell me what you think, >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> -- >>>>>>> Eric >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> [email protected] >>>>>>> http://openlayers.org/mailman/listinfo/users >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Alexandre Dubé >>>>> Mapgears >>>>> www.mapgears.com >>>>> >>>>> >>>>> >>> >>> >>> -- >>> Alexandre Dubé >>> Mapgears >>> www.mapgears.com >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://openlayers.org/mailman/listinfo/users >> >> _______________________________________________ Users mailing list [email protected] http://openlayers.org/mailman/listinfo/users
