< mclasen> first topic ? < desrt_> i can go first... * desrt_ adds an agenda item first :) < mclasen> I think you are first anyway < desrt_> okay < desrt_> so some of you already know that i talked with the release team recently < desrt_> and we've been freed from our obligation to backport GtkApplication to 2.22.0 < desrt_> that, mixed with the current mess i've stirred up with GApplication suggests that maybe we should take this chance to delay < desrt_> specifically, i'm proposing that we ship 2.26.0 glib without GApplication < desrt_> to mitigate some of the ill effects of this choice we would do the following: < desrt_> - branch glib-2-26 soon < desrt_> - release 2.27.0 off of master (including GApplication as it stands) < desrt_> - strip GApplication off the 2-26 branch and release 2.26.0 from there < 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 < ebassi> do we have feedback from the shell developers? < desrt_> walters, ? < desrt_> walters, on the list you seemed to be somewhat against this... < walters> well, what's the schedule for the next glib? < desrt_> december < mclasen> end of year < desrt_> it will fall with gtk 3.0 < walters> no after this one < walters> 2.28 i guess < desrt_> yes. that's the one in december. < walters> ah < mclasen> yes, 2.26 in a few weeks, 2.28 end of year < walters> okay < desrt_> the reason for the rush is because gnome 2.32.0 needs GSettings and GDBus < desrt_> so we must release glib 2.26.0 now < walters> well in general - i am unhappy with not shipping GApplication just because you can't implement $EDITOR with it yet < desrt_> walter; actually, the $EDITOR part is working fine already. it's the actions part that needs a bit more work. < desrt_> and most importantly, non-rushed review < 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 < desrt_> we will have some annoyed application developers from this choice < mclasen> I think we had them all speak up on ddl < desrt_> bastien, in particular, has made some mumbling on the list that although he understands the situation, he's not exactly happy about it < walters> well, we mgiht investigate how difficult it'd be to have app authors do copy&paste < walters> for at least uniqueness < desrt_> right -- so we have to decide what the "official party line" is in terms of what to do now < desrt_> i was thinking "go back to libunique" < desrt_> but some gdbus-based copy/paste stuff might be nice too < desrt_> in the end i guess each person will decide their own path < ebassi> libunique at least uses gdbus < desrt_> ah. nice indeed. < ebassi> thanks to chpe < desrt_> :) < desrt_> so are we more or less settled on this topic? < ebassi> need to do a proper release with gtk2 + gdbus < 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 < mclasen> I think we will have to release 2.26 with an apology for the sudden disappearance of promised new api < desrt_> ebassi, will you be around to talk after the meeting? < ebassi> desrt_: yes < desrt_> excellent < mclasen> but in the end, it is probably better to pull it now and bring it back properly in 3 months < desrt_> mclasen, i can manage the 2.26 release and take all the flak, since it's my fault... < mclasen> nah, that's not required < desrt_> okay. next topic < mclasen> we should probably do at least one 2.25 release after the stripping < mclasen> so, aim for branching 2.26 off later this week ? < desrt_> mclasen, i think that doesn't work < mclasen> no ? < desrt_> unless we want to do 2.25.x releases off the 2.26 branch < mclasen> right, that was my thought < desrt_> eh. i guess that's fine, actually < desrt_> okay < desrt_> before release we need some GDBus stuff done, though < desrt_> davidz has promised a GDBusMessage.lock() API and a final revisit of the filter stuff < mclasen> and just to finish that topic off, are there any remaining 2.26 api issues,apart from that ? < desrt_> i think chpe proposed an API that he liked < desrt_> and i was OK with, too < desrt_> he said he'd find time later this week < ebassi> g_object_class_install_properties() doesn't have an accepted-commit_now state but was reviewed < desrt_> oh. i liked what i read there. < desrt_> i ran the tests. they worked... *shrug* < desrt_> mclasen, ACK for push? < ebassi> with that in, I can finally finish my "modern gobject programming" document :-) < mclasen> fine with me < desrt_> ebassi, you will find that you have your status :p < mclasen> ebassi: volume zero of the gnome platform programming series ? < ebassi> mclasen: heh -- or, at least, a replacement for the gobject tutorial in the API reference < mclasen> maybe rename that to gobject obscurial < mclasen> anyway, next topic < desrt_> https://bugzilla.gnome.org/show_bug.cgi?id=50076 < desrt_> i think some changes will also be required here pre-2.26.0 < ebassi> desrt_: I've read your comment -- need to finish off my reply < desrt_> okay. we can also deal with that personally after the meeting, i think? < ebassi> sure < desrt_> okay. that one was fast. :) < desrt_> Company, ping < desrt_> Company, update? < Company> 4-1 Germany * desrt_ watches the coin land < desrt_> how's gtk? :) < Company> ECONTEXT < desrt_> gtk3 cleanups status? < Company> rendering cleanup was blocking on cairo 1.10 < Company> or better: review was < Company> and i've been silently chugging along replacing expose events with draw functions < desrt_> did you come to a decision about the signal prototype? < Company> i used (GtkWidget *, cairo_t *, int, int) < desrt_> cool < desrt_> have you broken into any container classes yet? < hp> what are the ints? < desrt_> or are you just letting the containers move around expose events still? < Company> not sure how useful the int, int really is, because there's borders etc < desrt_> hp; width and height of the widget < Company> hp: allcation width/height < mclasen> doesn't the widget know that itself ? < Company> mclasen: it would have to query and we assumed it'd want to know it anyway < desrt_> mclasen; yes. it does, but there are two reasons to avoid using it out of the widget < desrt_> 1) it's in the allocation (which also contains the x/y that we want the user to completely ignore) < desrt_> 2) according to Company's experience so far, it tends to result in much more compact code < hp> it just saves typing, width vs. widget->allocation.width ? < desrt_> more or less < desrt_> but it also makes the idea of accessing 'allocation' as something that you should not do < Company> hp: that and it avoids having to think about allocations < hp> but you could assert (width == widget->allocation.width) or no? < desrt_> it's dirty. don't touch it. (no. really.) < Company> hp: yes < mclasen> Company: but wasn't there some idea to normalize to a unit square, or something ? < Company> mclasen: the context is positioned at the widget's top left corner < 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 < hp> i.e. you don't want people thinking their size_allocate should be replicated inside draw() < desrt_> hp; dealing with changes in respect to size allocate is a bit different... < desrt_> since you're being handed an allocation directly in that case < desrt_> but even then, probably you should just chain up to let the widget worry about setting that allocation onto itself < 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. < Company> hp: the vfunc has a width < Company> hp: the gtk_widget_draw() API does't < hp> company, sure < 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 < desrt_> it's difficult to describe this idea to language bindings, for example < 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' < hp> which is surprising, to me < hp> .02 < Company> yeah < Company> it'd be more useful if it was interesting values < Company> like after subtracting padding etc < Company> i thought it'd be useful, but it turned out it wasn't as much while porting code < desrt_> hp, thanks for the concerns < Company> but then, the worst part of the porting is the mess that is border_width etc < desrt_> Company, any more totally crazy ideas pending? < hp> Company oh I fixed that one * Company asked on bug 628828 now < hp> I'll async'ly answer on there < 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 < mclasen> Company: so, the rendering-cleanup branch is ready for reviewing the pixmap removal, yeah ? < Company> mclasen: yeah < mclasen> ok, I'll try to get to it this week < mclasen> of course, everybody else should chime in as well < kris> i should try to build and run it on mac < Company> people know that everything i do is correct anyway, so they don't review my stuff as much as i'd like... < kris> and hope it won't need a few day-long debugging sessions this time :) < Company> kris: os x is probably non-compiling again < Company> as is win32 < mclasen> should we move into the next topic, then ? or are there more things to discuss about rendering-cleanup ? < Company> none from me < desrt_> re: the wiki page: is there anything on the cleanup list we should still discuss or should it be cleared out? < mclasen> where does your draw-function-introduction work live ? the same branch ? < ebassi> right, then: Padding cleanup < desrt_> we have a lot of items there for some time now < mclasen> desrt_: which cleanup list are you referring to ? < Company> mclasen: haven't pushed it yet < Company> mclasen: shoould i? < mclasen> might be more convenient to keep the branch at the pixmap removal level for the review ? < Company> mclasen: yeah, that was my idea < desrt_> mclasen, we have the bullet points on the meeting agenda page < mclasen> oh, that list < desrt_> the subitems under "possible GTK3 cleanup tasks" < mclasen> I've just thrown that in there as a source of inspiration < mclasen> we can remove it, I don' think discussing it now does much good < desrt_> k < Company> mclasen: reminds me: i had expected a reply from you about http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00069.html < mclasen> we should rather discuss the cleanups that are actually happening, like havocs padding work < mclasen> Company: I must have overlooked that < 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 < mclasen> lets reduce that to 4 years, I think < hp> well, also, "replace it so there's something to port to, then remove it" :-P < hp> except GtkRuler, screw that thing ... < ebassi> hehe < Company> ensonic's gonna fix that! < Company> next topic? < mclasen> padding cleanup ? < ebassi> yep < mclasen> havoc has put forward 3 things: alignment/padding in gtkwidget, magic expand, legacy-free grid container < ebassi> 1) and 3) are +1 for me < ebassi> the magic expand is nice, but I'm wary of magic < mclasen> of course, 3) is vapourware atm < 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. < hp> ebassi it's not really magic (it's not heuristic guesses or anything). it's just saving typing. < hp> ebassi incidentally I'm likely to come after clutter with all the same changes sooner or later :-P < ebassi> hp: what happens to the bubbling up to the parent if there's a container that doesn't understand expan in the middle? < hp> ebassi what do you mean by doesn't understand expand? < ebassi> hp: I mean, what happens if a GtkContainer does not allow expanding its children? < ebassi> does the chain stop there? < ebassi> I guess < hp> then they won't expand, yep < hp> you can also manually stop the bubble by setting expand=FALSE manually < ebassi> right < mclasen> I wonder if we need a non-magic expand flag in addition ? < hp> what container doesn't expand children though? < hp> there is a manual flag and an automatic flag < mclasen> I man for making some children expand in the container without marking them as 'the content area' < hp> the manual flag always "wins" < hp> mclasen oh you mean be able to expand without affecting window resize? < Company> mclasen: if you want children to expand, you set their expand poperty < 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. < Company> hp: so expand=FALSE in a container basically overrides all expand=TRUE in children, right < Company> ? < hp> Company yeah every widget has a manual override, and if that is unset, it goes by children < Company> right < Company> i think it makes a lot of sense < Company> the only thing to get right is properly chaining this up < 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. < Company> scrolled window < desrt_> are we basically talking about deprecating GtkMisc and GtkAlignment? < Company> though that one should expand by dfault < Company> desrt_: yes < desrt_> (and border_width on GtkContainer) < hp> desrt well that's the padding patch, separate from this expand stuff. but yes. < Company> GtkMisc has expand, too < desrt_> seems very webby :) < hp> Company, GtkAlignment has xscale/yscale < hp> yeah I guess expand replaces that < Company> desrt_: yeah, the only replacement for webby things that we don't have yet is a replacement for the "display" css property < desrt_> is that the inline vs. block one? < 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. < Company> desrt_: yeah < desrt_> heh. fun. :) < hp> you want inline vs. block or block vs. hidden ? < desrt_> i have to say that the new way of looking at expand is probably closer to what user's expect < desrt_> *users < desrt_> we get really a lot of people coming into #gtk+ wondering why stuff isn't expanding < desrt_> and we have to explain to them that they have to set the expand property on the box < desrt_> not the child < 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"... < hp> plus if you want to change whether a child expands you have to change more than one bool, which is lame. < desrt_> 'fill' is extremely dubious in terms of usefulness < Company> the only thing about expand is that it can have 3 values: true, false, inherit - hose are always hard to write api for < mclasen> we have a pretty setup with foo and foo-set < desrt_> inherit is that it expands only if it has a child that wants to expand? < Company> mclasen: i hate that, too - GtkCellRendererText is kinda sucky code < Company> desrt_: yeah < desrt_> so there is a bit of weirdness here < desrt_> consider this case (everything is same orientation here... let's say horizontal) < Company> could we replace the expand/no-expand with a dedicated widget? < desrt_> we have a toplevel box with 2 items inside a window < desrt_> the left item is a box with 2 items.. one expandable and one not < Company> or are properties more useful? < desrt_> the right item is a box with 2 items... both expandable < desrt_> we resize the window to make it bigger < desrt_> how is the space proportioned among the 3 expandable terminal widgets? < hp> depends on how the two widgets are packed, they are also in a box? < hp> is the box homogeneous? < desrt_> not homogeneous < Company> desrt_: according to their size request usually < desrt_> and yes. a box. < hp> it just uses the algorithm of the box they're in < hp> iirc GtkBox just equally divides extra space among expand widgets? < Company> linearly i think < 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 < Company> so a widget with twice the size request ets twice the extra space < mitch> as expected i'd say < hp> desrt right, so if you don't want that, don't use two layers of nested boxes ;-) < Company> desrt_: yes < Company> what hp says :) < desrt_> ya. that's reasonable i guess. < desrt_> i half asked that question just to clarify my own understanding :) < desrt_> so what happens to the packing properties? * Company would be happy if gtk got rid of child properties completely < hp> packing properties still work but they are redundant basically. the API of box sort of ends up mostly vanishing. < 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. < desrt_> hp; are you proposing breaking API of pack_start(), for example? < Company> hrm true < Company> we do have useful child properties < hp> desrt_, no, we'd just leave it there. that's why I suggested a GtkGrid because I think fixing Box is too incompatible. < hp> I mean, Box works fine still < desrt_> hmm < hp> but it just isn't logical anymore < 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" < mclasen> I think we'd leave GtkBox untouched, similar to GtkH/VBox, and just put a legacy-free container in at some point < 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 < mclasen> so we can kick the boxes out in gtk4 < desrt_> it's really changing the flavour of gtk < desrt_> in an extremely user-visible way (where user = app developer) < desrt_> not saying that's bad, of course < mclasen> how do you mean ? all the old apis are still there... < desrt_> right. but we will expect people not to use them < 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. < desrt_> hp, i agree about easier to learn < desrt_> as i mentioned, our current expand/fill child-property thing is just damn confusing for most people < Company> GtkBox will be like GtkCTree - we just have it to scare people < desrt_> hp, will you make it to the hackfest? < 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" < hp> desrt_, is it the one in october? < desrt_> yes. 18-22. < desrt_> it seems like we could have a very useful discussion around this topic < hp> I can give it a shot. depends on what is happening then < desrt_> okay < 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. < 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. < desrt_> hp; i think i disagree with you < desrt_> hp; but i could probably be convinced that you're right < hp> I have never had real code using the automatic expand-propagation, but it seems logical. < desrt_> i have a hard time remembering using a x/yscale that wasn't 0.0 or 1.0 < desrt_> or a x/yalign that wasn't 0.0 0.5 or 1.0 < Company> y < hp> if you _really_ need the float x/y scale then a custom container like Alignment is still a good solution < Company> desrt_: you can still write a GtkAlignment < hp> but I don't think it's a reason to muck up GtkWidget and the primary API * Company agrees with hp < Company> someone could grep jhbuild for an alignment with odd scales < 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 < desrt_> i'd actually advocate leaving GtkAlignment < desrt_> for those 'weird cases' < hp> desrt_, removing GtkAlignment is presumably a 4.0 task, if ever < desrt_> cool. < 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 < 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 < desrt_> hp, thanks for the intro. i had no idea about this stuff before. * mclasen thinks that baseline alignment is probably more interesting that odd flloating point values for xalign < desrt_> mclasen, are we adding 'point size' as a GtkWidget property now? < mclasen> so, to finish up the padding cleanup, do we have agreement to land the padding / align part ? < desrt_> i think we can wrap up early? < desrt_> ah... * desrt_ didn't think it would be so soon :) < ebassi> padding/align sounds good to me < desrt_> i'd prefer to hold off a little bit < hp> oh and renaming padding to margin < desrt_> but i don't really have a stake here < mclasen> sure, we don't have to rush it < mclasen> and renaming to margin sounds good to me too < hp> desrt_, are you going to look at it more closely and send some thoughts? < desrt_> yes < mclasen> should we land this on a branch for now, for easier inspection ? < Company> branches are useful < Company> i prefer reviews in cgit to reviews anywhere else < desrt_> ya. reading a git log is easier than flitting between a patch series < hp> I currently have padding and expanding on two separate branches, but if it's easier I could push just one < hp> depends on if people want to eval these together or separate < desrt_> i think we agree that padding would come first, right? < hp> they aren't really very interdependent < mclasen> yeah < desrt_> so push padding < desrt_> then rebase expanding onto the padding branch < desrt_> and push it < hp> desrt_, so one branch with both features < desrt_> one branch with one feature < desrt_> other branch as a fast-forward of the first branch, but with expansion added as well < hp> oh I see, sure < desrt_> jjardon, hello :) < ebassi> I guess the next point, "Deprecate/remove GtkRequisition" also fits in with geometry/layout changes < hp> what are the random-feature-branch naming conventions? < ebassi> but tristan is not here :-/ < desrt_> hp; i don't know that there is one < jjardon> desrt_: hi!, hello all < mclasen> hp: random names for random features < hp> ok, I can follow that guideline < desrt_> hp, but be aware of the other guideline: awesome names for awesome features < hp> oh, did you talk about breaking gdk-pixbuf to use cairo already in a prior meeting? < jjardon> ebassi: tristan made a patch in for the Deprecate/remove GtkRequisition bug: https://bugzilla.gnome.org/show_bug.cgi?id=626939#c3 < desrt_> oh. we have lockbutton up today too. /me missed that. < mclasen> hp: no, we haven't talked about that yet < mclasen> yeah, lockbutton < Company> damn < Company> i wanted to write a mail about my ideas wrt breaking GdkPixbuf < mclasen> its just a very small widget that I've ported from polkit-gtk < mclasen> it just turns a GPermission into a button, basically < desrt_> mclasen, my biggest concern here is guidelines about how it is meant to be used? < mclasen> my main motivation for wanting it in gtk is that we can kill another microlib < mclasen> ie polkitgtk < ebassi> that would be a good reason already < 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? < mclasen> and it is a step towards real simple preference dialogs < ebassi> for the guidelines, I guess it falls under the HIG < jjardon> That fix is needed to move the widget->requisition to a private structure < mclasen> desrt_: right, I'll have to flesh out the docs for that, I guess < ebassi> mclasen: feedback from the UX team would be good < mclasen> those are good points, could you perhaps comment in the bug ? < desrt_> mclasen, or maybe ask one of our design-minded people... < mclasen> ok, I'll do that < desrt_> i'll comment < mclasen> I'm fairly sure they will approve, though < mclasen> since they are all os x fanboys < mclasen> One thing I already did in preparation for the lockbutton < mclasen> is to make buttonboxes semi-homogeneous instead of strictly homogeneous < desrt_> did you land that? < mclasen> yes < desrt_> breaking at 1.5? < mclasen> pretty sure I did < mclasen> yeah < desrt_> with or without hinting API? < mclasen> think it needs to be tweakable ? < mclasen> no hinting for now < desrt_> not unless someone asks :) < desrt_> and again, not unless someone asks < desrt_> (imho) < desrt_> sounds quite right < mclasen> ok < mclasen> did we have more scheduled topics ? < ebassi> case sensitive search in TextBuffer < pbor> there was also case insensitive search on the agenda... < ebassi> http://bugzilla.gnome.org/show_bug.cgi?id=61852 < ebassi> honestly, I see no blocking issue there < ebassi> if there's a patch < desrt_> ah hah! < 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 < desrt_> i have a recommendation :) < mclasen> ugh, I had promised to review that < desrt_> you know there's this kind of searching that ancient grep used to support (-y option i think) < desrt_> lowercase letters were considered insensitive < desrt_> but uppercase had to exact-match < mitch> use case? < pbor> we are willing to do the cut&paste work if there is consensus < desrt_> so you could search for "foo" and find "foo" "Foo" or "FOO" but would only hit "FOO" < pbor> and by we, I mean nacho :) < 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." < Company> desrt_: so go for it! :) < desrt_> Company, i have no interest < desrt_> Company, just sharing an idea i recently read about :) < Company> hehe < mclasen> pbor: I think I had a vague feeling that the implementation is not really ideal < mclasen> case-folding a line at a time < mclasen> but, since we have no streaming regex api, I guess it is maybe the best we can do for now < 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 < pbor> and all projects that use textview cut and paste that code < mclasen> yeah, I guess that is the winning argument here < ebassi> I fully expect somebody complaining once it gets into TextBuffer < mclasen> so, lets tentatively accept it < mclasen> and wait for gmorten to show up and shred it.... < ebassi> "I have this faster implementation written on a napkin" < pbor> ebassi: that's when the usual "patches welcome" comes up :) < ebassi> heh < Company> "napkins welcome" < mclasen> pbor: is there a bug somewhere where I need to say 'go ahead' ? < pbor> mclasen: either bug http://bugzilla.gnome.org/show_bug.cgi?id=61852 or reply to nacho's mail I linked < mclasen> ok, I'll reply < pbor> thanks < mclasen> time to wrap up ? or should we touch on gdk-pixbuf <> cairo before closing ? < 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" < hp> current pixbuf is a), my original patch is b), and I provided a layered-on patch which is c) < hp> so, worth looking at that topic, perhaps. < hp> at your leisure < Company> hp: I'd love if we could skip this whole mess until cairo supports gdk-pixbuf's formats < mclasen> my main question is: do we have to hurry getting this in for gtk3, or is this something we can do safely later ? < Company> hp: because at that point it becomes very trivial < 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. < Company> hp: the consensus has been to support lots of formats in the future last i talked about that < Company> hp: though we should ask ssp to be sure < hp> mclasen, I think it's only completely safe in case 1), perhaps. < hp> Company but even if cairo supports pixbuf format, pixbuf format is still slow right? < Company> hp: but considering gdk-pixbuf's format is identical to the HTML5 format... < hp> the actual point of the change is to load from pixdata, png, etc. directly into GPU format, in some sense < Company> hp: yes, maybe < hp> really, ha ;-) < mclasen> one wonders how that happened < hp> I meant case a) < hp> losing track < Company> hp: that whole topic of performance warrants a separate discussion < hp> another option for the immediate term is to just add public surface-from-pixbuf and pixbuf-to-surface converters < 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 < mclasen> Company: so we'll wait for cairo 1.12 ? < Company> mclasen: i think that's best (assuming cairo 1.12 happens in a more timely fashion) < ebassi> in 2020? < ebassi> :-p < Company> i generally think that we should tackle gdk-pixbuf after gtk 3 < Company> because there's nothing we can gain from doing it now < mclasen> yeah, no api impact < hp> Company, well, approach b) or c) are somewhat dicey enough that doing it for 3 is a little cleaner, imo < Company> and i'm certainly busy with gtk 3.0 < hp> I would propose at least adding convert functions (publicizing the code in gdkcairo.c) for 3.0 < hp> that's just a trivial annoying problem that's easy to fix < mclasen> will that go into gdk-pixbuf and add a cairo dep there ? < Company> hp: i think my rendering cleanup branch has gdk_pixbuf_get_from_surface() < 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* ... < walters> guint8 * please * desrt_ ducks out early < mclasen> I guess we'll decide that next time < Company> i think gdk-pixbuf should have a cairo dep < hp> yeah no rush to decide this week < Company> doesn't make lots of sense without :) * mclasen needs to attend to some homework issues here < Company> unless we decide to throw the whole GdkPixbuf API away < Company> i.e. do something like gdk-pixbuf 3.0 < mclasen> the one thing we want to keep are loaders < mclasen> and maybe animations < mclasen> and maybe the serialization < Company> i'll write my mail about my ideal pixbuf lib < 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 < hp> yes, and serialization/pixdata < mclasen> we clearly don't need compositing and scaling and filling < 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 < Company> i don't think adding these things to cairo is a good idea < Company> it might make sense to get rid of gobject for loaders < Company> but only if we share the loaders with mozilla < Company> and i don't see that happen quite yet < mclasen> we could also just use ImageMagick < mclasen> :-) < Company> but i'd love to have non-sucky image loaders for gifs ;) < hp> there's always Imlib, guys < ebassi> heh, was about to suggest that < krh> hah * krh was waiting for somebody to mention imlib < ebassi> so, I guess that this was the last topic < ebassi> if somebody has other points, we can add them to the agenda for the next meeting -- which should be on the 21st < ebassi> right, I'll take silence as compliance :-) < ebassi> thanks everyone for attending, and see you in two weeks < pbor> 'night < ebassi> will send the minutes to the list, and the log to the wiki, as usual