< 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" < alex> I just wanted to talk a bit about what i'm working on with client side windows in gdk < mclasen> are we going to have a timj, or should we go ahead without him ? < rhult> he's not online on jabber so I'm guessing he's not coming < mclasen> ok < mclasen> alex: do you want to give us a quick overview, then ? < alex> Ok. < alex> So, i'm currently working on the third major iteration of the offscreen patch/branch < alex> Its availible at http://git.testbit.eu/Gtk-shallow/log/?h=client-side-windows < alex> The first version was sort of a hack to get offscreen windows going < alex> The second version (offscreen-ng branch at testbit) was a cleanup of that with a slightly new approach < alex> The third version is a more radical restructuring of gdk, inspired by feedback from owen about the offscreen-ng branch < mclasen> in what ways is it more radical ? * behdad listens < 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? < mitch_> being < mitch_> i found that approach pretty well designed < 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 < alex> And it will allow us to radically clean up and simplify the platform backends < behdad> alex: does it make it easier to render to an arbitrary cairo_t? < alex> since a) its pushing a lot of stuff to the common code, and b) we can drop all 32bit coord emulation < behdad> say, take a screenshot to pdf? < mitch_> do you have the link to owen'd mail at hand? < mitch_> owen's < alex> http://mail.gnome.org/archives/gtk-devel-list/2008-November/msg00020.html < mitch_> thanks < alex> So, all GdkWindow objects get functionallity added that tracks the full clip region < alex> and for some windows, GdkWindowObject->impl is the same as the impl of the parent window < mitch_> some as in which exactly? < alex> drawing in such a window will render to that impl, but automatically offsetting and clipping as if emulating an X window < alex> mitch_: same pointer value < mitch_> no what *some* windows, not same :) < alex> ah, yeah < mitch_> you mean as in lightweight subwindows < alex> in the typical case only the toplevel window will have its own native window < mitch_> software only < alex> and everyone else will have the same impl < mitch_> very nice < alex> however, we want to support native windows in the hierarchy < alex> for e.g. gtkplut < alex> gtkplug < 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 < alex> native events are only caught on the toplevel window < alex> all other windows (even native) get synthetic events < alex> update areas are tracked per native window < alex> begin_paint will only allocate one pixmap per native window when processing exposes on multiple client side windows < alex> There is also a new GdkWindow type GDK_WINDOW_OFFSCREEN < alex> Its a different type of window->impl that just renders to a pixmap < mitch_> essentially another backend with the new architecture? < alex> then you emulate child windows of that as normal < alex> this is for clutter integration and putting transformed widgets into a canvas * bratsche reads scrollback < mclasen> how much of what you have described is currently working on your branch ? < ebassi> so, in essence, a clutter actor would just use texture-from-pixmap to paint an offscreen window < ebassi> ? < bratsche> I like the part about cleaning up the gdk backends' code. :) < alex> mitch_: not really, its backed by the real architecture pixmap implementation < mitch_> ok < alex> mitch_: it mainly adds window resize (allocate new pixmap and copy data) and damage tracking when drawing < mitch_> as in adds to the new mighty gdkwindow? < mitch_> because it adds much more to the current code < alex> mitch_: by "it" i was refering to GdkOffscreenWindow < mitch_> ah ok < tristan> is this meeting still going on ? < alex> mclasen: General client side windows work, although i'm tracking down a bug where its not clearing the background when moving windows < tristan> :) < tristan> ah < mclasen> alex: working to the level of running a desktop on it ? < alex> mclasen: i need to port some more stuff from the offscreen-ng branch to make gdk_window_move/scroll/etc to be fast < alex> mclasen: not yet < alex> to the level that testgtk seems to mostly work < alex> However, there is no native child window support yet < ebassi> alex: would this break ABI/API? < mitch_> which of the many branches of the git repo do you consider on the way to be a candidate for merging? < alex> and there are a bunch of small things that need to be implemented < ebassi> alex: or is it safe? < alex> ebassi: Its generally designed to be ABI/API compatible < mitch_> the branch timj and i have been working on seems to be a dead end given all the goodness you just described < alex> however, there are some differences < alex> for instance, you clearly can't get an xid for any gdkwindow < 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. < alex> Then there are some minor things that are hard to emulate with client side windows < mclasen> alex: have you looked at some examples ? I bet 75% of all xid-getting is on toplevels anyway... < alex> for instance the constrain_to argument when grabbing the pointer is not possible to emulate < mitch_> so you would create a native window on the fly for that? and destroy it when no longer needed? < alex> mclasen: examples would be: gtkplug, opengl rendering, Xv < behdad> on-demand sounds promising < alex> mitch_: i don't think we can track when to destroy it < mclasen> alex: when the grab ends ? < mitch_> alex: can't we have some push/pop counter for "native needed", like in the grab example you gave? < mitch_> for just getting the xid we could add new api to release the ID < alex> in some cases maybe < mitch_> or just keep it allocated < alex> and sure, we could add an api to release it < alex> however, i'm not sure its important enought to not just convert them forever < mitch_> it would be cool to have the infrastructure for that anyway < mitch_> hm dunno < alex> in almost all cases i'm sure thats what gonna happen < 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) < mitch_> then gdk would make sure that handle gets never released? < mitch_> oh never use < mitch_> never mind :) < alex> it would just automatically create a native window in gdk_window_new if the attribute is such that emulated windows don't work < alex> (not that this is likely to happen in the post 1993 era) < mitch_> heh < mitch_> to come back to my earlier question, which of the branches do you consider the one to be eventually merged? < mitch_> i suppose your new stuff? < alex> I think the last one < mitch_> 2.16 material? < bratsche> Would it be worthwhile to start syncing Win32 stuff with it yet? < alex> Although its not yet to the state of the other branches its not much work to get it so, mostly lifting things over < bratsche> Or is there anything that needs syncing? < mclasen> do you have some form of roadmap towards merging it ? ie what 'small things' need fixing, etc < ebassi> mitch_: I guess that's the million dollars question :-) < mitch_> and the forbidden question: timeline ;) < mitch_> ebassi: haha yea < ebassi> mitch_: that would be the billion dollars one :-) < alex> But its much more maintainable, and actually cleans up a lot of gdk and moving backend code into the common code. < mclasen> more like 2.90 material, I guess ? < ebassi> mclasen: I'd tend to agree < alex> The other approaches is a lot more "bolted on" and really makes the code much harder to understand < alex> Whats the time scale for 2.16? < mitch_> mclasen: if it's binary compatible, but i think it sounds like that anyway < ebassi> would be a great feature for the 2.90, and would ease off all the non-believers < mitch_> sorry, that last sentence was misunderstandable < mitch_> ebassi: very good point! < ebassi> alex: guadec, so july/august '09 < 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 < ebassi> alex: but consider testing, so the window should close around may < alex> bratsche: maybe early next week < rhult> alex, so next week or so could be a good time to look at it? < alex> rhult: yeah < mitch_> rock :) < alex> i'll send a mail to the list when i consider it worth looking at < 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. < alex> I think it should be doable by may < mclasen> alex: would be great if you could send a status update mail, or put some status/roadmap stuff on the wiki < alex> yeah < alex> I'll send a status update on monday < alex> Also, i have a local file with lots of todos and stuff, i'll push that to the wiki < ebassi> ACTION: send an update on monday to gtk-devel-list (alexl) < ebassi> ACTION: put a roadmap/TODO on the wiki (alexl) < ebassi> alex: cool stuff < mclasen> pretty cool, thanks for the update alex < mitch_> indeed < mclasen> and thanks for doing all that work < mitch_> very much appreciated to make backends sane! < rhult> yes indeed < alex> it helps a lot that it moves a lot of stuff to the common code too < mitch_> yea the duplication was hurting < alex> thus increasing likelyhood that gtk acts the same on different backends < alex> and even allowing new features < mitch_> you can't come to guadec, you will drown in beers < alex> for instance, we could easily do child window shaped windows, which the osx backend doesn't do < alex> anyway, i'll keep on it and post next week < mclasen> do we have any other points to discuss under 'misc' ? < mitch_> yes < mitch_> mclasen: thanks for the property list on the wiki < mitch_> but didn't timj mean all properties, also e.g. GtkWidget ones, like "visible"? < mitch_> i'm not sure i agree on that, but since timj isn't here to raise his point... < mclasen> timj said as much on the list < mitch_> oh i missed that < ebassi> mclasen: not on the list < ebassi> mclasen: at least, it's not in the archives < mclasen> oh, maybe it was private mail < mclasen> yeah, it was a private exchange < mitch_> i must say "visible = TRUE" is so much more sane than FALSE, he has a very good point here ;) < ebassi> indeed < mclasen> but having visible=true in new GtkBox and visible = False in GtkH/VBox will suck < ebassi> in clutter we have show-on-set-parent < mclasen> and we'll have to keep it FALSE in gtkwidget as well < ebassi> which tantamounts to visible=true < mclasen> it just dilutes the reliability of defaults < mclasen> people will not remember and will have to explicitly set the property anyway.... < mitch_> maybe a global, app-settable default would make sense < mitch_> as in set before gtk_init() and never change < mitch_> dunno < mclasen> or tell people to use a ui builder that has the right defaults... < rhult> mitch_, that will break with libraries using gkt < rhult> gtk < mitch_> rhult: apps will figure that < kalikiana> mitch_: But it breaks widgets from libraries < mitch_> dunno, it would just be nice to have some migration path for any kind of default value change < mitch_> kalikiana: apps will also figure that and not set the flag < mitch_> gimp could easily set that flag < kalikiana> mitch_: So it's useless as soon as you need such a library :P < mitch_> so what? < mitch_> there could be a way to port such libraries in whatever way < mclasen> ACTION: add widget properties to live.gnome.org/GTK+/PropertyDefaults < mitch_> that's why i ask for a mogration path for defalt value changes < mclasen> ACTION: finish filling out default value table after a lengthy discussion < mitch_> hehe < kalikiana> mitch_: Maybe a GtkSettings property that libraries can read < tristan> oh, default values will be properly introspectable ? g_param_spec_set_default() in child classes or something ? < tristan> sounds nice < kalikiana> ie. default-visible < mitch_> i have no clue how to acheive it in detail, but keeping insane defaults forever is not really nice < tristan> mitch_, I think currently you have to g_object_class_install_property() over the old one, not so desirable < mitch_> yes i know < mclasen> yeah, the problem with that is duplication of strings, etc < tristan> mclasen, not to mention widget authors will not want to reinstall the whole property, and lazyness will result in the same problem < mclasen> it was briefly discusses when the param spec redirect stuff was introduced < 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 < mclasen> but nothing came out of it... < tristan> properties on interfaces, nod < mclasen> tristan: sure, go ahead < tristan> well, I would like to do something cool with actions, in glade < tristan> and currently, with no means of accessing them... < tristan> actions are only an anomaly of uimanager... from the glade pov < mitch_> a pretty nice anomaly ;) < tristan> so, I do have this little patch up, that is not quite ideal < tristan> mitch_, yes, agreed, I think we need actions :) < tristan> basically for a hacker, he has gtk_action_connect_proxy to work with < tristan> but not a builder user < tristan> so, what I propose for a start, is an accessor property on GtkWidget to set the action that controls the widget < tristan> and an additional attribute < tristan> to control whether your action proxy will get its UI stomped on or not, by gtkaction.c < tristan> the writeup is here: http://bugzilla.gnome.org/show_bug.cgi?id=560228 < tristan> Ideally though, I think that it would be better, if the action proxies had an interface < tristan> that would be responsible for bearing these properties, and updating the appearance of the proxy when appropriate < tristan> i.e. move all that widget casing code out of gtkaction.c, into their proxies < mitch_> yes, action and uimanagerare pretty much hacked up < mitch_> proper virtualization would allow for very powerful generic ui building < 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 < mitch_> also non-glade use cases here < tristan> yes, also non-glade cases, just the fact that you can set proxy appearance to the action or not < mclasen> one problem with making that all generic is that you'll generate a lot of signal handler overhead < tristan> allows you to use them everywhere < mitch_> would this be an opportunity to clean up the action stuff generally? < mclasen> thats why there is the 'widget chasing' in gtkaction, currently < mitch_> like adding a GtkActivatable interface insteaf of special-casing menu items and buttons all over the place < mitch_> and a GtkToggleable interface < mitch_> and a GtkRadio interface < mitch_> *please* :) < tristan> mitch_, thats the interface I would like to propose yes < tristan> mitch_, I suppose they could be different interfaces < tristan> I wonder if they need to < mitch_> didn't i just say that? < tristan> an activatable could be a toggle button, radio button < mitch_> yes < mitch_> menu item < mitch_> dialog < tristan> and menu item, and then depending on its action-controller... < mitch_> and then there would be toggleable on top of that and on top the radio thing < tristan> mitch_, a togglebutton:action would have to be of type GtkToggleAction < mitch_> a GtkToggleable:action i would say < tristan> ah yes ofcourse < mitch_> so the button special casing would be gone < tristan> but, why split GtkToggleable from GtkRadio etc ? < mitch_> because the radio thing needs a list of other radios < tristan> toggle button implements activatable.... and the property needs to be typed correctly < mitch_> it's prerequisite would be implementing the toggle interface < tristan> mmm * mclasen gotta go < mitch_> some how the list of actions need to find the list of controlled proxies < mitch_> and associate them < 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 < mitch_> mclasen: really :( why did that change? < mclasen> as I said: too many damn signal handlers...there are a _lot_ of proxies in an app like the gimp < mitch_> oh yea < mclasen> anyway, need to run < mclasen> later < tristan> later mclasen < tristan> mitch_, I'll look into interfaces with prerequisites and try to fry that in my brain for a bit < mitch_> cool :) < tristan> mitch_, another thing that would be really cool, is see if we cant have a GtkScrollAction < tristan> with adjustments for scale proxies and spin button proxies etc < mitch_> tristan: or a scalar action if that makes sense < tristan> not sure how it would be implemented though < mitch_> oh that's what you mean, cool :) < tristan> :) < kris> did the meeting start at 21 europe time? < kris> I lost track :/ < mitch_> tristan: gimp does an awful lot of generic crap with actions, and we hit the limits all the time < tristan> mitch_, Im trying to figure about the signal overhead, is it really much ? < tristan> and I dont see how it would scale up with this newer approach < tristan> hmmm < mitch_> tristan: one notify handler per proxy should do imho < ebassi> kris: 20:00 utc < ebassi> kris: an hour ago, in short :-) < kris> oh < kris> oops * kris also is not in #gtk+ currently < tristan> mitch_, maybe we can even eliminate it ! if proxies had a hand on the action, they can communicate events directly < kris> too busy with school crap < mitch_> tristan: eek! double eek! < mitch_> tristan: please not :( < tristan> lol < tristan> ok < mitch_> ;) < 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 < tristan> like scalar actions etc < mitch_> cool, thanks < tristan> thank you for listening ! :D < ebassi> okay, can we close the meeting or do we have new points? < mitch_> my point joke is used up now, so no < ebassi> thank the gods! < ebassi> :-P < ebassi> okay, the minutes will be sent to the list as usual