Re: GtkScrollbar marker API discussion



Hey guys,
I've finally come up with a patch to implement this:
https://bugzilla.gnome.org/show_bug.cgi?id=623712

The patch basically calls range's expose from scrollbar, and then
paint the markers on top, once that's done, the slider is painted
again on top. If there's anyone with the Nimbus theme or other theme
with non sqared sliders, please let me know how it behaves.

The patch adds simple marker support, no different classes/colours or
tooltip strings. Honestly I think this API solves 90% of the problem
and the code is maintaneable enough, plus adding themeable markers
would be a nightmare implementation wise, it'll be a pain for themers
and make the API more complicated, I don't see any other usecase than
the IDE one for this and the theming API is due to significantly
change during 3.x, if people _really_ want themeable markers, we
should add enough on the public API for people to subclass and
implement their own marker support.

Feedback and reviewers are welcome :-)

2010/7/8 Alberto Ruiz <aruiz gnome org>:
> 2010/7/7 Thomas Wood <thos gnome org>:
>> On Wed, 2010-07-07 at 00:42 +0100, Alberto Ruiz wrote:
>>> Hi Gtk+ hackers,
>>
>>> The marker addition call would look something like this:
>>>
>>> gtk_scrollbar_add_mark (GtkScrollbar *scrollbar, gdouble mark, gchar*
>>> mark_class);
>>>
>>> There would also be some stock markers with default colours.
>>> mark_class can be null and the default highlight colour  will be used.
>>>
>>> Again, how and where to set and extend the colour mapping is sort of a
>>> blurry spot to me.
>>
>>
>> It's probably important to get the theme integration correct here, so
>> people can adjust the default highlight colours so that they don't clash
>> with any other custom colours. Also, a different theme may want to draw
>> markers in some new fancy way, so it might be important to make sure the
>> marker information is available when the theme draws the scrollbar
>> background. Alternatively, we could add a new "marker" drawing function
>> in GtkStyle, but ideally we want to move away from using abstract
>> drawing methods.
>>
>> Regards,
>>
>> Thomas
>>
>>
>
> Hi Thomas,
>
> I'm gonna try to find some time during next week to put together a
> patch and propose an initial API.
> Working from there would be a lot easier for me. If adding custom
> colours is gonna be a hassle theming wise I might consider dropping
> support for that and just offer generic search match support similar
> to what GtkScale does but without any string.
>
> --
> Un saludo,
> Alberto Ruiz
>



-- 
Un saludo,
Alberto Ruiz


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]