< ebassi> yes, it's time :-) < ebassi> as usual, the agenda is at: http://live.gnome.org/GTK+/Meetings < xan> aruiz: they cannot do "whatever they want", just a subset of the things they could do if they were the copyright owners for the whole library ;) < ebassi> the points on the agenda are: < aruiz> xan: let's talk about that later :-) < ebassi> • GtkScrollable interface (bug #468689) < ebassi> • Removal of GtkAdjustments public fields < ebassi> since mclasen is not going to be here, this is going to be a slightly more informal meeting < ebassi> but, for item 1, I know that he left a comment < ebassi> on the bug < ebassi> and for item 2, I guess we need a recap < ebassi> if anyone has other items, now it would be the time to propose them :-) < aruiz> I do! < ebassi> I have an item, but I'll go after aruiz < aruiz> I want to talk about how gtkscrollbar's expose < aruiz> I've been trying to implement a marker API for the scrollbar, to achieve the same behaviour than google chrome's search < aruiz> can go into more details after the already proposed items < aruiz> ebassi: that's it, you can go ahead < chpe> ebassi: I want to discuss G_DEFINE_BOXED_TYPE (bug 449565) < ebassi> I wanted to discuss a meeting a guadec, and whether I should ask the guadec organizer to reserve a room - but it depends on attendance < tadeboro> For items 1 and 2, I prepared a wiki pages with some information in order to speed things up a bit. < tadeboro> They are linked from agenda, but here are direct links. < tadeboro> GtkScrollable interface: http://live.gnome.org/GTK%2B/GtkScrollable < tadeboro> GtkAdjustment: http://live.gnome.org/GTK%2B/GtkAdjustment < aruiz> I'll create a wikipage for GtkRange then (which is the actual source of my pain) < ebassi> tadeboro: so, starting with item 1: in short, the issue is? < ebassi> (just for the record) < tadeboro> Removing pre-GTK+-2 hack that enabled sharing of adjustments among parent and child widgets. < tadeboro> As described, I created a sample implementation of GtkScrollable interface that would be as similar as possible to current way of doing things, but without being a hack. < jjardon> related bug: https://bugzilla.gnome.org/show_bug.cgi?id=468689 < ebassi> interface properties are always annoying, but having implemented at least two similar interfaces (in nbtk and clutter-gtk) I see the design as inevitable < ebassi> having a scrollable, btw, would make my life easier in clutter-gtk :-) < tadeboro> I choose this because most of the scrolable widgets already have those properties and porting them would simply mean overrriding properties instead of installing them. < tadeboro> I created a table of widgets that would need to be ported and half of them already have [hv]adjustment properties. < ebassi> tadeboro: I guess the biggest issue blocking the patch is porting all scrollable widgets in gtk+ to the new API; if no regressions are encountered, then we just need to deprecate the old hack and commit the changes to master < aruiz> tadeboro: is the implementation of the interface totally up to each widget or there will be helpers? I tried to implement my own scrollable window once and it was actually not that obvious how to do it < ebassi> aruiz: the way I see it, is that currently it's not at all obvious how to create a scrollable widget because of the hoops you have to jump through; just having a Scrollable interface that allows you to set up adjustments would already be a winner < tadeboro> Each widget will need to do it's own implementation of scrolling based on values and signals from shared adjustments. < ebassi> then it's all up to the adjustments to work their magic, and you can move the GdkWindow you want to scroll < tadeboro> Again, I chose this path because it's least likely to break existing widgets. < tadeboro> I also added some code on wiki that shows how scrollable widgets should generally be created. < ebassi> for other toolkits using the Scrollable approach: http://docs.clutter-project.org/docs/mx/stable/mx-mx-scrollable.html < tadeboro> Generally speaking, one needs to populate upper, lower, page-size, page-increment and step-increment values of adjustment when size gets allocated to widget and respond to ::value-changed signal with scrolling the contents. < jjardon> Seems that there is not opossition to this new interface, tadeboro could you rework the patch to fix the bug commented by mathias for a second review? < aruiz> :-) < tadeboro> Sure. I'll also port some widgets to demonstrate how things will work. < tadeboro> I didn't want to start coding before getting at least initial approval. < jjardon> tadeboro, Did you talked with mathias about this? < pbor> would the new interface be just for 3.0 or also backportable? < tadeboro> jjardon: I haven't talked to him yet, will do that soonish. < jjardon> super < ebassi> at some point we'll have to decide to stop adding stuff back to 2.x < ebassi> I thought 2.22 was just for missing accessors, not for interfaces/functionality < jjardon> we already decided to not add new features to 2.x :P < tadeboro> pbor: This interface will be able to work side-by-side with old method, so in theory, it can be backported. < walters> jjardon: i wouldn't be so hasty with the "we" there... < ebassi> if people want to start maintaining 2.x < ebassi> walters: again, if you want to start maintaining gtk 2.x I think nobody will object to that < jjardon> walters, It was decided by the GTK+ maintainers some time ago in a meeting < ebassi> actually, it was decided years ago, and across several irc meetings, mailing lists and face to face discussions :-) < aruiz> anyway, are we done with the first point? < ebassi> aruiz: hey, that's *my* line :-p < aruiz> awwww :( < ebassi> so, ACTION: tadeboro to address mclasen comment < walters> ebassi: it doesn't make any sense to me that adding a new feature implies that whoever adds a new feature is responsible for all of gtk2 < ebassi> ACTION: tadeboro to port a couple of widgets to demonstrate functionality < ebassi> walters: that's how people gets saddled with maintainership, nowadays ;-) < ebassi> walters: I guess somebody can round up a pool of maintainers for 2.x < xan> *cricket sounds* < ebassi> personally, I'd rather have those people to do a fast development cycle for 3.x (2-3 years) < ebassi> but, again, we're digressing < walters> by 3.x do you mean API/ABI breaks? < ebassi> walters: I mean 3.x API expires in 2-3 years, then 4.x starts < ebassi> we can even add experimental API that is guaranteed to be stable only for a minor cycle, like we've been doing in clutter < ebassi> anyhow, this was all in the 3.0 effort; it took ages to be put into place because people wanted 2.x to continue < ebassi> I don't think keeping 2.x on life support by backporting the odd feature (and hoping it won't break anything) is going to make us any favour < ebassi> because it will keep app developers happy < jjardon> also, 3.x will allow to do a lot of things without breaking ABI / API for some time < ebassi> and I personally don't like keeping app developers happy ;-) < ebassi> jjardon: where "some time", again, means 2-3 years < aruiz> plus, it's not like we would encourage people to move on to 3.x if we backport stuff < ebassi> aruiz: my point exactly < jjardon> I mean, we dont need all the features in 3.0, they can land later < ebassi> all this soft-launch for 3.x was born out of the meeting in istanbul, where app developers threw a fit over the "oh my god we'll have to port our apps" approach < ebassi> well, actually the "oh my god, we have to keep up with a platform and do our job" approach < ebassi> *anyway* < ebassi> we digressed enough < ebassi> item 2: GtkAdjustment < ebassi> tadeboro: your turn again at the mike :-) < tadeboro> Removing public fields from GtkAdjustment right now makes it impossible to recode the delayed update functionality og GtkRange. < tadeboro> *of < tadeboro> GtkRange currently does this by directly modifying :value property and emitting ::value-changed signal at some later point. < tadeboro> gtk_adjustment_set_value(), which is replacement for direct ->value access, always emits ::value-changed signal at modification time. < tadeboro> I described this problem here: http://live.gnome.org/GTK%2B/GtkAdjustment < ebassi> tadeboro: can we have either an internal variant that does not emit ::value-changed or a public gtk_adjustment_set_value_no_emit()? < ebassi> (I'd rather go with the internal variant and expose it only if other widgets outside of gtk need it) < tadeboro> This would be possible. < tadeboro> Other solution would be to make value setter behave like all other setters. < tadeboro> This way, signal emission can be delayed by calling g_object_freeze_notify()/g_object_thaw_notify(). < tadeboro> Another benefit of making all setters go through g_object_set() is enhanced validation. < ebassi> tadeboro: con: all setters now have to go through the GValue marshalling code, which is more expensive < ebassi> tadeboro: and we're already switching everything to use function calls + validation < tadeboro> True, but 5/6 setters do that already. < jjardon> tadeboro, you discussed this with owen, rigth? What was his opinnion? < tadeboro> owen's main objection was geared towerds my proposed strict(er) validation. < tadeboro> *towards < tadeboro> There was not much discussion about method of setting the value. < jjardon> tadeboro, so, your current proposal doesnt include strict(er) validation? < tadeboro> Stricter validation is an add-on that can be added if everything goes trough GValue + marshalling. < tadeboro> But it's not strictly required (it would make some code much cleaner, though). < tadeboro> Main reason for going through GValue, marshalling ... is dispatch_properties_changed() function. < jjardon> tadeboro, interesting. Do you have a bug for your GtkAdjustment proposal? < tadeboro> This is the place which makes delayed signal emission and validation possible. < tadeboro> Bug: https://bugzilla.gnome.org/show_bug.cgi?id=619768 < tadeboro> I wrote a new implementation of GtkAdjustment some time ago (attached to that bug). < ebassi> so, I guess we'll need a review and a nod from mclasen < ebassi> tadeboro: other points? < tadeboro> That implementation has strict validation, delayed signal emission and protesction from signal emission of value hasn't changed. < tadeboro> *protection < tadeboro> Current implementation will trigger ::changed signal every time non-value property is changed through g_object_set(). < tadeboro> For possible gains of validation, see my wiki page (http://live.gnome.org/GTK%2B/GtkAdjustment) < tadeboro> At the end, there is a sample function from GtkIconView that is also replicated in couple of other widgets. < ebassi> tadeboro: cool < tadeboro> After public fields are removed, this function will gain some additional overhead, since each accessor call will call GTK_IS_ADJUSTMENT() macro. < tadeboro> Validation removes the need for such wrapper, since gtk_adjustment_set_upper() will do this for you in a more efficient way. < tadeboro> What I would like to hear from people here is: < tadeboro> - is internal gtk_adjustment_set_value_no_emit() + manual emission better than going through GValue ... < tadeboro> - is validation worth adding to GtkAdjustment < tadeboro> Most applications that use accessors will not see any difference if validation is in place. < ebassi> tadeboro: I guess you probably want to engage the community at large - did you send an email to gtk-devel-list? < tadeboro> Yes. Got no response. < ebassi> then send another email saying GtkAdjustment is going to be deprecated in the subject; those usually attract a lot of replies ;-) < jjardon> make GtkAdjustment more "intelligent" makes sense for me. Instead each app devel use custom code to verify the values < jjardon> ebassi, haha < aruiz> heh < tadeboro> Will do that. < aruiz> we're going to kill someone with a heart attack following this approach to attention catching < jjardon> I see tearoff in your face < ebassi> tadeboro: the case for the changes seems pretty solid < ebassi> tadeboro: again, we'll need a review and a nod from mclasen < thos> tadeboro: validation might be tricky if, e.g. you want to temporarily go off the end of the range < ebassi> ah, here's an app developer :-) < thos> tadeboro: for a elastic effect, for example < tadeboro> thos, this is not allowed and even current code will clamp your value. < tadeboro> thos: Docs explicitly state that value must be in range [lower, upper - page_size]. < ebassi> thos: I guess MxAdjustments are smarter; they also have more API to deal with those cases < thos> ebassi: yes, that's true < thos> it's probably not a very common case < thos> MxAdjustment has interpolation and "elastic" functions < ebassi> thos: it could be, once we start implementing more animations in the toolkit < thos> ebassi: oh yeah, I mean it's probably the only case for non-validation < thos> i.e. a situation you might not want the value kept "valid" < ebassi> if (gtk_adjustment_is_interpolating (adj)) { allow overshooting } else { clamp harder } < tadeboro> That kind of stuff will probably be needed for kinetic scrolling that poped-up latelly on IRC. < thos> tadeboro: exactly < jjardon> indeed < jjardon> https://bugzilla.gnome.org/show_bug.cgi?id=462208 < tadeboro> But adding more "relaxed" rules for "kinetic mode" can always be done, even if strict validation is added now. < nud> isn't adding stricter validation likely to break stuff? < nud> no matter what the doc says, I think this was the argument owen opposed for a recent gtkrange rework < nud> like if you change the range from [a, b] to [c, d] where c > b < tadeboro> nud: This can be cleanly handled by validation, thanks to dispatch_properties_changed() function. < tadeboro> nud: Validation is only done once all of the values are set. < tadeboro> nud: Only thing that would need to be done in this case is adding g_object_freeze|thaw_notify() calls around gtk_adjustment_set_upper|lower(). < tadeboro> nud: And one probably already does that or ::changed signal will get emitted twice, once in inconsistent state. < tadeboro> To state things a bit differently: if application uses accessors when dealing with GtkAdjustment, validation most probably will not cause any troubles. < tadeboro> If application accesses fields directly, it needs to be rewriten anyhow. < jjardon> well, this work is for GTK+3, so not a problem < ebassi> tadeboro: nud: can you write down this discussion on bugzilla/wiki page/mailing list? others might want to chime in < ebassi> (though, obviously, if direct access is disabled then there are fewer chances for code to break :-)) < nud> tadeboro, the point is that it requires changes in the code, so it can introduce bugs that are hard to find < tadeboro> nud: This is an argument owen used in discussion. But I fail to see the real problem here, since direct access will not be possible in 3.x and thus code needs to be updated anyhow. < jjardon> indeed, Maybe some modules can be fixed with this change < tadeboro> nud: As I said, problems will only pop-up if one calls gtk_adjustment_set_lower() && gtk_adjustment_set_upper(), where lower value is smaller than previous upper value and no ::changed signal emission is used. < ebassi> okay; I'd really like to avoid passing the 2 hrs mark this week as well, so if there are bigger comments I suggest to redirect them to the mailing list < tadeboro> I'll send a mail. < ebassi> tadeboro: thanks a lot < aruiz> :-) < ebassi> aruiz: your turn < aruiz> ooookay < aruiz> So, if you have a look here: http://live.gnome.org/GTK%2B/GtkRange < aruiz> basically, I've been trying to implement markers for the scrollbar < aruiz> while trying to write my patch < aruiz> I stumbled upon two facts < aruiz> 1) The logic to paint the scrollbar widget is in GtkRange < ebassi> ugh < aruiz> 2) There is a marker API for GtkScale, which is sort of specific to it's case (uses labels) < aruiz> so I figured I have two options < aruiz> one, implement a generic marker api in GtkRange, and have GtkScale's custom API rely on that < aruiz> and extend it for labels < aruiz> or < aruiz> implement a specific marker API for GtkSCrollbar < aruiz> now, the second option would force me to duplicate or move the expose code from GtkRange to GtkScrollbar < aruiz> and I don't know what the implications of that are < aruiz> which is why I'm here < ebassi> GtkScale::expose chains up, so the code is partially shared already < ebassi> I guess you want GtkScrollbar to override ::expose and do what GtkScale does < aruiz> well < ebassi> and add marker API to GtkScrollbar < aruiz> that'd pretty much mean that I have to copypaste the expose code from GtkRange right? < ebassi> no, just chain up from GtkScrollbar::expose < tadeboro> aruiz: You can chain up and do custom drawing on topof it. < aruiz> heh < ebassi> then draw on top < ebassi> like GtkScale does < aruiz> to draw on top < aruiz> I need to know where the trough is placed < aruiz> to know where the trough is placed, I pretty much need to replicate what GtkRange:expose does < ebassi> aruiz: no, you can get that geometry < aruiz> huh, may I ask how? < ebassi> aruiz: actually, once the GtkRange::expose has run, you know that the trough has been already placed < ebassi> aruiz: style properties < ebassi> aruiz: :focus-padding and :slider-width, to be precise < ebassi> aruiz: again, GtkScale does that to draw the markers < aruiz> gimme a sec < ebassi> aruiz: also, GtkRange has some geometry data inside its own structure < aruiz> yeah < ebassi> (which, I guess, will require internal accessors for) < aruiz> but that's private isn't it? < ebassi> aruiz: well, it's private from without gtk+; within gtk+ you can use it < aruiz> if an internal accessor to that struct is a plausible solution < aruiz> I'd rather go for that < ebassi> okay, so we'll need a bug for that :-) < aruiz> yeah < aruiz> I will file a bug for that one < aruiz> and for the rest of the stuff as I make progress < ebassi> aruiz: yup < aruiz> thanks a lot ebassi! < ebassi> aruiz: cool; and the marker API for scrollbar would be cool as well < aruiz> yeah < ebassi> a lot of apps would benefit from that < aruiz> once I have that structure < aruiz> in scrollbar itself < aruiz> it'll be piece of cake really < aruiz> oh < aruiz> another question is < aruiz> what would be the right color for the marker < aruiz> from the style palette < pbor> yup, I wanted that for a a long time, can you ping me when you open the bug so I subscribe to it? < aruiz> pbor: you bet < aruiz> :-) < pbor> aruiz: the color should be settable in the api imho < ebassi> aruiz: probably a styled color < ebassi> the same color used by the app to do the highlight < ebassi> of the search < aruiz> ebassi: makes sense < pbor> aruiz: I want different colors to mark errors, warnings and search < aruiz> a color per marker? < aruiz> that kind of makes sense < ebassi> so yeah, aruiz: look at GtkInfoBar :-) < pbor> a color per marker category < aruiz> ebassi: will do < aruiz> pbor: would the marker categories be dynamic? < tadeboro> aruiz: I would take them from GtkMessageType enum. < ebassi> aruiz: if you can attach an arbitrary identifier to a marker, then it's probably just as good < ebassi> a string, probably < ebassi> or a GtkMessageType value, like tadeboro said < aruiz> GtkMessageType seems sensible < pbor> no, please a string < ebassi> though strings would make it easier to style < aruiz> string? < pbor> so that they can be extended < ebassi> gtk_scrollbar_add_marker (bar, "error", position); < aruiz> yeah, I would reckon, you want it to be extensible by nature < aruiz> it'll be nice to have some "preset" categories though < aruiz> as #defs strings < ebassi> aruiz: stock marker identifiers, like stock icons < aruiz> or strings even, we don't want people to build their own string->colour map for every app < aruiz> yup < aruiz> okay < aruiz> I'm taking notes of all this feedback < ebassi> so < ebassi> ACTION: aruiz to open a bug for GtkRange accessors < pbor> aruiz: and ideally also a way to set a tooltip on a marker would be nice < aruiz> but, I won't be able to spend a huge amouont of time on this until september < aruiz> can fix the GtkRange issue relatively soon though < ebassi> ACTION: aruiz to open a bug/send an email for API discussion < aruiz> ebassi: got it < ebassi> aruiz: thanks < aruiz> np < aruiz> thanks everyone for the help and the feedback < aruiz> :-) < ebassi> aruiz: thanks :-) < ebassi> chpe: next item, G_DEFINE_BOXED_TYPE < pbor> aruiz: (last comment) an alternative to an extensible api is make easy to override the drawing of marks < chpe> ebassi: (bug 449565) < aruiz> pbor: I'll open a bug for the marker API as well, we can discuss there further :-) < pbor> sure < chpe> ebassi: so I just wanted to nag :) the patch has been changed to incorporate all changes requested, and now it's waiting for approval < ebassi> chpe: I'll do a review < chpe> thanks * ebassi adds it to the top of his needs-review pile < ebassi> will probably do it tomorrow < ebassi> okay, final item < ebassi> who's coming to guadec, this year? and should I contact the organization to get a room for a meeting? < aruiz> me < aruiz> :-) < ebassi> or do we just meet up informally at some point after I round up the usual suspects? < aruiz> ebassi: I'll be there and contribute with my humble presence if there is a meeting in place < aruiz> ebassi: having a spot to meet in place would make things better IMHO < ebassi> thos will be there as well; I also guess people from lanedo will be there < aruiz> last year wast kind of shit < aruiz> we met on that table at the terrace < ebassi> and I found out at the end :-) < aruiz> I'm sure garnacho is going < ebassi> luckily kris sent a report < aruiz> jjardon: you're going right? < ebassi> okay, so we can at least discuss themeing < aruiz> yup < jjardon> aruiz, yes < aruiz> ebassi: garnacho has also animation support on the radar < ebassi> aruiz: animation support might really require a complete re-engineering of the relayout/redraw cycle, just like we did in clutter < ebassi> anyway, we have *loads* of stuff to discuss < aruiz> yup < ebassi> it's just that not a lot of people will be there to discuss it, or so it seems < aruiz> that's not necessarily a bad thing < ebassi> I'll send an email to the list and gather some more attendance information < aruiz> :P < aruiz> but I know what you mean < jjardon> ebassi, Maybe setup a wiki page would help? < ebassi> jjardon: yes < aruiz> in any case, reserving a room won't hurt < aruiz> please, not during the FreeFA! X-) < ebassi> aruiz: it might, given that it's kind of late and I don't know how many rooms are actually available < ebassi> at the venue < ebassi> hence my request for attendance < ebassi> anyway, that was the last point < aruiz> :-) < ebassi> just 6 minutes over the 2hrs mark :-) < aruiz> thanks ebassi! < tadeboro> Finally! ;) < jjardon> http://live.gnome.org/GUADEC/2010/BOFs < aruiz> we can blame the FSF and it's bloody GLPv3 for that overtime < tadeboro> Thanks for great meeting everybody. < aruiz> :-) < tadeboro> And good night. < ebassi> thanks everyone < aruiz> night! < ebassi> will send the minutes to the list < ebassi> and see you at guadec :-)