1 < ebassi> so, I guess we'll have a new agenda for the meeting - since alex wants to join and the only point on the wiki is "miscellaneous" 2 < alex> I just wanted to talk a bit about what i'm working on with client side windows in gdk 3 < mclasen> are we going to have a timj, or should we go ahead without him ? 4 < rhult> he's not online on jabber so I'm guessing he's not coming 5 < mclasen> ok 6 < mclasen> alex: do you want to give us a quick overview, then ? 7 < alex> Ok. 8 < alex> So, i'm currently working on the third major iteration of the offscreen patch/branch 9 < alex> Its availible at http://git.testbit.eu/Gtk-shallow/log/?h=client-side-windows 10 < alex> The first version was sort of a hack to get offscreen windows going 11 < alex> The second version (offscreen-ng branch at testbit) was a cleanup of that with a slightly new approach 12 < alex> The third version is a more radical restructuring of gdk, inspired by feedback from owen about the offscreen-ng branch 13 < mclasen> in what ways is it more radical ? 14 * behdad listens 15 < mitch_> so you are going for what owen said, namely every GdkWindow being able to do everything in software, and the impl begin the only backend thing? 16 < mitch_> being 17 < mitch_> i found that approach pretty well designed 18 < alex> Its more radical in the sense that it changes how things work a lot, even if you're not actually using client side windows 19 < alex> And it will allow us to radically clean up and simplify the platform backends 20 < behdad> alex: does it make it easier to render to an arbitrary cairo_t? 21 < alex> since a) its pushing a lot of stuff to the common code, and b) we can drop all 32bit coord emulation 22 < behdad> say, take a screenshot to pdf? 23 < mitch_> do you have the link to owen'd mail at hand? 24 < mitch_> owen's 25 < alex> http://mail.gnome.org/archives/gtk-devel-list/2008-November/msg00020.html 26 < mitch_> thanks 27 < alex> So, all GdkWindow objects get functionallity added that tracks the full clip region 28 < alex> and for some windows, GdkWindowObject->impl is the same as the impl of the parent window 29 < mitch_> some as in which exactly? 30 < alex> drawing in such a window will render to that impl, but automatically offsetting and clipping as if emulating an X window 31 < alex> mitch_: same pointer value 32 < mitch_> no what *some* windows, not same :) 33 < alex> ah, yeah 34 < mitch_> you mean as in lightweight subwindows 35 < alex> in the typical case only the toplevel window will have its own native window 36 < mitch_> software only 37 < alex> and everyone else will have the same impl 38 < mitch_> very nice 39 < alex> however, we want to support native windows in the hierarchy 40 < alex> for e.g. gtkplut 41 < alex> gtkplug 42 < alex> those are supported by creating a native window, as a child of the parent native window, and then using the shaped window extension to make it clip to the other emulated windows 43 < alex> native events are only caught on the toplevel window 44 < alex> all other windows (even native) get synthetic events 45 < alex> update areas are tracked per native window 46 < alex> begin_paint will only allocate one pixmap per native window when processing exposes on multiple client side windows 47 < alex> There is also a new GdkWindow type GDK_WINDOW_OFFSCREEN 48 < alex> Its a different type of window->impl that just renders to a pixmap 49 < mitch_> essentially another backend with the new architecture? 50 < alex> then you emulate child windows of that as normal 51 < alex> this is for clutter integration and putting transformed widgets into a canvas 52 * bratsche reads scrollback 53 < mclasen> how much of what you have described is currently working on your branch ? 54 < ebassi> so, in essence, a clutter actor would just use texture-from-pixmap to paint an offscreen window 55 < ebassi> ? 56 < bratsche> I like the part about cleaning up the gdk backends' code. :) 57 < alex> mitch_: not really, its backed by the real architecture pixmap implementation 58 < mitch_> ok 59 < alex> mitch_: it mainly adds window resize (allocate new pixmap and copy data) and damage tracking when drawing 60 < mitch_> as in adds to the new mighty gdkwindow? 61 < mitch_> because it adds much more to the current code 62 < alex> mitch_: by "it" i was refering to GdkOffscreenWindow 63 < mitch_> ah ok 64 < tristan> is this meeting still going on ? 65 < alex> mclasen: General client side windows work, although i'm tracking down a bug where its not clearing the background when moving windows 66 < tristan> :) 67 < tristan> ah 68 < mclasen> alex: working to the level of running a desktop on it ? 69 < alex> mclasen: i need to port some more stuff from the offscreen-ng branch to make gdk_window_move/scroll/etc to be fast 70 < alex> mclasen: not yet 71 < alex> to the level that testgtk seems to mostly work 72 < alex> However, there is no native child window support yet 73 < ebassi> alex: would this break ABI/API? 74 < mitch_> which of the many branches of the git repo do you consider on the way to be a candidate for merging? 75 < alex> and there are a bunch of small things that need to be implemented 76 < ebassi> alex: or is it safe? 77 < alex> ebassi: Its generally designed to be ABI/API compatible 78 < mitch_> the branch timj and i have been working on seems to be a dead end given all the goodness you just described 79 < alex> however, there are some differences 80 < alex> for instance, you clearly can't get an xid for any gdkwindow 81 < alex> so, we need to consider how to decide what windows to make native. I'm considering on-demand creating native windows when you request the xid, and it might be doable. 82 < alex> Then there are some minor things that are hard to emulate with client side windows 83 < mclasen> alex: have you looked at some examples ? I bet 75% of all xid-getting is on toplevels anyway... 84 < alex> for instance the constrain_to argument when grabbing the pointer is not possible to emulate 85 < mitch_> so you would create a native window on the fly for that? and destroy it when no longer needed? 86 < alex> mclasen: examples would be: gtkplug, opengl rendering, Xv 87 < behdad> on-demand sounds promising 88 < alex> mitch_: i don't think we can track when to destroy it 89 < mclasen> alex: when the grab ends ? 90 < mitch_> alex: can't we have some push/pop counter for "native needed", like in the grab example you gave? 91 < mitch_> for just getting the xid we could add new api to release the ID 92 < alex> in some cases maybe 93 < mitch_> or just keep it allocated 94 < alex> and sure, we could add an api to release it 95 < alex> however, i'm not sure its important enought to not just convert them forever 96 < mitch_> it would be cool to have the infrastructure for that anyway 97 < mitch_> hm dunno 98 < alex> in almost all cases i'm sure thats what gonna happen 99 < alex> also, there are some cases where we can never use client side windows, like if you're using a different visual in a child window (different bit dept, different palette, or other old-school x crap) 100 < mitch_> then gdk would make sure that handle gets never released? 101 < mitch_> oh never use 102 < mitch_> never mind :) 103 < alex> it would just automatically create a native window in gdk_window_new if the attribute is such that emulated windows don't work 104 < alex> (not that this is likely to happen in the post 1993 era) 105 < mitch_> heh 106 < mitch_> to come back to my earlier question, which of the branches do you consider the one to be eventually merged? 107 < mitch_> i suppose your new stuff? 108 < alex> I think the last one 109 < mitch_> 2.16 material? 110 < bratsche> Would it be worthwhile to start syncing Win32 stuff with it yet? 111 < alex> Although its not yet to the state of the other branches its not much work to get it so, mostly lifting things over 112 < bratsche> Or is there anything that needs syncing? 113 < mclasen> do you have some form of roadmap towards merging it ? ie what 'small things' need fixing, etc 114 < ebassi> mitch_: I guess that's the million dollars question :-) 115 < mitch_> and the forbidden question: timeline ;) 116 < mitch_> ebassi: haha yea 117 < ebassi> mitch_: that would be the billion dollars one :-) 118 < alex> But its much more maintainable, and actually cleans up a lot of gdk and moving backend code into the common code. 119 < mclasen> more like 2.90 material, I guess ? 120 < ebassi> mclasen: I'd tend to agree 121 < alex> The other approaches is a lot more "bolted on" and really makes the code much harder to understand 122 < alex> Whats the time scale for 2.16? 123 < mitch_> mclasen: if it's binary compatible, but i think it sounds like that anyway 124 < ebassi> would be a great feature for the 2.90, and would ease off all the non-believers 125 < mitch_> sorry, that last sentence was misunderstandable 126 < mitch_> ebassi: very good point! 127 < ebassi> alex: guadec, so july/august '09 128 < alex> bratsche: I would like the other platform maintainers to look at it soon, but i want to get a few more things ported over first 129 < ebassi> alex: but consider testing, so the window should close around may 130 < alex> bratsche: maybe early next week 131 < rhult> alex, so next week or so could be a good time to look at it? 132 < alex> rhult: yeah 133 < mitch_> rock :) 134 < alex> i'll send a mail to the list when i consider it worth looking at 135 < bratsche> alex: Okay, fair enough. I'm going to pull the branch down and start looking at it soon. My big project at work is slowing down after this week so I can try to find time to work on the Win32 part of this if that would be helpful. 136 < alex> I think it should be doable by may 137 < mclasen> alex: would be great if you could send a status update mail, or put some status/roadmap stuff on the wiki 138 < alex> yeah 139 < alex> I'll send a status update on monday 140 < alex> Also, i have a local file with lots of todos and stuff, i'll push that to the wiki 141 < ebassi> ACTION: send an update on monday to gtk-devel-list (alexl) 142 < ebassi> ACTION: put a roadmap/TODO on the wiki (alexl) 143 < ebassi> alex: cool stuff 144 < mclasen> pretty cool, thanks for the update alex 145 < mitch_> indeed 146 < mclasen> and thanks for doing all that work 147 < mitch_> very much appreciated to make backends sane! 148 < rhult> yes indeed 149 < alex> it helps a lot that it moves a lot of stuff to the common code too 150 < mitch_> yea the duplication was hurting 151 < alex> thus increasing likelyhood that gtk acts the same on different backends 152 < alex> and even allowing new features 153 < mitch_> you can't come to guadec, you will drown in beers 154 < alex> for instance, we could easily do child window shaped windows, which the osx backend doesn't do 155 < alex> anyway, i'll keep on it and post next week 156 < mclasen> do we have any other points to discuss under 'misc' ? 157 < mitch_> yes 158 < mitch_> mclasen: thanks for the property list on the wiki 159 < mitch_> but didn't timj mean all properties, also e.g. GtkWidget ones, like "visible"? 160 < mitch_> i'm not sure i agree on that, but since timj isn't here to raise his point... 161 < mclasen> timj said as much on the list 162 < mitch_> oh i missed that 163 < ebassi> mclasen: not on the list 164 < ebassi> mclasen: at least, it's not in the archives 165 < mclasen> oh, maybe it was private mail 166 < mclasen> yeah, it was a private exchange 167 < mitch_> i must say "visible = TRUE" is so much more sane than FALSE, he has a very good point here ;) 168 < ebassi> indeed 169 < mclasen> but having visible=true in new GtkBox and visible = False in GtkH/VBox will suck 170 < ebassi> in clutter we have show-on-set-parent 171 < mclasen> and we'll have to keep it FALSE in gtkwidget as well 172 < ebassi> which tantamounts to visible=true 173 < mclasen> it just dilutes the reliability of defaults 174 < mclasen> people will not remember and will have to explicitly set the property anyway.... 175 < mitch_> maybe a global, app-settable default would make sense 176 < mitch_> as in set before gtk_init() and never change 177 < mitch_> dunno 178 < mclasen> or tell people to use a ui builder that has the right defaults... 179 < rhult> mitch_, that will break with libraries using gkt 180 < rhult> gtk 181 < mitch_> rhult: apps will figure that 182 < kalikiana> mitch_: But it breaks widgets from libraries 183 < mitch_> dunno, it would just be nice to have some migration path for any kind of default value change 184 < mitch_> kalikiana: apps will also figure that and not set the flag 185 < mitch_> gimp could easily set that flag 186 < kalikiana> mitch_: So it's useless as soon as you need such a library :P 187 < mitch_> so what? 188 < mitch_> there could be a way to port such libraries in whatever way 189 < mclasen> ACTION: add widget properties to live.gnome.org/GTK+/PropertyDefaults 190 < mitch_> that's why i ask for a mogration path for defalt value changes 191 < mclasen> ACTION: finish filling out default value table after a lengthy discussion 192 < mitch_> hehe 193 < kalikiana> mitch_: Maybe a GtkSettings property that libraries can read 194 < tristan> oh, default values will be properly introspectable ? g_param_spec_set_default() in child classes or something ? 195 < tristan> sounds nice 196 < kalikiana> ie. default-visible 197 < mitch_> i have no clue how to acheive it in detail, but keeping insane defaults forever is not really nice 198 < tristan> mitch_, I think currently you have to g_object_class_install_property() over the old one, not so desirable 199 < mitch_> yes i know 200 < mclasen> yeah, the problem with that is duplication of strings, etc 201 < tristan> mclasen, not to mention widget authors will not want to reinstall the whole property, and lazyness will result in the same problem 202 < mclasen> it was briefly discusses when the param spec redirect stuff was introduced 203 < tristan> if you guys are more or less done... I would like to raise a point of my own if there is still some time 204 < mclasen> but nothing came out of it... 205 < tristan> properties on interfaces, nod 206 < mclasen> tristan: sure, go ahead 207 < tristan> well, I would like to do something cool with actions, in glade 208 < tristan> and currently, with no means of accessing them... 209 < tristan> actions are only an anomaly of uimanager... from the glade pov 210 < mitch_> a pretty nice anomaly ;) 211 < tristan> so, I do have this little patch up, that is not quite ideal 212 < tristan> mitch_, yes, agreed, I think we need actions :) 213 < tristan> basically for a hacker, he has gtk_action_connect_proxy to work with 214 < tristan> but not a builder user 215 < tristan> so, what I propose for a start, is an accessor property on GtkWidget to set the action that controls the widget 216 < tristan> and an additional attribute 217 < tristan> to control whether your action proxy will get its UI stomped on or not, by gtkaction.c 218 < tristan> the writeup is here: http://bugzilla.gnome.org/show_bug.cgi?id=560228 219 < tristan> Ideally though, I think that it would be better, if the action proxies had an interface 220 < tristan> that would be responsible for bearing these properties, and updating the appearance of the proxy when appropriate 221 < tristan> i.e. move all that widget casing code out of gtkaction.c, into their proxies 222 < mitch_> yes, action and uimanagerare pretty much hacked up 223 < mitch_> proper virtualization would allow for very powerful generic ui building 224 < tristan> I could hack up such a patch that does the interface thing, based on my other patch, in a day or two... if thats interesting 225 < mitch_> also non-glade use cases here 226 < tristan> yes, also non-glade cases, just the fact that you can set proxy appearance to the action or not 227 < mclasen> one problem with making that all generic is that you'll generate a lot of signal handler overhead 228 < tristan> allows you to use them everywhere 229 < mitch_> would this be an opportunity to clean up the action stuff generally? 230 < mclasen> thats why there is the 'widget chasing' in gtkaction, currently 231 < mitch_> like adding a GtkActivatable interface insteaf of special-casing menu items and buttons all over the place 232 < mitch_> and a GtkToggleable interface 233 < mitch_> and a GtkRadio interface 234 < mitch_> *please* :) 235 < tristan> mitch_, thats the interface I would like to propose yes 236 < tristan> mitch_, I suppose they could be different interfaces 237 < tristan> I wonder if they need to 238 < mitch_> didn't i just say that? 239 < tristan> an activatable could be a toggle button, radio button 240 < mitch_> yes 241 < mitch_> menu item 242 < mitch_> dialog 243 < tristan> and menu item, and then depending on its action-controller... 244 < mitch_> and then there would be toggleable on top of that and on top the radio thing 245 < tristan> mitch_, a togglebutton:action would have to be of type GtkToggleAction 246 < mitch_> a GtkToggleable:action i would say 247 < tristan> ah yes ofcourse 248 < mitch_> so the button special casing would be gone 249 < tristan> but, why split GtkToggleable from GtkRadio etc ? 250 < mitch_> because the radio thing needs a list of other radios 251 < tristan> toggle button implements activatable.... and the property needs to be typed correctly 252 < mitch_> it's prerequisite would be implementing the toggle interface 253 < tristan> mmm 254 * mclasen gotta go 255 < mitch_> some how the list of actions need to find the list of controlled proxies 256 < mitch_> and associate them 257 < mclasen> just one thing to point out before I go: early revisions of the action code were much more generic, doing most things in property notify handlers 258 < mitch_> mclasen: really :( why did that change? 259 < mclasen> as I said: too many damn signal handlers...there are a _lot_ of proxies in an app like the gimp 260 < mitch_> oh yea 261 < mclasen> anyway, need to run 262 < mclasen> later 263 < tristan> later mclasen 264 < tristan> mitch_, I'll look into interfaces with prerequisites and try to fry that in my brain for a bit 265 < mitch_> cool :) 266 < tristan> mitch_, another thing that would be really cool, is see if we cant have a GtkScrollAction 267 < tristan> with adjustments for scale proxies and spin button proxies etc 268 < mitch_> tristan: or a scalar action if that makes sense 269 < tristan> not sure how it would be implemented though 270 < mitch_> oh that's what you mean, cool :) 271 < tristan> :) 272 < kris> did the meeting start at 21 europe time? 273 < kris> I lost track :/ 274 < mitch_> tristan: gimp does an awful lot of generic crap with actions, and we hit the limits all the time 275 < tristan> mitch_, Im trying to figure about the signal overhead, is it really much ? 276 < tristan> and I dont see how it would scale up with this newer approach 277 < tristan> hmmm 278 < mitch_> tristan: one notify handler per proxy should do imho 279 < ebassi> kris: 20:00 utc 280 < ebassi> kris: an hour ago, in short :-) 281 < kris> oh 282 < kris> oops 283 * kris also is not in #gtk+ currently 284 < tristan> mitch_, maybe we can even eliminate it ! if proxies had a hand on the action, they can communicate events directly 285 < kris> too busy with school crap 286 < mitch_> tristan: eek! double eek! 287 < mitch_> tristan: please not :( 288 < tristan> lol 289 < tristan> ok 290 < mitch_> ;) 291 < tristan> mitch_, ok I'll see what I can write up, I'll aim simple and try to get it working without any new additions 292 < tristan> like scalar actions etc 293 < mitch_> cool, thanks 294 < tristan> thank you for listening ! :D 295 < ebassi> okay, can we close the meeting or do we have new points? 296 < mitch_> my point joke is used up now, so no 297 < ebassi> thank the gods! 298 < ebassi> :-P 299 < ebassi> okay, the minutes will be sent to the list as usual
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.