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
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.