1 < jdahlin> ebassi: should we start?
   2 < mclasen> tbf: if you file a bug I may have a look, or ask danw
   3 < ebassi> jdahlin: yes, we should start
   4 < ebassi> I'll write down the points:
   5 < ebassi> * extended layout management (tbf)
   6 < ebassi> * offscreen redirection (mitch, ebassi)
   7 < ebassi> * 2.14 status (mclasen)
   8 < ebassi> * guadec team meeting
   9 < ebassi> * consider adding EggToolPalette (murrayc, tbf)
  10 < ebassi> these are the points that are on the wiki and that have been sent to me in addition to the first two
  11 < ebassi> so, who wants to start? :-)
  12 < mclasen> small addition under misc: Gnome tool kit vs GTK+ toolkit
  13 < bratsche> I also want some discussion of http://bugzilla.gnome.org/show_bug.cgi?id=540529
  14 < ebassi> oh, yeah
  15 < bratsche> I don't know what to do with it, if anything.
  16 < mclasen> should we discuss that first, to get it out of the way ?
  17 < kris> yea why not
  18 < mclasen> I think it is largely just a miscommunication
  19 < kris> I don't see any point of removing references to GIMP
  20 < kris> GTK+ has a history
  21 < kris> and its history is "GIMP Toolkit"
  22 < jdahlin> I also wanted to discuss formalising the review process, but that might be better to do at guadec.
  23 < bratsche> I don't have any opinion one way or the other, I just want to know what I should do with it.
  24 < kris> I don't see anything that is wrong with this
  25 < mclasen> I thought the request was mainly about removing a misleading name from visible places
  26 < rhult> behdad only asked to remove it from the pc file, afaik
  27 < rhult> which makes sense and nobody has objected to
  28 < bratsche> The bug title says "Remove all GIMP references", so I took that literally and changed the name in all the .[ch] files as well.
  29 < mclasen> rhult: and I said it might be good to look through the docs, too
  30 < jdahlin> I might argue that we should keep it consistent, if we remove it in one place we should remove it everywhere
  31 < rhult> mclasen, right
  32 < mclasen> and the result was a patch that touched every single source file
  33 < kris> what is the problem with "gimp toolkit" at all?
  34 < mclasen> kris: no problem per se, except for it being slightly misleading
  35 < hpj> i think "gimp" is frequently taken to mean "inferior"
  36 < jdahlin> right, gtk+ is used outside of gimp.
  37 < mclasen> the new website never spells GTK+ out as Gimp tool kit, as far as I can see
  38 < kris> how? people think it is 100% tied to gimp?
  39 < mclasen> kris: there is nothing wrong with acknowledging the history
  40 < mclasen> I've proposed to add a history section to the docs
  41 < kris> anyway, if we have to, I would update the pkgconfig file to say "GTK+" or "GTK+ UI toolkit"
  42 < kris> but not touch source fioles
  43 < yosh> honestly, changing every source file should've been a giant red flag
  44 < kris> adding a history section to the docs sounds like a nice idea
  45 < yosh> pkg-config can just say "GTK+" no expansion
  46 < mclasen> that seems to be a clear agreement.
  47 < mclasen> bratsche: good enough ?
  48 < bratsche> Yeah, so leave the docs/.pc/whatever files and revert GTK+ Toolkit -> GIMP Toolkit in all the .[ch] files?
  49 < kris> what happened to the docs?
  50 < bratsche> I updated -every- reference. :)
  51 < mclasen> yes. I can look into a 'history' section for the docs in my 'spare time'
  52 < kris> I don't see the need to update the docs
  53 < ebassi> okay then. ACTION: bratsche will revert the changes to the source files
  54 < kris> from the original situation (before this commit) I would *only* update the pkg-config file
  55 < kris> leave all source code and docs as is
  56 < kris> add a history section to the docs at some point
  57 < bratsche> Well wait.. revert all the .[ch] files for sure.  Should I also revert all docs?
  58 < kris> and GTK+ toolkit sounds wrong (TK is toolkit), please use just "GTK+" or "GTK+ Graphical UI Library" or something if it needs further explanation
  59 < yosh> yeah, only change the .pc file, and I'd argue to make it just say "GTK+" instead of "GTK+ Toolkit"
  60 < kris> yosh and I clearly agree here ;)
  61 < yosh> so revert the entire patch, then just change the .pc file to just say "GTK+"
  62 < jdahlin> I wouldn't call it GIMP Toolkit in the documentation, unless in an historical section
  63 < tbf> yosh: just saying "GTK+" is really sub-optimal
  64 < yosh> tbf: why?
  65 < jdahlin> following the precedent set by the new website
  66 < tbf> yosh: the .pc file description should be at least a little bit descriptive
  67 < kris> tbf: then we should go for "GTK+ Graphical UI library" or something like that
  68 < kris> not "GTK+ Toolkit"
  69 < tbf> kris: yup
  70 < bratsche> I like that.
  71 < yosh> tbf: I don't agree. do you really think someone who knows enough to look at pkg-config doesn't know what GTK+ is?
  72 < bratsche> So that goes in .pc files, everything else goes back to the way it used to be right?
  73 < mclasen> bratsche: that seems the way to go
  74 < bratsche> yosh: Maybe they know what it is, but how is additional information harmful?
  75 < tbf> yosh: when dealing with new libs i do
  76 < yosh> we're not talking about the generic case
  77 < yosh> but "Graphical UI Library" is fine
  78 < tbf> yosh: i just answered your question
  79 < tbf> yosh: even if it was suggestive
  80 < mclasen> lets send the fight over the exact pc file line to a subcomittee
  81 < kris> mclasen: I think we have just agreed though ;)
  82 < tbf> yosh: also think about applications like anjuta which might use that description entry
  83 < mclasen> tbf: they are already broken by not getting translations
  84 < tbf> mclasen: that's no reason to break it even more
  85 < mclasen> true
  86 < kris> Is anybody against using "GTK+ Graphical UI Library"?
  87 < kris> if not, we can settle this and continue ;)
  88 < mclasen> moving on...
  89 < ebassi> yeah, moving on
  90 < bratsche> Yes, I will do this tonight after work.
  91 < bratsche> Thanks everyone.
  92 < mclasen> I'd like to do 2.14 status next if thats ok
  93 < bratsche> When is the 2.14 release date?
  94 < mclasen> so, the plan at last years guadec was to have a 2.14 release by this years guadec
  95 < kris> I would propose to discuss the 2.14 release date at guadec, just like last year (and the year before)
  96 < mclasen> thats obviously getting a bit tight
  97 < mclasen> kris: fine with me, but I won't be there
  98 < kris> mclasen: oh really? suck :(
  99 < mclasen> kris: family obligations...
 100 < timj> mclasen: urm, really bad news..
 101 < mclasen> kris: I already took my 2 conference days this year...
 102 < kris> mclasen: too bad :(
 103 < bratsche> I told Andre Klapper I would try to finish up my GUnitTest (or whatever you call it) for #56070 by then, but I haven't yet.  I'll try to do it this week if there is a chance to get this in by 2.14 release.
 104 < kris> so what is left for 2.14?
 105 < mclasen> what I'm interested in today is what people want to get into 2.14 still ?
 106 < mclasen> any major outstanding features or fixes ?
 107 < kris> I am pondering to *maybe* get tree view column resizing into 2.14
 108 < kris> but I found new bugs at the airport last weekend, need to look into that again to make a good estimation
 109 < kris> I guess it could go into 2.14.x also
 110 < bratsche> If I can finish this test really soon then I'll propose it and the current patch for #56070
 111 < jdahlin> mclasen: pbor wanted me to proxy the request for builder root support
 112 < timj> bratsche: comment #134 there sounds like you should joint the gtk+ BOF at guadec. i'd like to talk about changes in event processing there
 113 < kris> timj: when it the GTK+ BOF scheduled btw?
 114 < tbf> guess extended layout and eggtoolpalette are out due lack of time?
 115 < bratsche> timj: I'm not at guadec though. :(
 116 < kris> timj: I couldnt find it in the schedule today
 117 < mclasen> tbf: if either are ready to be dropped in right now, I don't see that as a given
 118 < jdahlin> tbf: are you going to push and do the integration ?
 119 < timj> kris: after your talk, i think the schedule says something else that "BOF"
 120 < Sonderblade> there was quite a few accessors missing after the GSEAL merge, i think it would be nice to have them so that compiling with sealing enabled would be feasible
 121 < kris> timj: oh really?
 122 < mclasen> in particular the toolpalette is probably a fairly isolated piece ?
 123 < tbf> mclasen: well, eggtoolpalette is quite isolated and finished
 124 < timj> tbf: yes, definitely my feeling, it's too late for those
 125 < jdahlin> I'd also like to see extended layout go in, not sure what state it is in though.
 126 < kris> timj: not on the schedule here http://guadec.expectnation.com/guadec08/public/schedule/grid/2008-07-11
 127 < mclasen> tbf: the question is: where are the uses that justify the rushed inclusion into gtk ?
 128 < timj> mclasen: i don't think it's a good idea to push major new APIs at this point. that usually needs proper review and we're late with the schedule promised for gnome already
 129 < kris> Sonderblade: do you have a list of what's missing?
 130 < mclasen> yeah, I tend to agree
 131 < tbf> mclasen: so far only glom uses it
 132 < tbf> afaik
 133 < jdahlin> yes, if we're late then we should defer new api to the next release
 134 < mclasen> tbf: would it be a major disaster for glom to ship its own copy for a little longer ?
 135 < mclasen> tbf: ie until 2.15 opens ?
 136 < mclasen> tbf: I know that is probably a bit disappointing considering all the work you've sunken into the extended layout already
 137 < jdahlin> (or if it will be 3.1)
 138 < Sonderblade> kris: no list, but there are some bug reports, "quite a lot" is missing even if much have been fixed
 139 < timj> tbf: we should really talk through your exact layouting changes at guadec, we didn't really get a chance to finish that last year (and in berlin we both were too busy)
 140 < tbf> mclasen: not really, but it would be reasonable to have a proper done tool palette in gtk at some time
 141 < kris> Sonderblade: I can't imagine much is missing though
 142 < tbf> mclasen: there are quite some apps which use have-assed versions
 143 < mclasen> tbf: would e.g the gimp switch to that implementation ? that would be a major selling point, in my view 
 144 < tbf> mclasen: well, regarding extended layout i am also quite guilty of not pushing it enough
 145 < kris> to me extended layout sounds really nice to start 2.15 with
 146 < kris> if we can review and land it early, it will get large amounts of testing
 147 < mclasen> tbf: you should nail down the available parts of the GTK+ maintainership at guadec to have it discussed to the end
 148 < mclasen> together with mitch's box flipping...
 149 < mclasen> ok, coming back to unfinished things in the current tree
 150 < mclasen> what is the state of the GSEAL merge currently ?
 151 < jdahlin> there's a wiki page iirc
 152 < timj> mclasen: all uncontroversial bits of our branch have been merged
 153 < jdahlin> http://live.gnome.org/GTK%2B/3.0/PendingSealings
 154 < mclasen> all abi accidents straightened out ?
 155 < timj> people have started sealing gtkrcstyle, gtkstyle and more, but i haven't really looked at those yet and don't know whther that's trivial enough to actually have it.
 156 < mclasen> i'm asking because I want to get another snapshot out this week, before guadec
 157 < timj> i'm not aware of ramaining abi accidents
 158 < kris> I guess we are having a 2.16, which means that having GSEAL done is not a 2.14 requirement
 159 < timj> remaining
 160 < mclasen> timj: is the goal to have the remaining things sealed before 2.14 ?
 161 < timj> mclasen: no, i think keeping the gnome schedule is more important
 162 < timj> it'd be nice to have more things sealed, but i don't think we should hold off the release further because of this
 163 < mclasen> timj: ok, good
 164 < jdahlin> timj: off topic: is GtkStyle really that hard, seems to me that it just need a lot of getters taking one GtkStateType argument?
 165 < timj> jdahlin: i cannot provide you with a well informed opinion on gtkstyle at this point
 166 < jdahlin> timj: okay, I'll open a bug and discuss there.
 167 < timj> i.e. prefer to investigate this before being pressed for a call ;)
 168 < mclasen> the other critical piece is the file chooser...
 169 < kalikiana> jdahlin: You might talk to garnacho who's working on gtkrcstyle which is a bit related
 170 < garnacho> yeah, also began working on GtkStyle :)
 171 < mclasen> bratsche: do you have any idea how well the trunk filechooser works on win32 currently ?
 172 < bratsche> mclasen: No, but I can find out if you want.
 173 < mclasen> bratsche: that would be useful, I know hans and tor did some work in gio to make it better
 174 < bratsche> mclasen: I haven't been working off of trunk on Win32 so far.
 175 < bratsche> Okay, I'll look into it then.
 176 < mclasen> so you probably need trunk glib too
 177 < bratsche> Yeah.
 178 < mclasen> or just wait until I do releases later this week...
 179 < bratsche> So far I haven't really looked into gio Win32 stuff.  I'm mostly just familiar with gdk/win32 so far.
 180 < bratsche> Okay, I made myself a note to look into this.
 181 < mclasen> so, action on this topic: I do releases this week, and the guadec meeting discusses the final schedule ?>
 182 < timj> mclasen: fine, taking a note on the guadec todo here
 183 < timj> mclasen: we'll prolly discuss the schedule for the next stable gtk, i guess...
 184 < mclasen> yeah, that too
 185 < ebassi> apropos guadec
 186 < mclasen> and the version number...
 187 < kris> this gtk+ 2.14
 188 < kris> next 2.16
 189 < kris> done
 190 < kris> !
 191 < mclasen> easy as pie
 192 < bratsche> :)
 193 < ebassi> hehe
 194  * timj is all for syncing versions numbers at latest with 3.0
 195 < kris> timj: yes, with 3.0 we will sync
 196 < kris> timj: i will break abi in glib for you, so you can call it 3.0
 197 < kris> done!
 198 < ebassi> apropos guadec: who's taking the minutes?
 199 < kris> ebassi: I wouldnt mind to volunteer again
 200 < ebassi> cool, thanks kris
 201 < kris> unless the previous year's minutes sucked and somebody wants to take over
 202 < timj> guadec minutes? i'd love to have you do them kris ;)
 203 < kris> oaky
 204 < kris> I would bring my student notebook and pencil again
 205 < kris> would->will
 206 < timj> kris: they were great, i think even owen replied and said so
 207 < ebassi> kris: the minutes last year were great :-)
 208 < kris> okay
 209 < kris> settled then
 210 < kris> done!
 211 < mclasen> ebassi: anything else on guadec meeting preparations ?
 212 < ebassi> we already have a slot, so I'll round up the usual suspects when the day comes :-)
 213 < mclasen> sounds good to me
 214 < mclasen> what topics do we have left, offscreen redirection ?
 215 < ebassi> yes
 216 < ebassi> no mitch, though
 217 < ebassi> well
 218 < bratsche> Yeah, he said he probably wouldn't be here.
 219 < timj> mclasen: offscreen pixmaps are in, offscreen refactorings are in, event procressing is planned for post-2.14 with having a dicussion on event processing during guadec
 220 < timj> i.e. event processing would be nice to get in later this fall
 221 < hpj> i've a question for the misc section
 222 < ebassi> timj: yeah, it would. is the GdkOffscreenWindow slated to go in for 2.14 then?
 223 < mclasen> hpj: lets finish offscreen, then we'll take your question
 224 < ebassi> timj: it would at least enable embedding complex widgets in canvases, even without the event transformation
 225 < ebassi> I agree that the event translation is too complex to go it now, though, and it will require some API talk with the other out-of-tree canvases as well
 226 < timj> ebassi: i've definitely not given the rest enough review to say it can easily go in
 227 < ebassi> timj: yeah, I understand that
 228 < timj> and it seems the remaining patch still has some issues, so it's probably better to reconsider integration when those have been straightened out. considering that we're running late already, that's most probably post-2.14 again
 229 < ebassi> okay, fair enough
 230 < mclasen> does that leave us with something useful in 2.14 ?
 231 < mclasen> at least we have the snapshotting, I guess
 232 < ebassi> mclasen: well, gtk_widget_get_snapshot() and a huge refactoring of GdkWindow
 233 < timj> yes, and i consider both huge gains already ;)
 234 < timj> they definitely took quite some work from alex, ebassi and me at least ;))
 235 < bratsche> What is the refactoring in GdkWindow?
 236 < mclasen> sounds fine to me then
 237 < mclasen> anything else on offscreen ?
 238 < mclasen> else we should hear hpj's question
 239 < ebassi> bratsche: moved most of the api into a GInterface
 240 < timj> mclasen: nothing else from em
 241 < timj> me
 242 < ebassi> bratsche: implemented by the backends - some of which are now broken, I guess :-)
 243 < ebassi> mclasen: nothing more from me
 244 < kris> quartz has been fixed on Friday at least
 245 < kris> works fine
 246 < bratsche> ebassi: Cool, thanks.  I'll look it up, I'm curious since I work on the Win32 part of it now.
 247 < mclasen> ebassi: might be good to collect some hints on how to fix the backends...
 248 < ebassi> mclasen: sure
 249 < mclasen> unless they are all fixed already
 250 < mclasen> I guess directfb is the problem child
 251 < ebassi> I think win32 is broken, and surely directfb
 252 < bratsche> I didn't know anything about this, and I usually don't build trunk.
 253 < bratsche> So I'll look into it since I told mclasen I would build trunk to test filechooser anyway.
 254 < ebassi> bratsche: thanks
 255 < mclasen> hpj: what was your question ?
 256 < hpj> so i've been toying with a new GDK backend that renders each toplevel GdkWindow to a respective cairo image surface and leaves further rendering and event generation up to the application
 257 < kris> bratsche: adapting the backend was not harrd for quartz
 258 < hpj> is there any chance of a backend like that making it into GTK proper if i maintain it?
 259 < kris> bratsche: just look at the quartz and X11 change sets
 260 < bratsche> kris: Cool, thanks.
 261 < bratsche> I'll look at this maybe tonight after work if I have time.
 262 < hpj> my use case is applications that want to use windows in a peculiar rendering context
 263 < hpj> like SDL/OpenGL games
 264 < hpj> or anything else you can think of that's not tied to a particular windowing system/device like X11, DirectFB, win32, quartz
 265 < ebassi> hpj: I think this matches some of the OffscreenWindow capabilities
 266 < mclasen> hpj: there was an abstract framebuffer backend in bugzilla at some point
 267 < mclasen> is this similar ?
 268 < hpj> yes, it's similar to offscreen rendering, but handles all application windows and does not depend on a display subsystem
 269 < timj> hpj: can we talk this through at guadec as well? particularly about event processing....
 270 < hpj> i basically resurrected the linuxfb code and took out the device-specific parts, made it render each toplevel to a separate surface and not to a screen surface
 271 < hpj> i have mouse events and rendering (mostly) working
 272 < hpj> (testing using gtk-demo)
 273 < hpj> timj: sure
 274 < hpj> i was just wondering if i should make the effort to get this integrated or if the answer is no right off the bat
 275 < hpj> because of the overlap with offscreen rendering
 276 < timj> hpj: yeah, but that's logic that is replicated in a bunch of backends and offscreen rendering, ideally, we'll have only one implementation of that at some point
 277 < timj> hpj: in general, if a backend has valid use cases, and especially if its well maintained, there's no reason to reject it up front
 278 < mclasen> hpj: we have a bit of bad luck with retaining backend maintainers...linuxfb, directfb,...
 279 < hpj> timj: cool
 280 < timj> the biggest problems we usually have with backends is bad maintenance
 281 < hpj> i think i'd be a reliable maintainer
 282 < hpj> i've been around for a while
 283 < hpj> so i'll pursue it for eventual inclusion, then
 284 < mclasen> sure, noone doubts that :-)
 285 < hpj> backends don't disturb the code much, fortunately
 286 < timj> hpj: sounds good then. ;) added to the guadec talk todo
 287 < hpj> especially a "special needs" one like this one
 288 < mclasen> but I share tims concern that this feels like we should be able to share a lot of the code across backends
 289 < hpj> timj: thanks!
 290 < kris> we should refactor all backend crap in 3.x!!!
 291 < kris> :)
 292 < hpj> yeah, the GDK stuff is a bit hairier than it could be for backend implementors
 293 < kris> a bit???
 294 < hpj> but that's a different project :)
 295 < hpj> heh
 296  * kris would love to get rid of all X11 specific crap
 297 < mclasen> kris: death to subwindows...
 298 < bratsche> Come on, it's FUN!
 299 < kris> and make it much simpler
 300 < bratsche> :)
 301 < kris> mclasen: that too
 302 < hpj> yeah, subwindows make it interesting :)
 303 < ebassi> hehe
 304 < hpj> ok, that's it for my question
 305 < jdahlin> kris: many people has said that, nobody has written a proposal...
 306 < mclasen> I think we are done then ! ebassi ?
 307 < ebassi> done deal :-)
 308 < kris> jdahlin: lemme first finish univeristy, okay? ;)
 309 < jdahlin> kris: always the same excuses.
 310 < kris> jdahlin: tsss
 311 < arc> kris, you'll finish, and then you'll realize that you don't have more spare time
 312 < ebassi> okay, thanks everyone - I'll send the minutes to the list later tonight