GNOME Bugzilla – Bug 623711
Add internal accessors for GtkRange's geometry struct
Last modified: 2014-09-27 04:28:45 UTC
In order to add marker functionality to GtkScrollbar I need access to the trough geometry which is painted and placed in an internal struct in GtkRange.
Created attachment 165388 [details] [review] Add internal accessors for GtkRange's geometry struct
That was fast
I think that the steppers should be provided, the trough and the slider are enough for my usecase, but the point of this exposure is to provide as much info as possible. Plus, it should be possible to use NULL as an argument and get only the info you're interested in :-)
Created attachment 165391 [details] [review] Add internal accessors for GtkRange's geometry struct.v2 I've added the steppers and you can use NULL as a entry parameter now
I don't think this is right.
Matthias, would you elaborate a bit on why you think this is the case? If you have a look at the expose code at GtkRange, you'll notice that the expose code has quite a bit of logic to figure out the geometry of the slider, trough and steppers. I'm not too keen on duplicating all that code just to avoid an internal accessor. If you have an alternative in mind please let us know :-)
I guess I am just disagreeing with the idea of starting to let that 'quite a bit of logic' leak out, after we've contained it in GtkRange for so long.
See bug 97326 for a similar request to expose the guts
I'm assuming you understand I'm not considering exposing these elements in the public API. Do you suggest we should duplicate the code then? Another option would be to have a private function out of both widgets that would give you the geometry of all those elements from a given GtkRange. The problem I see with duplication is that if at some point the theming mechanism changes somehow, we would have to keep that in mind. In any case, I don't quite understand why the expose logic of what ultimately is a GtkScrollbar lives in GtkRange anyway as it's supposed to be a base class. If moving that expose code down to GtkScrollbar seems like an option to you, I'm all for that, but my gut feeling tells me I'm prolly missing something here. I lack any sort of background on the past of this widget and some of the consequences of the changes I'm proposing, so your advice is really appreciated.
Created attachment 165722 [details] [review] Exposes GtkRange elements' geometry internally Didn't notice the previous patch was exposing these guts publicly, adding a private header here :-)
Hi, Small typo: the last if checks stepper_c while it should check stepper_d