CEGUI (Crazy Eddie's GUI) Forums

Hey,

it seems to me that ItemListBox entries (ItemEntry) currently don't provide any way to create a hover effect on them.
Is that correct?

I tried adding a StateImagery 'Hover' to my looknfeel class for 'ItemEntry', but it showed no effect.
Reviewing the renderer class 'FalagardItemEntry' (Core/Itementry, ItemEntry.cpp), it seems the render() method there does not try to find a 'Hover' StateImagery at all...

What would be the best way to add a hovering effect? Adopt the code from Button?
E.g. add 'd_hovering' field, access it by 'isHovering()' and update it on mouse-move trigger?

Thanks.

Things change(d) a bit. So I need to ask first: CEGUI version?

It's 0.8.5. Sorry, I should have mentioned.
However I checked your repo's head sources and there don't seem to be changes on this.

This is the 'ItemEntry' Falagard class (as far as I understand):
https://bitbucket.org/cegui/cegui/src/e ... ew-default

It does not seem to care whether the element is hovered or has a 'Hover' ImagerySection or not in the render() method there.

These are the classes behind the ItemEntry backing up the layout (couldn't find any hover related there as well)
https://bitbucket.org/cegui/cegui/src/e ... ew-default
https://bitbucket.org/cegui/cegui/src/e ... ew-default

-----------------------

And for comparison, this is the Button (which has hovering):
https://bitbucket.org/cegui/cegui/src/e ... ew-default

For the button, most of the internal implementation for handling hover is in the ButtonBase class:
https://bitbucket.org/cegui/cegui/src/e ... ew-default
https://bitbucket.org/cegui/cegui/src/e ... ew-default

What you just said is pretty much what I would have told you as well So you got it figured out pretty well already

The thing is that in the optimal case, and this is how I would have made this, the list should not care what the hell you wanna display, imo you should be able to just add whatever you want and just specify the size each item will have (and but by default scissored outside the size). I am not 100% sure but I think the default branch already allows some lists to add whatever child windows to its items, or maybe there are none as well. But in 0.8.5 there are definitely none. You will have to write your own ItemEntry class that derives from the ones used for the list and which supports the imagerysections in he way button does. Then it should work afaik. Clearly this aint optimal. Another soluton would be to hook up some event handlers and try to trigger a change via that, but I think that's less elegant and maybe not working well.

Another soluton would be to hook up some event handlers and try to trigger a change via that, but I think that's less elegant and maybe not working well.

Yes, I thought about that, but as you said this isn't a very elegant solutions and there might be others looking for this feature.
I rather thought about adding that functionality to the existing ItemEntry class?

Like:
1) Figure out if this logic may be should and can be handled in the base Window class (because basically any Window can be hovered?)
2) Add a field to track state like ButtonBase has ('d_hovering')
3) Make it accessible like ButtonBase does ('bool isHovering()')
4) Make sure this field is actually set with the correct value
5) Use the 'isHovering()' in Window (or ItemEntry) Falagard classes within render() to select 'Hover' section.

I'm just not really sure how to do (4), need to have a further look at the Button example.
And I'm not sure whether this should be implemented in 'ItemEntry' or may be really should go into 'Window' (which probably would be a larger refactoring) ?

Unfortunately we can't add fields to exposed classes on v0-8 branch because of ABI compatibility. As a workaround you could use a property added to the list of properties. In any case, if you look at default branch you will see this field does not exist anymore there and the thing has been reworked. I think timotei did this.

ItemEntry derives from Window, is there anything that stops us from simply adding a child Window to itemEntry, one of type CEGUI/Button?

is there anything that stops us from simply adding a child Window to itemEntry, one of type CEGUI/Button?

Do you mean as a workaround for my special case?
A Button which will occupy 100% of the area to emulate a hovering ItemEntry?

I think if the button takes 100% of the ItemEntry area, then the current "selection" technique will not work anymore.
Because the selection imagery is part of the ItemEntry layout and therefore behind the button-child.
You would end up with hoverable, but I think not visibly-selectable entries...

Also I think this is a rather hacky solution :-/

Unfortunately we can't add fields to exposed classes on v0-8 branch because of ABI compatibility.

I'm not requiring a quick solution...

From the point of an outsider, I still think that adding at least part of the hovering functionality (e.g. track state) to the 'Window' class itself seems reasonable. At least any Window can be hovered somehow by the mouse, right?

@cyberjunk: As u may have noticed, there has been a flood of questions on the board recently. Unfortunately, @Ident couldn't take the pressure and fled to an unkown location, leaving me to deal with all the mess. Rumors say he'll b back in 2 weeks. I'll try to keep things under control till then.

To me, hovering seems like a feature of any widget, not something specific to a list item. Therefore, I think, it should be implemented for any "Window" object. If you're willing to implement it yourself, we'll try to help u the best we can, and your contribution will be greatly evaluted and you'll b eternally commemorated in cegui's hall of fame.

As @Ident has pointed out, u must b careful with ABI/API compatibility issues, and choose your target branch accordingly.

Just to make this sure.

Is this the branch for API breaking changes?
https://bitbucket.org/cegui/cegui/commits/branch/v0

Or is it this one?
https://bitbucket.org/cegui/cegui/branch/default

And I guess this one is for 0.8 API?
https://bitbucket.org/cegui/cegui/commits/branch/v0-8

API breaking changes go into default branch. v0 is for ABI breaking changes.

.. as u can read here.

@cyberjunk: It's highly recommended that if u want to implement it, u 1st share your plans on how to do it here, to prevent redundant work later.