Highlighting parts of complex widgets in themes

[Fredrik Höglund]

Hi Karl,

This is pretty much how a style is expected to implement hover effects
for complex controls. The style has to install an event filter and set the
mouse tracking state for widgets, since otherwise mouse tracking
would always have to be enabled for all widgets regardless of whether
the style needs it or not.

An application should never change the mouse tracking state for a non-
custom widget, so that's not an issue. If a custom widget needs to call
drawPrimitve() directly it should assume that the style needs hover
information, and set the Style_MouseOver bit in the style flags as
appropriate. The kicker taskbar buttons do this e.g.

QStyle provides several functions for making this easier though, like
querySubControl(), which tells you which part of a complex control is
under a set of screen coordinates.

What you'd normally do is call this function in your event filter, and
store the return value in a private variable in your style class, along
with a pointer to the hover widget. If either has changed since the last
motion event you repaint the widget.

In drawComplexControl() you then check if the passed widget pointer
matches the hover widget, and then set the Style_MouseOver bit in
the style flags when calling drawPrimitive() to draw the subcontrol
that's hovered.

That way there's no reason to check anything other than the style
flags in drawPrimitive().

Regards,
Fredrik


On Wednesday 17 December 2003 15:05, Karl Vogel wrote:
> Since I like the gnome Simple theme that much and I couldn't find it for
> KDE, I
> thought I'd have a look at implementing it.
>
> The thinice engine (the gtk engine used in the simple theme) has
> highlighting of
> the buttons if you move over them. For normal widgets (e.g. buttons) this
> can be
> achieved by installing an event filter that listens for Enter and Leave
> events.
> (like it's also done in the Plastik theme)
>
> However, this doesn't work for complex widgets like the scrollbar, as it is
> composed of smaller Primitive Elements (arrow up, down, slider). The enter
> and
> leave event is for the entire scrollbar, so that alone can't be used as you
> would highlight the entire widget, while only the Primitive Element should
> be
> highlight.
>
> I currently implemented this by installing an eventfilter on the scrollbar
> that
> also listens for mouse move events and then records the current mouse
> position
> within the widget. Then I issue a repaint and in the drawing code of the
> Primitive Element, I check if the recorded mouse position is within the
> element.
>
> In order to receive the mouse move events, I had to enable mouse tracking
> on the
> widget, which I actived in the polish method of the style.
>
> While this works, I'm wondering if there isn't a better way to do this.. as
> this
> feels kind of hackish and would mock things up if the application changes
> the
> tracking state.
>
> -- Karl