1 < mclasen> ebassi: do we have an agenda ?
   2 < ebassi> yes
   3 < thos> It was in ebassi's reminder e-mail
   4 < ebassi> • Composite containers + GtkBuilder patch (tristan)
   5 < ebassi> • GDbus merge status (mclasen, davidz)
   6 < mclasen> thos: I never read those :-)
   7 < ebassi> • Monet (thos)
   8 < ebassi> • Deprecations in the 3.x cycle (jjardon)
   9 < ebassi> I still have to send my email re: GController to gtk-devel-list, though I can discuss the bits here
  10 < ebassi> (it's a trivial point, and it mostly revolves around finding a suitable API design)
  11 < mclasen> let me start with a 2 line status update on 2.90, maybe ?
  12 < danw> i'd like to add a quick "where to add add proxy and tls code for gio" agenda item
  13 < ebassi> right, yes; that was a point I wanted to add after the 2.90 release
  14 < mclasen> danw: sure
  15 < mclasen> so, I've merged the 2.90 branch to master last week, and done 2.21.0 and 2.90.0 releases
  16 < mclasen> 2.90.0 has most things renamed for parallel installability
  17 < mclasen> though I forgot a few small things
  18 < mclasen> next steps on master should be to continue with removing deprecated things (some left in gdk)
  19 < mclasen> and look at merging xi2
  20 < mclasen> that should be enough for 2.91, I guess
  21 < kris> with regard to xi2
  22 < kris> i merged the quartz patches for that into the xi2 branch yesterday
  23  * mclasen update done
  24 < kris> or on Sunday
  25 < kris> I forgot the exact day
  26 < ebassi> so only the basic win32 support is missing from xi2, at this point?
  27 < kris> yes
  28 < mclasen> and the multidevice uncertainty
  29 < kris> but garnacho_ is working on that AFIAK
  30 < jjardon> IMHO It would be good a review of the patch to seal GDK: https://bugzilla.gnome.org/show_bug.cgi?id=592580
  31 < kris> we cannot really move forward with multidevice until the xinput side of things has been figured
  32 < ebassi> jjardon: I promised that :-)
  33 < garnacho_> yes I started on the win32 backend work
  34 < mclasen> kris: yeah, there was brief discussion of merging xi2 without the multidevice stuff for now
  35 < mclasen> I would be thankful for any feedback on the 2.90 snapshot, and the renaming choices I made
  36 < mclasen> ok, so first agenda topic ? composite containers / gtkbuilder 
  37 < tristan> well, I have not been paying much attention to that lately, but... I think its a really interesting move...
  38 < tristan> if its worth peoples time I could try to demystify what I'm trying to accomplish with that patch
  39 < tristan> imo it needs not so much work
  40 < mclasen> tristan: if you could demystify it, that might be good
  41 < tristan> ok, the idea is to let GTK+ classes use GtkBuilder in a way more like Cocoa uses nib files
  42 < mclasen> although Ithink I have a good idea already ('templates')
  43 < tristan> it makes for 2 big benefits
  44 < tristan>   a.) it allows us to write more OO like code, and IMO more defragmented code
  45 < tristan> because writing composite objects forces you to handle UI portions from an object class
  46 < tristan> then b.)
  47 < tristan> is from rad tools, we can take a different approach (one more like adobe flash...)
  48 < tristan> we can allow the user to define an interface completely as a mockup and then...
  49 < tristan> right click on object --> export as Class
  50 < tristan> and write the code to handle the object
  51 < tristan> all code goes on object classes after that
  52 < tristan> the implementation is another detail, explaining that is a bit more in depth 
  53 < mclasen> I assume there is a way to define 'slots' or 'extension points' ?
  54 < tristan> hmmm, well the features also include that composite children explicitly referenced by name become instance variables for free
  55 < tristan> mclasen, my last version of the patch addresses that
  56 < tristan> it allows you to push an instance onto the context of a GtkBuilder parse
  57 < tristan> the builder file for a composite container is built inline as children of the instance
  58 < tristan> so... basically you can implement the add child with a "type" flavour...
  59 < tristan> or just expose a composite child container
  60 < tristan> (which is more easily usable generically)
  61 < tristan> i.e. composite container defines an GtkBox child or such
  62 < tristan> child composite widget is added to that in the file of its parent
  63 < mclasen> tristan: so I guess there is a few questions here
  64 < mclasen> - how much code is this and where does it live ? mostly gtkcontainer.c/gtkbuilder.c ?
  65 < mclasen> - what state is the patch in ? 
  66 < mclasen> - what are the next steps ?
  67 < tristan> right, GtkBuilder takes maybe +- 20 lines, GtkContainer does the work (maybe +- 150 lines for now)
  68 < tristan> the patch needs documentation but works as is, theres one thing I think would be good to do to it though
  69 < tristan> which is, restrict callbacks from the composite builder files to be handled by class methods
  70 < tristan> i.e. for now the patch adds the paramspec type to color a property as a "composite child"
  71 < mclasen> I think I probably need to see some examples of this in action to get a clear picture
  72 < tristan> that can be nice for syntactic sugar from language bindings
  73 < tristan> ... the same would be nice to do for class methods
  74 < tristan> right. If I could pull out a cocoa or flash project that would do it...
  75 < tristan> its become common practice to handle say; a dialog from a GObject with a builder file
  76 < tristan> (when using GtkBuilder)
  77 < tristan> then to use instance variables to handle the more important screen bits
  78 < tristan> and some callbacks handled by the class about that UI
  79 < tristan> making the UI reusable and encapsulated throughout the program
  80 < mclasen> is there any glade integration for this on the horizon ? the description sounded like that would be a big part of the attraction here
  81 < mclasen> tristan: will you have the time to work on this stuff for 3.0 inclusion ?
  82 < tristan> well, what would be the work involved there... and what can we provide from Glade (without anjuta) is 2 things...
  83 < tristan> and Glade I expect will inevidably lag behind GTK+ regardless with the gseal and all
  84 < tristan> some hacks we need to clean up
  85 < tristan> but for the GTK+ portion I could dig up some spare time
  86 < mclasen> yeah
  87 < tristan> what is the schedule exactly ?
  88 < jjardon> For the record, there is a demo code here: https://bugzilla.gnome.org/show_bug.cgi?id=612036#c9
  89 < mclasen> gtk3 should be out for the next gnome release, so septemberish
  90 < tristan> mclasen, lets say that from Glade we can get the recursive project dependancy thing worked out and allow you to create projects from child widgets... and try to do that sensibly... that would be a project in itself
  91 < tristan> and then from an IDE then some language context specific things can be done with instance variable/callback methods
  92 < tristan> for instance the ide could allow a visual way for the user to directly relate an instance var with a composite child
  93  * mclasen wonders if anybody else wants to chime in on this
  94 < ebassi> I honestly have yet to look at the example - though the gtk+ bits are easy to understand
  95 < ebassi> I'm more worried about language bindings integration, and introspection
  96 < tristan> right thats the most important part
  97 < ebassi> but I need to look at it more in depth - sorry, tristan :-(
  98 < thos> ebassi: I imagine it would be used mostly to create objects for applications, i.e. final classes, so bindings and introspection wouldn't be a great deal?
  99 < thos> unless of course, someone then decides to make their application into a library ... :-)
 100 < tristan> thos, well the container class has to let the binding override how signals are connected
 101 < tristan> thats one thing to think of
 102 < mclasen> thos: f this makes it much nicer to create reusable composites in glade, I could see a desire to have them bindable and introspectable
 103 < tristan> and the way its implemented, it *should* allow for cross language derivation
 104 < tristan> i.e. the associated code for the associate class in that language runs to construct the class
 105 < tristan> and yes, composite classes can be extended
 106 < mclasen> so, summary ?
 107 < mclasen> intriguing, but we all need to study it some more ?
 108  * mclasen feels bad for not having done so yet
 109 < tristan> Ive been real busy too no worries
 110 < tristan> well, I can try to dish out another iteration that includes a class vfunc restriction
 111 < tristan> and considers how language bindings will override that code
 112 < ebassi> mclasen: yeah, I think it's the executive summary :-)
 113 < mclasen> ok then
 114 < mclasen> I will make an honest effort to study it before the next meeting
 115 < mclasen> next topic ? gdbus merge status 
 116 < tristan> thanks :)
 117 < mclasen> so, wrt to gdbus, as I said on the list, we have a merge branch now
 118 < ebassi> mclasen: I've seen that davidz has updated the TODO
 119 < mclasen> and getting it in a branch got some people interested/worried enough to give some feedback and try it out
 120 < mclasen> yeah, there is a todo of sorts in gio/gdbusconnection.c
 121 < mclasen> I've sat down with david this morning and looked over what we think is needed
 122 < mclasen> the todo reflects that
 123 < mclasen> there is some internal code cleanup and loose ends, but nothing major
 124 < mclasen> the thing I think is most needed atm is fleshing out the porting guide with enough hints to get people started
 125 < mclasen> and fleshing out the docs in general
 126 < mclasen> david and I plan to get a good chunk of that done tomorrow and thursday
 127 < ebassi> is the merge target still the end of this week?
 128 < mclasen> and target the merge for friday
 129 < mclasen> and then get a snapshot with gdbus out before the weekend
 130  * ebassi will man up and look at the porting guide
 131 < jessevdk> did anything change for the way to specify introspection data for gdbus?
 132 < mclasen> no
 133 < jessevdk> it was something I found quite cumbersome, but maybe it's a detail
 134 < mclasen> I guess that is a topic we need to cover in the migration guide
 135 < ebassi> right now, generating XML is not *too* bad; maybe we should hide the programmatic approach and fix it at a later date?
 136 < mclasen> since we have no codegen, things will look quite a bit different with gdbus
 137 < shaunm> are there concrete plans wrt code generation? (I know davidz mentioned it)
 138 < mclasen> shaunm: I think the answer is: lets land the basics first, and then try various things for codegen
 139 < shaunm> that's fair. just curious if anybody had looked into it yet
 140 < mclasen> davidz older eggdbus code had something, and there is idl stuff, etc
 141 < jessevdk> I'd like to see g-o-i support at some point
 142 < mclasen> if there are no specific concerns about gdbus and merging it, we should probably move on
 143 < mclasen> next topic is more interesting, anyway: monet
 144 < danw> it looks nice from a distance, but from close up it's pretty spotty
 145 < thos> oh right, that's me :-)
 146 < danw> (thank you, thank you, i'll be here all week)
 147 < thos> well, I guess my approach so far has been to try and build something outside of GTK+, to enable other toolkits to work well with it
 148 < thos> hence the seperate repository
 149 < thos> also, it might ease transition
 150 < thos> I've looked at changing GtkStyle straight off, and it envolves an huge amount of work just to get something started
 151 < thos> involves*
 152 < thos> so, first off, I guess it would be good to know whether people agree with this approach
 153 < mclasen> danw: was that an impressionistic joke, or have you actually looked at it ?
 154 < danw> the former. sorry :)
 155 < thos> it's fair to say that there isn't a complete system yet
 156 < mclasen> thos: it is clear that whatever we do in the 3.0 timeframe will have to provide a close equivalent to the gtkstyle api
 157 < mclasen> even if only as a compat wrapper
 158 < thos> mclasen: essentially MnStyle is similar to GtkStyle, but without references to any Gtk+ types
 159 < jjardon> thos, Do you have s smooth porting path, ie, GTK+ 2.22 applications will work with a recompilation?
 160 < thos> mclasen: in the short term, it's possible to create an abstraction layer on top of the existing api
 161 < mclasen> have you tried to use monet in any other toolkits ?
 162 < thos> mclasen: no
 163 < thos> jjardon: currently I have a GTK+ 2.x theme engine as a compatibility layer
 164 < thos> it may involve some hacks in the future though, as new features are introduced
 165 < jjardon> thos, so, any porting guide anywhere? or GTK+ 2.x application will work without any change?
 166 < thos> jjardon: currently they work without change
 167 < thos> if there was no limit on time, I'd propose more radical ideas, such as removing features like style properties and allowing the "theme engine" more control over widget appearances
 168 < leio> GTK3 is an API break, why would it be a requirement to have a close equivalent to ease porting? Theming seems to be the most sore point anyway, logical to need to make radical API changes there
 169 < jjardon> What happen with GtkStyle and GtkRCStyle? (They are not gsealed)
 170 < shaunm> thos: and how would that affect applications that dig into the style for information?
 171 < thos> shaunm: colours should still be accessible
 172 < mclasen> leio: time and resource constraints
 173 < ebassi> leio: the idea is that you can use 2.22 as a trampoline for 3.0
 174 < thos> shaunm: I'm thinking more like properties such as GtkComboBox "appears-as-list"
 175 < leio> but then we are stuck with what is in 3.0. Other than color access, I don't think there's much porting work other than for theme engines?
 176 < leio> (assuming the resource constraints are in porting GNOME3 applications, as keeping compatibility or writing compatibility layer is extra time use)
 177 < thos> I think the main issue is actually the theme-engine api
 178 < mclasen> thos: appears-as-list is clearly a bad one
 179 < thos> mclasen: I think most style properties are concerned with positioning of sub-elements in a widget, and these are the things that cause the most difficulty for third parties to emulate GTK+
 180 < thos> mclasen: if we reduced these and allowed the engine to control position (as is what is required for the win32 engine to work well), it might help reduce complexity inside GTK+
 181 < thos> but again, this is quite a large step, and I'm not sure it can be done in the 3.0 time frame
 182 < thos> the other important thing that Monet does is to move away from the "abstract" drawing API of GtkStyle
 183 < mclasen> thos: how does your work compare to garnachos GtkStyleContext, have you two tried a comparison / synthesis ?
 184 < thos> mclasen: I think GtkStyleContext is a valuable idea in decoupling GTK+ from the widget drawing
 185 < thos> mclasen: the goal beingn to pass information about a widget between the drawing API and the toolkit
 186 < thos> mclasen: personally I think GtkStyleContext is not bound enough (it has the same issues as the detail string in the 
 187               current API), but it's something we can work on
 188  * kris pokes garnacho_ 
 189 < jjardon> thos, Are the points of the theming hackfest still valid? http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00115.html
 190 < thos> jjardon: yes, I think so
 191 < thos> jjardon: there are a few things I would drop from there - CSS, Hit detection
 192 < garnacho_> thos, there's no detail string in GtkStyleContext API, rather a set of classes an element applies to, with further positioning/child information
 193 < thos> garnacho_: yes, I wasn't saying there was a detail string in GtkStyleContext :-)
 194 < thos> garnacho_: my last understanding (maybe outdated), was GtkStyleContext was much like a hash table
 195 < garnacho_> that has evolved a bit, it's essentially an interface to data provided by GtkStyleProviders
 196 < thos> mclasen: I think my main questions would be; how much can we change inside GTK+ for this cycle, and what can we do to future proof what's left
 197 < mclasen> thos: right
 198 < thos> in summary, what I'm trying to do at the moment to get started is create an abstraction above GtkStyle/GtkRcStyle that is a new widget drawing API
 199 < thos> one that has the advantages that we wanted from the theme hackfest last year
 200 < jjardon> thos, As far I can know you can't break the api in 2.x releases, but one application that compiles in the latest 2.x release should compile in GTK+3 . Maybe one exception can be made for the theming stuff if there is'nt another solution
 201 < mclasen> obviously, having something for bug 541136 would help the 'future proof' part
 202 < thos> mclasen: yes
 203 < thos> mclasen: although, I think there is also some stuff we will want to remove as part of that process
 204 < thos> (bg_pixmap for example)
 205 < jjardon> Also 540392
 206 < kris> is bg_pixmap something that should fully go?
 207 < kris> so, that means, we will no longer support custom backgrounds for widgets etc. ?
 208 < thos> kris: I don't really think it works as you might expect
 209 < kris> (I am asking because I am currently starting to review a large patch that (finally) adds bg_pixmap support for tree view)
 210 < thos> ah
 211 < thos> kris: won't most themes just draw over the top anyway?
 212 < kris> tree view will draw over that background already currently
 213 < kris> I still have to figure out how that patch changes it
 214 < thos> I guess one issue that introduces then is the colours exposed by GtkStyle
 215  * mclasen has to go in 10
 216 < thos> currently people get very confused about text/base and bg/fg
 217 < thos> I've seen it used incorrectly so many times
 218 < thos> and some people want more symbolic colours available
 219 < mclasen> thos: there are many unsolvable problems around color pairs
 220 < mclasen> like putting labels in the infobar
 221 < thos> exactly
 222 < mclasen> where you get text (in the label) on top of the symbolic background color of the infobar
 223 < mclasen> and so on
 224 < thos> perhaps it would be useful if there was a proposal for a new set of colours in GtkStyle?
 225 < mclasen> thos: one issue with symbolic colors is that they come individually
 226 < mclasen> not as a per-state array
 227 < mclasen> and not in pairs, except by convention
 228 < thos> mclasen: right, and not as fg/bg pairs
 229 < thos> exactly
 230 < thos> mclasen: I'm happy to work on a proposal for GtkStyle, but anything changing GtkStyle is going to be very invasive
 231 < mclasen> yeah, thats why it has not been tackled yet :-(
 232 < garnacho_> why not using GtkStyleContext as the data source?
 233 < thos> garnacho_: would that replace GtkStyle completely?
 234 < ebassi> garnacho_: that would imply deprecating GtkStyle, or making it "read-only"
 235 < garnacho_> ebassi, I was working towards deprecating it
 236 < leio> with sealing of that struct, it needs to be changed in apps already
 237 < garnacho_> thos, my plan is to make GtkStyle a shallow object on top of GtkStyleContext
 238 < mclasen> garnacho_: that sounds like maybe the most realistic plan for a 3.0 timeframe 
 239 < mclasen> I have only a few minutes left, should we quickly touch the last two topics ?
 240 < ebassi> danw: ?
 241 < ebassi> (proxy and tls code for gio)
 242 < danw> yup
 243 < mclasen> danw: what are the options ?
 244 < danw> so, stormer will have code ready to commit soon, but we have a libproxy dependency for somewhere. likewise, i'm working on the tls code and it will have a gnutls dependency (or an NSS one on some platforms)(
 245 < ebassi> danw: using extension points?
 246 < danw> (a) put it in glib, (b) put it in gvfs, even though they're needed on windows too, (c) create a new module (gnio?)
 247 < danw> ebassi: presumably, unless (a). actually, probably even if (a)
 248 < mclasen> danw: are there any licensing complications ?
 249 < danw> no
 250 < danw> everything is LGPL or easier
 251 < mclasen> then it sounds like using extension points inside gio might be the easiest ?
 252 < mclasen> like we treat file notification already ?
 253 < danw> like file notification, meaning that the implementations of the extension points are also in the glib source tree (and thus glib gains deps on libproxy and tls libs?)
 254 < mclasen> are there any funny cyclic deps ? is libproxy using glib ?
 255 < danw> ah, yes. libproxy has a gnome plugin, that reads proxy settings from gconf (currently. presumably gsettings eventually)
 256 < mclasen> ah, fun
 257 < mclasen> so that might make a separate module more plausible, then
 258 < mclasen> if we make it an extension point, you could also colocate the module with libproxy...
 259 < danw> yeah. and i guess we could deprecate the separate module later if we found a good way to put it in-tree
 260 < leio> I suggest you split libproxy-gnome to a separate package?
 261 < danw> there's also the tls stuff even after figuring out libproxy
 262 < danw> putting the extension point into libproxy is plausible. i don't think they'd want to split out libproxy-gnome from the rest of th esource tree
 263 < leio> (mostly nvm, I confused with libsoup-gnome)
 264 < mclasen> colocating the tls stuff with gnutls/nss is probably less plausible
 265 < danw> actually, putting our extension points into someone else's module might cause problems with release schedules too
 266 < mclasen> I don't strictly object to having either of these live inside gio as conditionally compiled subdirectories
 267 < danw> anyway, don't need an answer today since you've got to run, but soon-ish
 268 < mclasen> I can still split them off in distro packages and contain the dependency that way
 269 < danw> the circular dep with libproxy is awkward though
 270 < mclasen> yeah
 271 < mclasen> anyway, I gotta go
 272 < mclasen> we should figure this out soon, as you say
 273 < mclasen> to land even more cool stuff this cycle
 274 < mclasen> :-)
 275 < mclasen> see you all soon
 276 < mclasen> next meeting in 2 weeks ?
 277 < mclasen> or so 
 278 < ebassi> mclasen: agree
 279 < mclasen> later
 280 < garnacho_> sounds fine to me
 281 < ebassi> there's still one last point from jjardon 
 282 < ebassi> which I think we can discuss - mclasen can read the minutes :-)
 283 < ebassi> deprecations in the 3.x cycle
 284 < jjardon> Yeah, only point to bugs about deprecations, It would be great a review to accept or reject them ASAP so app devels can patch their applications
 285 < jjardon> https://bugzilla.gnome.org/buglist.cgi?status_whiteboard_type=casesubstring;status_whiteboard=deprecations;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO
 286 < ebassi> we touched it briefly last week as well (deprecation of the H|V stuff, GtkTearOffMenu, GtkRuler, etc.)
 287 < ebassi> I think we can go ahead and deprecate GtkTearoffMenu
 288 < ebassi> can't wait for the flames
 289 < jjardon> :)
 290 < ebassi> we discussed about deprecating GtkHSV ages ago, but we never did
 291 < ebassi> same as GtkRuler
 292 < ebassi> or, at least, make GtkHSV a private widget for GtkColorSelection only
 293 < vwduder> also, if anyone would care to look over #50076 for GDateTime, and let me know if its on the right track, i can spend some more cycles on it
 294 < ebassi> vwduder: I think I did a review on #gtk+ a couple of days ago
 295 < ebassi> vwduder: apart from making s/g_date_time_from_time_t/g_date_time_from_epoch/ and using gint64 instead of time_t, there were positive comments
 296 < ebassi> shame that mitch's not here for a comment re: gtkruler and gtkhsv
 297 < ebassi> codesearch says that gtkruler is still used
 298 < jjardon> Maybe more interesting is the deprecation of the H|V stuff, do we agree on deprecate them? (and make base widget not abstract)
 299 < ebassi> but gtkhsv is not
 300 < jjardon> Here the wiki page for the property defaults: http://live.gnome.org/GTK+/PropertyDefaults
 301 < ebassi> jjardon: last week mclasen said that there are some issue in making the Orientable classes non-abstract - esp. for the default values - but he wanted to unblock the situation
 302 < jjardon> Maybe a mail to gtk-devel-list could help?
 303 < ebassi> jjardon: yes, it would help
 304 < ebassi> jjardon: at least, it would bring out people from the woods
 305 < ebassi> jjardon: could you assemble a list of "deprecatable" classes?
 306 < jjardon> ebassi, sure
 307 < ebassi> thanks
 308 < jjardon> I think the bugzilla list is quite complete, If you add the  H|V stuff
 309 < ebassi> yup
 310 < jjardon> and  GtkHSV
 311 < ebassi> okay, I think we can adjourn the meeting
 312 < ebassi> next meeting: same time, in two weeks
 313 < ebassi> thanks for attending, everyone