1 < ebassi> yes, it's time :-)
   2 < ebassi> as usual, the agenda is at: http://live.gnome.org/GTK+/Meetings
   3 < 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 ;)
   4 < ebassi> the points on the agenda are:
   5 < aruiz> xan: let's talk about that later :-)
   6 < ebassi> • GtkScrollable interface (bug #468689)
   7 < ebassi> • Removal of GtkAdjustments public fields
   8 < ebassi> since mclasen is not going to be here, this is going to be a slightly more informal meeting
   9 < ebassi> but, for item 1, I know that he left a comment
  10 < ebassi> on the bug
  11 < ebassi> and for item 2, I guess we need a recap
  12 < ebassi> if anyone has other items, now it would be the time to propose them :-)
  13 < aruiz> I do!
  14 < ebassi> I have an item, but I'll go after aruiz 
  15 < aruiz> I want to talk about how gtkscrollbar's expose
  16 < aruiz> I've been trying to implement a marker API for the scrollbar, to achieve the same behaviour than google chrome's search
  17 < aruiz> can go into more details after the already proposed items
  18 < aruiz> ebassi: that's it, you can go ahead
  19 < chpe> ebassi: I want to discuss G_DEFINE_BOXED_TYPE (bug 449565)
  20 < 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
  21 < tadeboro> For items 1 and 2, I prepared a wiki pages with some information in order to speed things up a bit.
  22 < tadeboro> They are linked from agenda, but here are direct links.
  23 < tadeboro> GtkScrollable interface: http://live.gnome.org/GTK%2B/GtkScrollable
  24 < tadeboro> GtkAdjustment: http://live.gnome.org/GTK%2B/GtkAdjustment
  25 < aruiz> I'll create a wikipage for GtkRange then (which is the actual source of my pain)
  26 < ebassi> tadeboro: so, starting with item 1: in short, the issue is?
  27 < ebassi> (just for the record)
  28 < tadeboro> Removing pre-GTK+-2 hack that enabled sharing of adjustments among parent and child widgets.
  29 < 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.
  30 < jjardon> related bug: https://bugzilla.gnome.org/show_bug.cgi?id=468689
  31 < 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
  32 < ebassi> having a scrollable, btw, would make my life easier in clutter-gtk :-)
  33 < 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.
  34 < tadeboro> I created a table of widgets that would need to be ported and half of them already have [hv]adjustment properties.
  35 < 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
  36 < 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
  37 < 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
  38 < tadeboro> Each widget will need to do it's own implementation of scrolling based on values and signals from shared adjustments.
  39 < ebassi> then it's all up to the adjustments to work their magic, and you can move the GdkWindow you want to scroll
  40 < tadeboro> Again, I chose this path because it's least likely to break existing widgets.
  41 < tadeboro> I also added some code on wiki that shows how scrollable widgets should generally be created.
  42 < ebassi> for other toolkits using the Scrollable approach: http://docs.clutter-project.org/docs/mx/stable/mx-mx-scrollable.html
  43 < 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.
  44 < 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?
  45 < aruiz> :-)
  46 < tadeboro> Sure. I'll also port some widgets to demonstrate how things will work.
  47 < tadeboro> I didn't want to start coding before getting at least initial approval.
  48 < jjardon> tadeboro, Did you talked with mathias about this?
  49 < pbor> would the new interface be just for 3.0 or also backportable?
  50 < tadeboro> jjardon: I haven't talked to him yet, will do that soonish.
  51 < jjardon> super
  52 < ebassi> at some point we'll have to decide to stop adding stuff back to 2.x
  53 < ebassi> I thought 2.22 was just for missing accessors, not for interfaces/functionality
  54 < jjardon> we already decided to not add new features to 2.x :P
  55 < tadeboro> pbor: This interface will be able to work side-by-side with old method, so in theory, it can be backported.
  56 < walters> jjardon: i wouldn't be so hasty with the "we" there...
  57 < ebassi> if people want to start maintaining 2.x
  58 < ebassi> walters: again, if you want to start maintaining gtk 2.x I think nobody will object to that
  59 < jjardon> walters, It was decided by the GTK+ maintainers some time ago in a meeting
  60 < ebassi> actually, it was decided years ago, and across several irc meetings, mailing lists and face to face discussions :-)
  61 < aruiz> anyway, are we done with the first point?
  62 < ebassi> aruiz: hey, that's *my* line :-p
  63 < aruiz> awwww :(
  64 < ebassi> so, ACTION: tadeboro to address mclasen comment
  65 < 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
  66 < ebassi> ACTION: tadeboro to port a couple of widgets to demonstrate functionality
  67 < ebassi> walters: that's how people gets saddled with maintainership, nowadays ;-)
  68 < ebassi> walters: I guess somebody can round up a pool of maintainers for 2.x
  69 < xan> *cricket sounds*
  70 < ebassi> personally, I'd rather have those people to do a fast development cycle for 3.x (2-3 years)
  71 < ebassi> but, again, we're digressing
  72 < walters> by 3.x do you mean API/ABI breaks?
  73 < ebassi> walters: I mean 3.x API expires in 2-3 years, then 4.x starts
  74 < 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
  75 < 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
  76 < 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
  77 < ebassi> because it will keep app developers happy
  78 < jjardon> also, 3.x will allow to do a lot of things without breaking ABI / API for some time
  79 < ebassi> and I personally don't like keeping app developers happy ;-)
  80 < ebassi> jjardon: where "some time", again, means 2-3 years
  81 < aruiz> plus, it's not like we would encourage people to move on to 3.x if we backport stuff
  82 < ebassi> aruiz: my point exactly
  83 < jjardon> I mean, we dont need all the features in 3.0, they can land later
  84 < 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
  85 < ebassi> well, actually the "oh my god, we have to keep up with a platform and do our job" approach
  86 < ebassi> *anyway*
  87 < ebassi> we digressed enough
  88 < ebassi> item 2: GtkAdjustment
  89 < ebassi> tadeboro: your turn again at the mike :-)
  90 < tadeboro> Removing public fields from GtkAdjustment right now makes it impossible to recode the delayed update functionality og GtkRange.
  91 < tadeboro> *of
  92 < tadeboro> GtkRange currently does this by directly modifying :value property and emitting ::value-changed signal at some later point.
  93 < tadeboro> gtk_adjustment_set_value(), which is replacement for direct ->value access, always emits ::value-changed signal at modification time.
  94 < tadeboro> I described this problem here: http://live.gnome.org/GTK%2B/GtkAdjustment
  95 < ebassi> tadeboro: can we have either an internal variant that does not emit ::value-changed or a public gtk_adjustment_set_value_no_emit()?
  96 < ebassi> (I'd rather go with the internal variant and expose it only if other widgets outside of gtk need it)
  97 < tadeboro> This would be possible.
  98 < tadeboro> Other solution would be to make value setter behave like all other setters.
  99 < tadeboro> This way, signal emission can be delayed by calling g_object_freeze_notify()/g_object_thaw_notify().
 100 < tadeboro> Another benefit of making all setters go through g_object_set() is enhanced validation.
 101 < ebassi> tadeboro: con: all setters now have to go through the GValue marshalling code, which is more expensive
 102 < ebassi> tadeboro: and we're already switching everything to use function calls + validation
 103 < tadeboro> True, but 5/6 setters do that already.
 104 < jjardon> tadeboro, you discussed this with owen, rigth? What was his opinnion?
 105 < tadeboro> owen's main objection was geared towerds my proposed strict(er) validation.
 106 < tadeboro> *towards
 107 < tadeboro> There was not much discussion about method of setting the value.
 108 < jjardon> tadeboro, so, your current proposal doesnt include strict(er) validation?
 109 < tadeboro> Stricter validation is an add-on that can be added if everything goes trough GValue + marshalling.
 110 < tadeboro> But it's not strictly required (it would make some code much cleaner, though).
 111 < tadeboro> Main reason for going through GValue, marshalling ... is dispatch_properties_changed() function.
 112 < jjardon> tadeboro, interesting. Do you have a bug for your GtkAdjustment proposal?
 113 < tadeboro> This is the place which makes delayed signal emission and validation possible.
 114 < tadeboro> Bug: https://bugzilla.gnome.org/show_bug.cgi?id=619768
 115 < tadeboro> I wrote a new implementation of GtkAdjustment some time ago (attached to that bug).
 116 < ebassi> so, I guess we'll need a review and a nod from mclasen
 117 < ebassi> tadeboro: other points?
 118 < tadeboro> That implementation has strict validation, delayed signal emission and protesction from signal emission of value hasn't changed.
 119 < tadeboro> *protection
 120 < tadeboro> Current implementation will trigger ::changed signal every time non-value property is changed through g_object_set().
 121 < tadeboro> For possible gains of validation, see my wiki page (http://live.gnome.org/GTK%2B/GtkAdjustment)
 122 < tadeboro> At the end, there is a sample function from GtkIconView that is also replicated in couple of other widgets.
 123 < ebassi> tadeboro: cool
 124 < tadeboro> After public fields are removed, this function will gain some additional overhead, since each accessor call will call GTK_IS_ADJUSTMENT() macro.
 125 < tadeboro> Validation removes the need for such wrapper, since gtk_adjustment_set_upper() will do this for you in a more efficient way.
 126 < tadeboro> What I would like to hear from people here is:
 127 < tadeboro>  - is internal gtk_adjustment_set_value_no_emit() + manual emission better than going through GValue ...
 128 < tadeboro>  - is validation worth adding to GtkAdjustment
 129 < tadeboro> Most applications that use accessors will not see any difference if validation is in place.
 130 < ebassi> tadeboro: I guess you probably want to engage the community at large - did you send an email to gtk-devel-list?
 131 < tadeboro> Yes. Got no response.
 132 < ebassi> then send another email saying GtkAdjustment is going to be deprecated in the subject; those usually attract a lot of replies ;-)
 133 < jjardon> make GtkAdjustment more "intelligent" makes sense for me. Instead each app devel use custom code to verify the values
 134 < jjardon> ebassi, haha
 135 < aruiz> heh
 136 < tadeboro> Will do that.
 137 < aruiz> we're going to kill someone with a heart attack following this approach to attention catching
 138 < jjardon> I see tearoff in your face
 139 < ebassi> tadeboro: the case for the changes seems pretty solid
 140 < ebassi> tadeboro: again, we'll need a review and a nod from mclasen
 141 < thos> tadeboro: validation might be tricky if, e.g. you want to temporarily go off the end of the range
 142 < ebassi> ah, here's an app developer :-)
 143 < thos> tadeboro: for a elastic effect, for example
 144 < tadeboro> thos, this is not allowed and even current code will clamp your value.
 145 < tadeboro> thos: Docs explicitly state that value must be in range [lower, upper - page_size].
 146 < ebassi> thos: I guess MxAdjustments are smarter; they also have more API to deal with those cases
 147 < thos> ebassi: yes, that's true
 148 < thos> it's probably not a very common case
 149 < thos> MxAdjustment has interpolation and "elastic" functions
 150 < ebassi> thos: it could be, once we start implementing more animations in the toolkit
 151 < thos> ebassi: oh yeah, I mean it's probably the only case for non-validation
 152 < thos> i.e. a situation you might not want the value kept "valid"
 153 < ebassi> if (gtk_adjustment_is_interpolating (adj)) { allow overshooting } else { clamp harder }
 154 < tadeboro> That kind of stuff will probably be needed for kinetic scrolling that poped-up latelly on IRC.
 155 < thos> tadeboro: exactly
 156 < jjardon> indeed
 157 < jjardon> https://bugzilla.gnome.org/show_bug.cgi?id=462208
 158 < tadeboro> But adding more "relaxed" rules for "kinetic mode" can always be done, even if strict validation is added now.
 159 < nud> isn't adding stricter validation likely to break stuff?
 160 < nud> no matter what the doc says, I think this was the argument owen opposed for a recent gtkrange rework
 161 < nud> like if you change the range from [a, b] to [c, d] where c > b
 162 < tadeboro> nud: This can be cleanly handled by validation, thanks to dispatch_properties_changed() function.
 163 < tadeboro> nud: Validation is only done once all of the values are set.
 164 < 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().
 165 < tadeboro> nud: And one probably already does that or ::changed signal will get emitted twice, once in inconsistent state.
 166 < tadeboro> To state things a bit differently: if application uses accessors when dealing with GtkAdjustment, validation most probably will not cause any troubles.
 167 < tadeboro> If application accesses fields directly, it needs to be rewriten anyhow.
 168 < jjardon> well, this work is for GTK+3, so not a problem
 169 < ebassi> tadeboro: nud: can you write down this discussion on bugzilla/wiki page/mailing list? others might want to chime in
 170 < ebassi> (though, obviously, if direct access is disabled then there are fewer chances for code to break :-))
 171 < nud> tadeboro, the point is that it requires changes in the code, so it can introduce bugs that are hard to find
 172 < 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.
 173 < jjardon> indeed, Maybe some modules can be fixed with this change
 174 < 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
 175 smaller than previous upper value and no ::changed signal emission is used.
 176 < 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
 177 < tadeboro> I'll send a mail.
 178 < ebassi> tadeboro: thanks a lot
 179 < aruiz> :-)
 180 < ebassi> aruiz: your turn
 181 < aruiz> ooookay
 182 < aruiz> So, if you have a look here: http://live.gnome.org/GTK%2B/GtkRange
 183 < aruiz> basically, I've been trying to implement markers for the scrollbar
 184 < aruiz> while trying to write my patch
 185 < aruiz> I stumbled upon two facts
 186 < aruiz> 1) The logic to paint the scrollbar widget is in GtkRange
 187 < ebassi> ugh
 188 < aruiz> 2) There is a marker API for GtkScale, which is sort of specific to it's case (uses labels)
 189 < aruiz> so I figured I have two options
 190 < aruiz> one, implement a generic marker api in GtkRange, and have GtkScale's custom API rely on that
 191 < aruiz> and extend it for labels
 192 < aruiz> or
 193 < aruiz> implement a specific marker API for GtkSCrollbar
 194 < aruiz> now, the second option would force me to duplicate or move the expose code from GtkRange to GtkScrollbar
 195 < aruiz> and I don't know what the implications of that are
 196 < aruiz> which is why I'm here
 197 < ebassi> GtkScale::expose chains up, so the code is partially shared already
 198 < ebassi> I guess you want GtkScrollbar to override ::expose and do what GtkScale does
 199 < aruiz> well
 200 < ebassi> and add marker API to GtkScrollbar
 201 < aruiz> that'd pretty much mean that I have to copypaste the expose code from GtkRange right?
 202 < ebassi> no, just chain up from GtkScrollbar::expose
 203 < tadeboro> aruiz: You can chain up and do custom drawing on topof it.
 204 < aruiz> heh
 205 < ebassi> then draw on top
 206 < ebassi> like GtkScale does
 207 < aruiz> to draw on top
 208 < aruiz> I need to know where the trough is placed
 209 < aruiz> to know where the trough is placed, I pretty much need to replicate what GtkRange:expose does
 210 < ebassi> aruiz: no, you can get that geometry
 211 < aruiz> huh, may I ask how?
 212 < ebassi> aruiz: actually, once the GtkRange::expose has run, you know that the trough has been already placed
 213 < ebassi> aruiz: style properties
 214 < ebassi> aruiz: :focus-padding and :slider-width, to be precise
 215 < ebassi> aruiz: again, GtkScale does that to draw the markers
 216 < aruiz> gimme a sec
 217 < ebassi> aruiz: also, GtkRange has some geometry data inside its own structure
 218 < aruiz> yeah
 219 < ebassi> (which, I guess, will require internal accessors for)
 220 < aruiz> but that's private isn't it?
 221 < ebassi> aruiz: well, it's private from without gtk+; within gtk+ you can use it
 222 < aruiz> if an internal accessor to that struct is a plausible solution
 223 < aruiz> I'd rather go for that
 224 < ebassi> okay, so we'll need a bug for that :-)
 225 < aruiz> yeah
 226 < aruiz> I will file a bug for that one
 227 < aruiz> and for the rest of the stuff as I make progress
 228 < ebassi> aruiz: yup
 229 < aruiz> thanks a lot ebassi!
 230 < ebassi> aruiz: cool; and the marker API for scrollbar would be cool as well
 231 < aruiz> yeah
 232 < ebassi> a lot of apps would benefit from that
 233 < aruiz> once I have that structure
 234 < aruiz> in scrollbar itself
 235 < aruiz> it'll be piece of cake really
 236 < aruiz> oh
 237 < aruiz> another question is
 238 < aruiz> what would be the right color for the marker
 239 < aruiz> from the style palette
 240 < pbor> yup, I wanted that for a a long time, can you ping me when you open the bug so I subscribe to it?
 241 < aruiz> pbor: you bet
 242 < aruiz> :-)
 243 < pbor> aruiz: the color should be settable in the api imho
 244 < ebassi> aruiz: probably a styled color
 245 < ebassi> the same color used by the app to do the highlight
 246 < ebassi> of the search
 247 < aruiz> ebassi: makes sense
 248 < pbor> aruiz: I want different colors to mark errors, warnings and search
 249 < aruiz> a color per marker?
 250 < aruiz> that kind of makes sense
 251 < ebassi> so yeah, aruiz: look at GtkInfoBar :-)
 252 < pbor> a color per marker category
 253 < aruiz> ebassi: will do
 254 < aruiz> pbor: would the marker categories be dynamic?
 255 < tadeboro> aruiz: I would take them from GtkMessageType enum.
 256 < ebassi> aruiz: if you can attach an arbitrary identifier to a marker, then it's probably just as good
 257 < ebassi> a string, probably
 258 < ebassi> or a GtkMessageType value, like tadeboro said
 259 < aruiz> GtkMessageType seems sensible
 260 < pbor> no, please a string
 261 < ebassi> though strings would make it easier to style
 262 < aruiz> string?
 263 < pbor> so that they can be extended
 264 < ebassi> gtk_scrollbar_add_marker (bar, "error", position);
 265 < aruiz> yeah, I would reckon, you want it to be extensible by nature
 266 < aruiz> it'll be nice to have some "preset" categories though
 267 < aruiz> as #defs strings
 268 < ebassi> aruiz: stock marker identifiers, like stock icons
 269 < aruiz> or strings even, we don't want people to build their own string->colour map for every app
 270 < aruiz> yup
 271 < aruiz> okay
 272 < aruiz> I'm taking notes of all this feedback
 273 < ebassi> so
 274 < ebassi> ACTION: aruiz to open a bug for GtkRange accessors
 275 < pbor> aruiz: and ideally also a way to set a tooltip on a marker would be nice
 276 < aruiz> but, I won't be able to spend a huge amouont of time on this until september
 277 < aruiz> can fix the GtkRange issue relatively soon though
 278 < ebassi> ACTION: aruiz to open a bug/send an email for API discussion
 279 < aruiz> ebassi: got it
 280 < ebassi> aruiz: thanks
 281 < aruiz> np
 282 < aruiz> thanks everyone for the help and the feedback
 283 < aruiz> :-)
 284 < ebassi> aruiz: thanks :-)
 285 < ebassi> chpe: next item, G_DEFINE_BOXED_TYPE
 286 < pbor> aruiz: (last comment) an alternative to an extensible api is make easy to override the drawing of marks
 287 < chpe> ebassi: (bug 449565)
 288 < aruiz> pbor: I'll open a bug for the marker API as well, we can discuss there further :-)
 289 < pbor> sure
 290 < 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
 291 < ebassi> chpe: I'll do a review
 292 < chpe> thanks
 293  * ebassi adds it to the top of his needs-review pile
 294 < ebassi> will probably do it tomorrow
 295 < ebassi> okay, final item
 296 < ebassi> who's coming to guadec, this year? and should I contact the organization to get a room for a meeting?
 297 < aruiz> me
 298 < aruiz> :-)
 299 < ebassi> or do we just meet up informally at some point after I round up the usual suspects?
 300 < aruiz> ebassi: I'll be there and contribute with my humble presence if there is a meeting in place
 301 < aruiz> ebassi: having a spot to meet in place would make things better IMHO
 302 < ebassi> thos will be there as well; I also guess people from lanedo will be there
 303 < aruiz> last year wast kind of shit
 304 < aruiz> we met on that table at the terrace
 305 < ebassi> and I found out at the end :-)
 306 < aruiz> I'm sure garnacho is going
 307 < ebassi> luckily kris sent a report
 308 < aruiz> jjardon: you're going right?
 309 < ebassi> okay, so we can at least discuss themeing
 310 < aruiz> yup
 311 < jjardon> aruiz, yes
 312 < aruiz> ebassi: garnacho has also animation support on the radar
 313 < ebassi> aruiz: animation support might really require a complete re-engineering of the relayout/redraw cycle, just like we did in clutter
 314 < ebassi> anyway, we have *loads* of stuff to discuss
 315 < aruiz> yup
 316 < ebassi> it's just that not a lot of people will be there to discuss it, or so it seems
 317 < aruiz> that's not necessarily a bad thing
 318 < ebassi> I'll send an email to the list and gather some more attendance information
 319 < aruiz> :P
 320 < aruiz> but I know what you mean
 321 < jjardon> ebassi, Maybe setup a wiki page would help?
 322 < ebassi> jjardon: yes
 323 < aruiz> in any case, reserving a room won't hurt
 324 < aruiz> please, not during the FreeFA! X-)
 325 < ebassi> aruiz: it might, given that it's kind of late and I don't know how many rooms are actually available
 326 < ebassi> at the venue
 327 < ebassi> hence my request for attendance
 328 < ebassi> anyway, that was the last point
 329 < aruiz> :-)
 330 < ebassi> just 6 minutes over the 2hrs mark :-)
 331 < aruiz> thanks ebassi!
 332 < tadeboro> Finally! ;)
 333 < jjardon> http://live.gnome.org/GUADEC/2010/BOFs
 334 < aruiz> we can blame the FSF and it's bloody GLPv3 for that overtime
 335 < tadeboro> Thanks for great meeting everybody.
 336 < aruiz> :-)
 337 < tadeboro> And good night.
 338 < ebassi> thanks everyone
 339 < aruiz> night!
 340 < ebassi> will send the minutes to the list
 341 < ebassi> and see you at guadec :-)