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