1 < mclasen> first topic ?
   2 < desrt_> i can go first...
   3  * desrt_ adds an agenda item first :)
   4 < mclasen> I think you are first anyway
   5 < desrt_> okay
   6 < desrt_> so some of you already know that i talked with the release team recently
   7 < desrt_> and we've been freed from our obligation to backport GtkApplication to 2.22.0
   8 < desrt_> that, mixed with the current mess i've stirred up with GApplication suggests that maybe we should take this chance to delay
   9 < desrt_> specifically, i'm proposing that we ship 2.26.0 glib without GApplication
  10 < desrt_> to mitigate some of the ill effects of this choice we would do the following:
  11 < desrt_>  - branch glib-2-26 soon
  12 < desrt_>  - release 2.27.0 off of master (including GApplication as it stands)
  13 < desrt_>  - strip GApplication off the 2-26 branch and release 2.26.0 from there
  14 < desrt_> my main reason for wanting the delay is because, although i feel that i could easily rush the new GApplication code into glib, there would likely be problems caused by the lack of proper review
  15 < ebassi> do we have feedback from the shell developers?
  16 < desrt_> walters, ?
  17 < desrt_> walters, on the list you seemed to be somewhat against this...
  18 < walters> well, what's the schedule for the next glib?
  19 < desrt_> december
  20 < mclasen> end of year
  21 < desrt_> it will fall with gtk 3.0
  22 < walters> no after this one
  23 < walters> 2.28 i guess
  24 < desrt_> yes.  that's the one in december.
  25 < walters> ah
  26 < mclasen> yes, 2.26 in a few weeks, 2.28 end of year
  27 < walters> okay
  28 < desrt_> the reason for the rush is because gnome 2.32.0 needs GSettings and GDBus
  29 < desrt_> so we must release glib 2.26.0 now
  30 < walters> well in general - i am unhappy with not shipping GApplication just because you can't implement $EDITOR with it yet
  31 < desrt_> walter; actually, the $EDITOR part is working fine already.  it's the actions part that needs a bit more work.
  32 < desrt_> and most importantly, non-rushed review
  33 < walters> well, i can't say i can totally context switch to GApplication right now myself, so if it has to wait for December, it'll have to wait i guess
  34 < desrt_> we will have some annoyed application developers from this choice
  35 < mclasen> I think we had them all speak up on ddl
  36 < desrt_> bastien, in particular, has made some mumbling on the list that although he understands the situation, he's not exactly happy about it
  37 < walters> well, we mgiht investigate how difficult it'd be to have app authors do copy&paste
  38 < walters> for at least uniqueness
  39 < desrt_> right -- so we have to decide what the "official party line" is in terms of what to do now
  40 < desrt_> i was thinking "go back to libunique"
  41 < desrt_> but some gdbus-based copy/paste stuff might be nice too
  42 < desrt_> in the end i guess each person will decide their own path
  43 < ebassi> libunique at least uses gdbus
  44 < desrt_> ah.  nice indeed.
  45 < ebassi> thanks to chpe 
  46 < desrt_> :)
  47 < desrt_> so are we more or less settled on this topic?
  48 < ebassi> need to do a proper release with gtk2 + gdbus
  49 < ebassi> desrt_: as I said to you the other day, I can reserve time to review/implement missing bits -- but I generally agree that more time would be nice
  50 < mclasen> I think we will have to release 2.26 with an apology for the sudden disappearance of promised new api
  51 < desrt_> ebassi, will you be around to talk after the meeting?
  52 < ebassi> desrt_: yes
  53 < desrt_> excellent
  54 < mclasen> but in the end, it is probably better to pull it now and bring it back properly in 3 months
  55 < desrt_> mclasen, i can manage the 2.26 release and take all the flak, since it's my fault...
  56 < mclasen> nah, that's not required
  57 < desrt_> okay.  next topic
  58 < mclasen> we should probably do at least one 2.25 release after the stripping
  59 < mclasen> so, aim for branching 2.26 off later this week ?
  60 < desrt_> mclasen, i think that doesn't work
  61 < mclasen> no ?
  62 < desrt_> unless we want to do 2.25.x releases off the 2.26 branch
  63 < mclasen> right, that was my thought
  64 < desrt_> eh.  i guess that's fine, actually
  65 < desrt_> okay
  66 < desrt_> before release we need some GDBus stuff done, though
  67 < desrt_> davidz has promised a GDBusMessage.lock() API and a final revisit of the filter stuff
  68 < mclasen> and just to finish that topic off, are there any remaining 2.26 api issues,apart from that ?
  69 < desrt_> i think chpe proposed an API that he liked
  70 < desrt_> and i was OK with, too
  71 < desrt_> he said he'd find time later this week
  72 < ebassi> g_object_class_install_properties() doesn't have an accepted-commit_now state but was reviewed
  73 < desrt_> oh.  i liked what i read there.
  74 < desrt_> i ran the tests.  they worked... *shrug*
  75 < desrt_> mclasen, ACK for push?
  76 < ebassi> with that in, I can finally finish my "modern gobject programming" document :-)
  77 < mclasen> fine with me
  78 < desrt_> ebassi, you will find that you have your status :p
  79 < mclasen> ebassi: volume zero of the gnome platform programming series ?
  80 < ebassi> mclasen: heh -- or, at least, a replacement for the gobject tutorial in the API reference
  81 < mclasen> maybe rename that to gobject obscurial
  82 < mclasen> anyway, next topic 
  83 < desrt_> https://bugzilla.gnome.org/show_bug.cgi?id=50076
  84 < desrt_> i think some changes will also be required here pre-2.26.0
  85 < ebassi> desrt_: I've read your comment -- need to finish off my reply
  86 < desrt_> okay.  we can also deal with that personally after the meeting, i think?
  87 < ebassi> sure
  88 < desrt_> okay.  that one was fast. :)
  89 < desrt_> Company, ping
  90 < desrt_> Company, update?
  91 < Company> 4-1 Germany
  92  * desrt_ watches the coin land
  93 < desrt_> how's gtk? :)
  94 < Company> ECONTEXT
  95 < desrt_> gtk3 cleanups status?
  96 < Company> rendering cleanup was blocking on cairo 1.10
  97 < Company> or better: review was
  98 < Company> and i've been silently chugging along replacing expose events with draw functions
  99 < desrt_> did you come to a decision about the signal prototype?
 100 < Company> i used (GtkWidget *, cairo_t *, int, int)
 101 < desrt_> cool
 102 < desrt_> have you broken into any container classes yet?
 103 < hp> what are the ints?
 104 < desrt_> or are you just letting the containers move around expose events still?
 105 < Company> not sure how useful the int, int really is, because there's borders etc
 106 < desrt_> hp; width and height of the widget
 107 < Company> hp: allcation width/height
 108 < mclasen> doesn't the widget know that itself ?
 109 < Company> mclasen: it would have to query and we assumed it'd want to know it anyway
 110 < desrt_> mclasen; yes.  it does, but there are two reasons to avoid using it out of the widget
 111 < desrt_> 1) it's in the allocation (which also contains the x/y that we want the user to completely ignore)
 112 < desrt_> 2) according to Company's experience so far, it tends to result in much more compact code
 113 < hp> it just saves typing, width vs. widget->allocation.width ? 
 114 < desrt_> more or less
 115 < desrt_> but it also makes the idea of accessing 'allocation' as something that you should not do
 116 < Company> hp: that and it avoids having to think about allocations
 117 < hp> but you could assert (width == widget->allocation.width) or no?
 118 < desrt_> it's dirty.  don't touch it.  (no.  really.)
 119 < Company> hp: yes
 120 < mclasen> Company: but wasn't there some idea to normalize to a unit square, or something ?
 121 < Company> mclasen: the context is positioned at the widget's top left corner
 122 < hp> you still kinda have to think about allocation, for example if you have a PangoLayout youd' probably set its width in size_allocate and then in draw you'd have to assume it was still set up properly
 123 < hp> i.e. you don't want people thinking their size_allocate should be replicated inside draw()
 124 < desrt_> hp; dealing with changes in respect to size allocate is a bit different...
 125 < desrt_> since you're being handed an allocation directly in that case
 126 < desrt_> but even then, probably you should just chain up to let the widget worry about setting that allocation onto itself
 127 < hp> what I'm saying is, draw() only works if width == allocation.width. draw() having a width arg seems to imply there's some kind of new information there, but there can't be.
 128 < Company> hp: the vfunc has a width
 129 < Company> hp: the gtk_widget_draw() API does't
 130 < hp> company, sure
 131 < desrt_> Company, actually that's a bit of a good point.  it's odd to see virtual function wrappers that have different arguments than the virtual functions themselves
 132 < desrt_> it's difficult to describe this idea to language bindings, for example
 133 < hp> well, fwiw, I think it's weird. for me it'd raise all kinds of questions about "is this new information I need to handle? what if the width is not allocation.width?" and then I go round with the docs and it's "these are just here to save typing 'int width = widget->allocation.width' 
 134 < hp> which is surprising, to me
 135 < hp> .02
 136 < Company> yeah
 137 < Company> it'd be more useful if it was interesting values
 138 < Company> like after subtracting padding etc
 139 < Company> i thought it'd be useful, but it turned out it wasn't as much while porting code
 140 < desrt_> hp, thanks for the concerns
 141 < Company> but then, the worst part of the porting is the mess that is border_width etc
 142 < desrt_> Company, any more totally crazy ideas pending?
 143 < hp> Company oh I fixed that one
 144  * Company asked on bug 628828 now
 145 < hp> I'll async'ly answer on there
 146 < Company> i think that's about rendering cleanup - i suppose we'll have some discussions on the lists and then more exciting stuff in the next meeting
 147 < mclasen> Company: so, the rendering-cleanup branch is ready for reviewing the pixmap removal, yeah ?
 148 < Company> mclasen: yeah
 149 < mclasen> ok, I'll try to get to it this week
 150 < mclasen> of course, everybody else should chime in as well
 151 < kris> i should try to build and run it on mac
 152 < Company> people know that everything i do is correct anyway, so they don't review my stuff as much as i'd like...
 153 < kris> and hope it won't need a few day-long debugging sessions this time :)
 154 < Company> kris: os x is probably non-compiling again
 155 < Company> as is win32
 156 < mclasen> should we move into the next topic, then ? or are there more things to discuss about rendering-cleanup ?
 157 < Company> none from me
 158 < desrt_> re: the wiki page: is there anything on the cleanup list we should still discuss or should it be cleared out?
 159 < mclasen> where does your draw-function-introduction work live ? the same branch ?
 160 < ebassi> right, then: Padding cleanup
 161 < desrt_> we have a lot of items there for some time now
 162 < mclasen> desrt_: which cleanup list are you referring to ?
 163 < Company> mclasen: haven't pushed it yet
 164 < Company> mclasen: shoould i?
 165 < mclasen> might be more convenient to keep the branch at the pixmap removal level for the review ?
 166 < Company> mclasen: yeah, that was my idea
 167 < desrt_> mclasen, we have the bullet points on the meeting agenda page
 168 < mclasen> oh, that list
 169 < desrt_> the subitems under "possible GTK3 cleanup tasks"
 170 < mclasen> I've just thrown that in there as a source of inspiration
 171 < mclasen> we can remove it, I don' think discussing it now does much good
 172 < desrt_> k
 173 < Company> mclasen: reminds me: i had expected a reply from you about http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00069.html
 174 < mclasen> we should rather discuss the cleanups that are actually happening, like havocs padding work
 175 < mclasen> Company: I must have overlooked that
 176 < walters> Company: i'd suggest the rule is simply: if it's not something we want to maintain for another 10 years, remove it now
 177 < mclasen> lets reduce that to 4 years, I think
 178 < hp> well, also, "replace it so there's something to port to, then remove it" :-P
 179 < hp> except GtkRuler, screw that thing ... 
 180 < ebassi> hehe
 181 < Company> ensonic's gonna fix that!
 182 < Company> next topic?
 183 < mclasen> padding cleanup ?
 184 < ebassi> yep
 185 < mclasen> havoc has put forward 3 things: alignment/padding in gtkwidget, magic expand, legacy-free grid container
 186 < ebassi> 1) and 3) are +1 for me
 187 < ebassi> the magic expand is nice, but I'm wary of magic
 188 < mclasen> of course, 3) is vapourware atm
 189 < hp> yes, I don't know about 3), depends on the timeline for 3.0, not sure how it works yet, etc. it was just an idea. it can always be added later.
 190 < hp> ebassi it's not really magic (it's not heuristic guesses or anything). it's just saving typing.
 191 < hp> ebassi incidentally I'm likely to come after clutter with all the same changes sooner or later :-P
 192 < ebassi> hp: what happens to the bubbling up to the parent if there's a container that doesn't understand expan in the middle?
 193 < hp> ebassi what do you mean by doesn't understand expand?
 194 < ebassi> hp: I mean, what happens if a GtkContainer does not allow expanding its children?
 195 < ebassi> does the chain stop there?
 196 < ebassi> I guess
 197 < hp> then they won't expand, yep
 198 < hp> you can also manually stop the bubble by setting expand=FALSE manually
 199 < ebassi> right
 200 < mclasen> I wonder if we need a non-magic expand flag in addition ?
 201 < hp> what container doesn't expand children though?
 202 < hp> there is a manual flag and an automatic flag
 203 < mclasen> I man for making some children expand in the container without marking them as 'the content area'
 204 < hp> the manual flag always "wins"
 205 < hp> mclasen oh you mean be able to expand without affecting window resize?
 206 < Company> mclasen: if you want children to expand, you set their expand poperty
 207 < hp> if you want to have expansion in a sub-tree of a window, but don't want window itself to resize, then you just set expand=false on the tree node where you want expand to stop propagating up.
 208 < Company> hp: so expand=FALSE in a container basically overrides all expand=TRUE in children, right
 209 < Company> ?
 210 < hp> Company yeah every widget has a manual override, and if that is unset, it goes by children
 211 < Company> right
 212 < Company> i think it makes a lot of sense
 213 < Company> the only thing to get right is properly chaining this up
 214 < hp> it'd be sort of interesting maybe to see how often real apps have expand=TRUE that doesn't go all the way up to Window. I would bet in most such cases it's more or less a bug, but maybe not all.
 215 < Company> scrolled window
 216 < desrt_> are we basically talking about deprecating GtkMisc and GtkAlignment?
 217 < Company> though that one should expand by dfault
 218 < Company> desrt_: yes
 219 < desrt_> (and border_width on GtkContainer)
 220 < hp> desrt well that's the padding patch, separate from this expand stuff. but yes.
 221 < Company> GtkMisc has expand, too
 222 < desrt_> seems very webby :)
 223 < hp> Company, GtkAlignment has xscale/yscale
 224 < hp> yeah I guess expand replaces that
 225 < Company> desrt_: yeah, the only replacement for webby things that we don't have yet is a replacement for the "display" css property
 226 < desrt_> is that the inline vs. block one?
 227 < hp> so the backward incompatibility on the expand patch, I guess, is that if you had a GtkBox with an expandable item in it, and did not set expand all the way up the tree, now that would be automatically done for you. This could break a few apps, possibly.
 228 < Company> desrt_: yeah
 229 < desrt_> heh.  fun. :)
 230 < hp> you want inline vs. block or block vs. hidden ? 
 231 < desrt_> i have to say that the new way of looking at expand is probably closer to what user's expect
 232 < desrt_> *users
 233 < desrt_> we get really a lot of people coming into #gtk+ wondering why stuff isn't expanding
 234 < desrt_> and we have to explain to them that they have to set the expand property on the box
 235 < desrt_> not the child
 236 < hp> I don't know about you but I've spent plenty of time reading through a maze of box code going "which one of these TRUE/FALSE/0 things is f'd up"... 
 237 < hp> plus if you want to change whether a child expands you have to change more than one bool, which is lame.
 238 < desrt_> 'fill' is extremely dubious in terms of usefulness
 239 < Company> the only thing about expand is that it can have 3 values: true, false, inherit - hose are always hard to write api for
 240 < mclasen> we have a pretty setup with foo and foo-set
 241 < desrt_> inherit is that it expands only if it has a child that wants to expand?
 242 < Company> mclasen: i hate that, too - GtkCellRendererText is kinda sucky code
 243 < Company> desrt_: yeah
 244 < desrt_> so there is a bit of weirdness here
 245 < desrt_> consider this case (everything is same orientation here... let's say horizontal)
 246 < Company> could we replace the expand/no-expand with a dedicated widget?
 247 < desrt_> we have a toplevel box with 2 items inside a window
 248 < desrt_> the left item is a box with 2 items.. one expandable and one not
 249 < Company> or are properties more useful?
 250 < desrt_> the right item is a box with 2 items... both expandable
 251 < desrt_> we resize the window to make it bigger
 252 < desrt_> how is the space proportioned among the 3 expandable terminal widgets?
 253 < hp> depends on how the two widgets are packed, they are also in a box?
 254 < hp> is the box homogeneous?
 255 < desrt_> not homogeneous
 256 < Company> desrt_: according to their size request usually
 257 < desrt_> and yes.  a box.
 258 < hp> it just uses the algorithm of the box they're in
 259 < hp> iirc GtkBox just equally divides extra space among expand widgets?
 260 < Company> linearly i think
 261 < desrt_> what i'm getting at is this: it sort of seems like the expandable item on the left will get twice as much 'extra' space as the two on the right
 262 < Company> so a widget with twice the size request ets twice the extra space
 263 < mitch> as expected i'd say
 264 < hp> desrt right, so if you don't want that, don't use two layers of nested boxes ;-)
 265 < Company> desrt_: yes
 266 < Company> what hp says :)
 267 < desrt_> ya.  that's reasonable i guess.
 268 < desrt_> i half asked that question just to clarify my own understanding :)
 269 < desrt_> so what happens to the packing properties?
 270  * Company would be happy if gtk got rid of child properties completely
 271 < hp> packing properties still work but they are redundant basically. the API of box sort of ends up mostly vanishing.
 272 < hp> Company well child props are useful for things that are genuinely container-specific like, start or end of box, or table attach points. it's just that padding, expand, align are really applicable in any container. 
 273 < desrt_> hp; are you proposing breaking API of pack_start(), for example?
 274 < Company> hrm true
 275 < Company> we do have useful child properties
 276 < hp> desrt_, no, we'd just leave it there. that's why I suggested a GtkGrid because I think fixing Box is too incompatible.
 277 < hp> I mean, Box works fine still
 278 < desrt_> hmm
 279 < hp> but it just isn't logical anymore
 280 < hp> like you'd ask "why is there this expand here and that expand there that do the same thing?" and the answer would be "historical"
 281 < mclasen> I think we'd leave GtkBox untouched, similar to GtkH/VBox, and just put a legacy-free container in at some point
 282 < desrt_> out of all of the weird insane changes that we've done this cycle, this would far and away really be the biggest of all
 283 < mclasen> so we can kick the boxes out in gtk4
 284 < desrt_> it's really changing the flavour of gtk
 285 < desrt_> in an extremely user-visible way (where user = app developer)
 286 < desrt_> not saying that's bad, of course
 287 < mclasen> how do you mean ? all the old apis are still there...
 288 < desrt_> right.  but we will expect people not to use them
 289 < hp> it's true. it is a dramatically cleaner model, imo, easier for people to learn and more useful. but having the cleaner model AND the old model for a long time, will be gross.
 290 < desrt_> hp, i agree about easier to learn
 291 < desrt_> as i mentioned, our current expand/fill child-property thing is just damn confusing for most people
 292 < Company> GtkBox will be like GtkCTree - we just have it to scare people
 293 < desrt_> hp, will you make it to the hackfest?
 294 < hp> yes. expand,fill encodes what should be "expand=boolean, align=start/end/center/fill" (logically) into "expand=boolean; fill=boolean; add an Alignment to do start/end/center or do anything perpendicular to box axis"
 295 < hp> desrt_, is it the one in october?
 296 < desrt_> yes.  18-22.
 297 < desrt_> it seems like we could have a very useful discussion around this topic
 298 < hp> I can give it a shot. depends on what is happening then
 299 < desrt_> okay
 300 < hp> fwiw, my confidence levels are. I'm 99% sure that start/end/center/fill should be an enum and not a flag plus a float. this worked great in HippoCanvas and in the box widget litl shell (and I think for a while gnome-shell) were using with clutter.
 301 < hp> I think adjust_size_request adjust_size_allocation could break a few things subtly, basically widgets that were relying on having the border inside their allocation, or being allocated at 0,0.
 302 < desrt_> hp; i think i disagree with you
 303 < desrt_> hp; but i could probably be convinced that you're right
 304 < hp> I have never had real code using the automatic expand-propagation, but it seems logical.
 305 < desrt_> i have a hard time remembering using a x/yscale that wasn't 0.0 or 1.0
 306 < desrt_> or a x/yalign that wasn't 0.0 0.5 or 1.0
 307 < Company> y
 308 < hp> if you _really_ need the float x/y scale then a custom container like Alignment is still a good solution
 309 < Company> desrt_: you can still write a GtkAlignment
 310 < hp> but I don't think it's a reason to muck up GtkWidget and the primary API
 311  * Company agrees with hp
 312 < Company> someone could grep jhbuild for an alignment with odd scales
 313 < hp> the larger problem with flag+float isn't so much whether you need 0.67, but that you can set nonsensical combinations. "I set 0.0, it isn't working" type stuff
 314 < desrt_> i'd actually advocate leaving GtkAlignment
 315 < desrt_> for those 'weird cases'
 316 < hp> desrt_, removing GtkAlignment is presumably a 4.0 task, if ever
 317 < desrt_> cool.
 318 < desrt_> would be sad if we had to tell someone "the only way to do this is by writing your own container implementation" for something as mundane as off-centre alignment
 319 < hp> GtkAlignment is also useful for the odd case where you just need to stick in a widget that doesn't draw anything, as a spacer or placeholder or whatever
 320 < desrt_> hp, thanks for the intro.  i had no idea about this stuff before.
 321  * mclasen thinks that baseline alignment is probably more interesting that odd flloating point values for xalign
 322 < desrt_> mclasen, are we adding 'point size' as a GtkWidget property now?
 323 < mclasen> so, to finish up the padding cleanup, do we have agreement to land the padding / align part ?
 324 < desrt_> i think we can wrap up early?
 325 < desrt_> ah...
 326  * desrt_ didn't think it would be so soon :)
 327 < ebassi> padding/align sounds good to me
 328 < desrt_> i'd prefer to hold off a little bit
 329 < hp> oh and renaming padding to margin
 330 < desrt_> but i don't really have a stake here
 331 < mclasen> sure, we don't have to rush it
 332 < mclasen> and renaming to margin sounds good to me too
 333 < hp> desrt_, are you going to look at it more closely and send some thoughts?
 334 < desrt_> yes
 335 < mclasen> should we land this on a branch for now, for easier inspection ?
 336 < Company> branches are useful
 337 < Company> i prefer reviews in cgit to reviews anywhere else
 338 < desrt_> ya.  reading a git log is easier than flitting between a patch series
 339 < hp> I currently have padding and expanding on two separate branches, but if it's easier I could push just one
 340 < hp> depends on if people want to eval these together or separate
 341 < desrt_> i think we agree that padding would come first, right?
 342 < hp> they aren't really very interdependent
 343 < mclasen> yeah
 344 < desrt_> so push padding
 345 < desrt_> then rebase expanding onto the padding branch
 346 < desrt_> and push it
 347 < hp> desrt_, so one branch with both features 
 348 < desrt_> one branch with one feature
 349 < desrt_> other branch as a fast-forward of the first branch, but with expansion added as well
 350 < hp> oh I see, sure
 351 < desrt_> jjardon, hello :)
 352 < ebassi> I guess the next point, "Deprecate/remove GtkRequisition" also fits in with geometry/layout changes
 353 < hp> what are the random-feature-branch naming conventions?
 354 < ebassi> but tristan is not here :-/
 355 < desrt_> hp; i don't know that there is one
 356 < jjardon> desrt_: hi!, hello all
 357 < mclasen> hp: random names for random features
 358 < hp> ok, I can follow that guideline
 359 < desrt_> hp, but be aware of the other guideline: awesome names for awesome features
 360 < hp> oh, did you talk about breaking gdk-pixbuf to use cairo already in a prior meeting?
 361 < jjardon> ebassi: tristan made a patch in for the Deprecate/remove GtkRequisition bug: https://bugzilla.gnome.org/show_bug.cgi?id=626939#c3
 362 < desrt_> oh.  we have lockbutton up today too.  /me missed that.
 363 < mclasen> hp: no, we haven't talked about that yet
 364 < mclasen> yeah, lockbutton
 365 < Company> damn
 366 < Company> i wanted to write a mail about my ideas wrt breaking GdkPixbuf
 367 < mclasen> its just a very small widget that I've ported from polkit-gtk
 368 < mclasen> it just turns a GPermission into a button, basically
 369 < desrt_> mclasen, my biggest concern here is guidelines about how it is meant to be used?
 370 < mclasen> my main motivation for wanting it in gtk is that we can kill another microlib
 371 < mclasen> ie polkitgtk
 372 < ebassi> that would be a good reason already
 373 < desrt_> where does it go in a dialog?  above the action area?  in the left-side of the action area?  what if there is also a help button?
 374 < mclasen> and it is a step towards real simple preference dialogs
 375 < ebassi> for the guidelines, I guess it falls under the HIG
 376 < jjardon> That fix is needed to move the widget->requisition to a private structure
 377 < mclasen> desrt_: right, I'll have to flesh out the docs for that, I guess
 378 < ebassi> mclasen: feedback from the UX team would be good
 379 < mclasen> those are good points, could you perhaps comment in the bug ?
 380 < desrt_> mclasen, or maybe ask one of our design-minded people...
 381 < mclasen> ok, I'll do that
 382 < desrt_> i'll comment
 383 < mclasen> I'm fairly sure they will approve, though
 384 < mclasen> since they are all os x fanboys
 385 < mclasen> One thing I already did in preparation for the lockbutton
 386 < mclasen> is to make buttonboxes semi-homogeneous instead of strictly homogeneous
 387 < desrt_> did you land that?
 388 < mclasen> yes
 389 < desrt_> breaking at 1.5?
 390 < mclasen> pretty sure I did
 391 < mclasen> yeah
 392 < desrt_> with or without hinting API?
 393 < mclasen> think it needs to be tweakable ?
 394 < mclasen> no hinting for now
 395 < desrt_> not unless someone asks :)
 396 < desrt_> and again, not unless someone asks
 397 < desrt_> (imho)
 398 < desrt_> sounds quite right
 399 < mclasen> ok
 400 < mclasen> did we have more scheduled topics ?
 401 < ebassi> case sensitive search in TextBuffer
 402 < pbor> there was also case insensitive search on the agenda...
 403 < ebassi> http://bugzilla.gnome.org/show_bug.cgi?id=61852
 404 < ebassi> honestly, I see no blocking issue there
 405 < ebassi> if there's a patch
 406 < desrt_> ah hah!
 407 < pbor> yeah, nacho is not around, but basically his mail sums it up: http://mail.gnome.org/archives/gtk-devel-list/2010-July/msg00020.html
 408 < desrt_> i have a recommendation :)
 409 < mclasen> ugh, I had promised to review that
 410 < desrt_> you know there's this kind of searching that ancient grep used to support (-y option i think)
 411 < desrt_> lowercase letters were considered insensitive
 412 < desrt_> but uppercase had to exact-match
 413 < mitch> use case?
 414 < pbor> we are willing to do the cut&paste work if there is consensus
 415 < desrt_> so you could search for "foo" and find "foo" "Foo" or "FOO" but would only hit "FOO"
 416 < pbor> and by we, I mean nacho :)
 417 < Company> desrt_: to quote hp in that bug: "Implementing search yourself shouldn't be too difficult. There's nothing magic about how it's done in gtktextiter.c."
 418 < Company> desrt_: so go for it! :)
 419 < desrt_> Company, i have no interest
 420 < desrt_> Company, just sharing an idea i recently read about :)
 421 < Company> hehe
 422 < mclasen> pbor: I think I had a vague feeling that the implementation is not really ideal
 423 < mclasen> case-folding a line at a time
 424 < mclasen> but, since we have no streaming regex api, I guess it is maybe the best we can do for now
 425 < pbor> mclasen: yes, the implementation is not ideal, but as said in the mail, no one stepped up to do a better implementation in the last 10 years
 426 < pbor> and all projects that use textview cut and paste that code
 427 < mclasen> yeah, I guess that is the winning argument here
 428 < ebassi> I fully expect somebody complaining once it gets into TextBuffer
 429 < mclasen> so, lets tentatively accept it
 430 < mclasen> and wait for gmorten to show up and shred it....
 431 < ebassi> "I have this faster implementation written on a napkin"
 432 < pbor> ebassi: that's when the usual "patches welcome" comes up :)
 433 < ebassi> heh
 434 < Company> "napkins welcome"
 435 < mclasen> pbor: is there a bug somewhere where I need to say 'go ahead' ?
 436 < pbor> mclasen: either bug http://bugzilla.gnome.org/show_bug.cgi?id=61852 or reply to nacho's mail I linked
 437 < mclasen> ok, I'll reply
 438 < pbor> thanks
 439 < mclasen> time to wrap up ? or should we touch on gdk-pixbuf <> cairo before closing ?
 440 < hp> If people want to follow up later that's fine w/ me. the main issues in my mind are 1) is a cairo dependency OK/good 2) how strict to be on back compat, either a) "always keep pixels from construct time" or b) "never keep them" or c) "keep them sometimes trying to be clever"
 441 < hp> current pixbuf is a), my original patch is b), and I provided a layered-on patch which is c)
 442 < hp> so, worth looking at that topic, perhaps.
 443 < hp> at your leisure
 444 < Company> hp: I'd love if we could skip this whole mess until cairo supports gdk-pixbuf's formats
 445 < mclasen> my main question is: do we have to hurry getting this in for gtk3, or is this something we can do safely later ?
 446 < Company> hp: because at that point it becomes very trivial
 447 < hp> Company, yes, this does not make sense if that's the intent. but I thought the reason to support the cairo formats is more the GPU, than cairo.
 448 < Company> hp: the consensus has been to support lots of formats in the future last i talked about that
 449 < Company> hp: though we should ask ssp to be sure
 450 < hp> mclasen, I think it's only completely safe in case 1), perhaps.
 451 < hp> Company but even if cairo supports pixbuf format, pixbuf format is still slow right?
 452 < Company> hp: but considering gdk-pixbuf's format is identical to the HTML5 <canvas> format...
 453 < hp> the actual point of the change is to load from pixdata, png, etc. directly into GPU format, in some sense
 454 < Company> hp: yes, maybe
 455 < hp> really, ha ;-)
 456 < mclasen> one wonders how that happened
 457 < hp> I meant case a)
 458 < hp> losing track
 459 < Company> hp: that whole topic of performance warrants a separate discussion
 460 < hp> another option for the immediate term is to just add public surface-from-pixbuf and pixbuf-to-surface converters
 461 < Company> hp: in general you want to conversion when uploading - and as long as we upload on every draw anyway, there's not much of an issue
 462 < mclasen> Company: so we'll wait for cairo 1.12 ?
 463 < Company> mclasen: i think that's best (assuming cairo 1.12 happens in a more timely fashion)
 464 < ebassi> in 2020?
 465 < ebassi> :-p
 466 < Company> i generally think that we should tackle gdk-pixbuf after gtk 3
 467 < Company> because there's nothing we can gain from doing it now
 468 < mclasen> yeah, no api impact
 469 < hp> Company, well, approach b) or c) are somewhat dicey enough that doing it for 3 is a little cleaner, imo
 470 < Company> and i'm certainly busy with gtk 3.0
 471 < hp> I would propose at least adding convert functions (publicizing the code in gdkcairo.c) for 3.0 
 472 < hp> that's just a trivial annoying problem that's easy to fix
 473 < mclasen> will that go into gdk-pixbuf and add a cairo dep there ?
 474 < Company> hp: i think my rendering cleanup branch has gdk_pixbuf_get_from_surface()
 475 < hp> mclasen I guess, or back to my original patch for this, which let you have pixbufs in other formats sans cairo, or else the function just returns a uchar*  ... 
 476 < walters> guint8 * please
 477  * desrt_ ducks out early
 478 < mclasen> I guess we'll decide that next time
 479 < Company> i think gdk-pixbuf should have a cairo dep
 480 < hp> yeah no rush to decide this week
 481 < Company> doesn't make lots of sense without :)
 482  * mclasen needs to attend to some homework issues here
 483 < Company> unless we decide to throw the whole GdkPixbuf API away
 484 < Company> i.e. do something like gdk-pixbuf 3.0
 485 < mclasen> the one thing we want to keep are loaders 
 486 < mclasen> and maybe animations
 487 < mclasen> and maybe the serialization
 488 < Company> i'll write my mail about my ideal pixbuf lib
 489 < hp> that's what I was saying in the email thread, the real question is what to do about Loader and Animation, not what to do about pixbuf vs. surface
 490 < hp> yes, and serialization/pixdata
 491 < mclasen> we clearly don't need compositing and scaling and filling
 492 < hp> moving Loader and Animation to cairo would make sense except that any API used outside of the draw() method added to cairo suffers from non-GObject suck
 493 < Company> i don't think adding these things to cairo is a good idea
 494 < Company> it might make sense to get rid of gobject for loaders
 495 < Company> but only if we share the loaders with mozilla
 496 < Company> and i don't see that happen quite yet
 497 < mclasen> we could also just use ImageMagick 
 498 < mclasen> :-)
 499 < Company> but i'd love to have non-sucky image loaders for gifs ;)
 500 < hp> there's always Imlib, guys
 501 < ebassi> heh, was about to suggest that
 502 < krh> hah
 503  * krh was waiting for somebody to mention imlib
 504 < ebassi> so, I guess that this was the last topic
 505 < ebassi> if somebody has other points, we can add them to the agenda for the next meeting -- which should be on the 21st
 506 < ebassi> right, I'll take silence as compliance :-)
 507 < ebassi> thanks everyone for attending, and see you in two weeks
 508 < pbor> 'night
 509 < ebassi> will send the minutes to the list, and the log to the wiki, as usual