[OpenLayers-Users] Hover control sample (share)
Amos Hayes
ahayes at gcrc.carleton.ca
Wed Jan 21 13:58:38 EST 2009
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
ahayes at gcrc.carleton.ca
+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 <ahayes at gcrc.carleton.ca>:
>>
>> 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
>> ahayes at gcrc.carleton.ca
>> +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 <adube at mapgears.com>:
>>>>
>>>>> 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
>>>>>> <eric.c2c at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On Mon, Jan 19, 2009 at 3:30 PM, Alexandre Dube <adube at mapgears.com
>>>>>>>>
>>>>>>> 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
>>>>>>> Users at openlayers.org
>>>>>>> http://openlayers.org/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Alexandre Dubé
>>>>> Mapgears
>>>>> www.mapgears.com
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Alexandre Dubé
>>> Mapgears
>>> www.mapgears.com
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openlayers.org
>>> http://openlayers.org/mailman/listinfo/users
>>
>>
More information about the Users
mailing list