< mclasen> ebassi: do we have an agenda ? < ebassi> yes < thos> It was in ebassi's reminder e-mail < ebassi> • Composite containers + GtkBuilder patch (tristan) < ebassi> • GDbus merge status (mclasen, davidz) < mclasen> thos: I never read those :-) < ebassi> • Monet (thos) < ebassi> • Deprecations in the 3.x cycle (jjardon) < ebassi> I still have to send my email re: GController to gtk-devel-list, though I can discuss the bits here < ebassi> (it's a trivial point, and it mostly revolves around finding a suitable API design) < mclasen> let me start with a 2 line status update on 2.90, maybe ? < danw> i'd like to add a quick "where to add add proxy and tls code for gio" agenda item < ebassi> right, yes; that was a point I wanted to add after the 2.90 release < mclasen> danw: sure < mclasen> so, I've merged the 2.90 branch to master last week, and done 2.21.0 and 2.90.0 releases < mclasen> 2.90.0 has most things renamed for parallel installability < mclasen> though I forgot a few small things < mclasen> next steps on master should be to continue with removing deprecated things (some left in gdk) < mclasen> and look at merging xi2 < mclasen> that should be enough for 2.91, I guess < kris> with regard to xi2 < kris> i merged the quartz patches for that into the xi2 branch yesterday * mclasen update done < kris> or on Sunday < kris> I forgot the exact day < ebassi> so only the basic win32 support is missing from xi2, at this point? < kris> yes < mclasen> and the multidevice uncertainty < kris> but garnacho_ is working on that AFIAK < jjardon> IMHO It would be good a review of the patch to seal GDK: https://bugzilla.gnome.org/show_bug.cgi?id=592580 < kris> we cannot really move forward with multidevice until the xinput side of things has been figured < ebassi> jjardon: I promised that :-) < garnacho_> yes I started on the win32 backend work < mclasen> kris: yeah, there was brief discussion of merging xi2 without the multidevice stuff for now < mclasen> I would be thankful for any feedback on the 2.90 snapshot, and the renaming choices I made < mclasen> ok, so first agenda topic ? composite containers / gtkbuilder < tristan> well, I have not been paying much attention to that lately, but... I think its a really interesting move... < tristan> if its worth peoples time I could try to demystify what I'm trying to accomplish with that patch < tristan> imo it needs not so much work < mclasen> tristan: if you could demystify it, that might be good < tristan> ok, the idea is to let GTK+ classes use GtkBuilder in a way more like Cocoa uses nib files < mclasen> although Ithink I have a good idea already ('templates') < tristan> it makes for 2 big benefits < tristan> a.) it allows us to write more OO like code, and IMO more defragmented code < tristan> because writing composite objects forces you to handle UI portions from an object class < tristan> then b.) < tristan> is from rad tools, we can take a different approach (one more like adobe flash...) < tristan> we can allow the user to define an interface completely as a mockup and then... < tristan> right click on object --> export as Class < tristan> and write the code to handle the object < tristan> all code goes on object classes after that < tristan> the implementation is another detail, explaining that is a bit more in depth < mclasen> I assume there is a way to define 'slots' or 'extension points' ? < tristan> hmmm, well the features also include that composite children explicitly referenced by name become instance variables for free < tristan> mclasen, my last version of the patch addresses that < tristan> it allows you to push an instance onto the context of a GtkBuilder parse < tristan> the builder file for a composite container is built inline as children of the instance < tristan> so... basically you can implement the add child with a "type" flavour... < tristan> or just expose a composite child container < tristan> (which is more easily usable generically) < tristan> i.e. composite container defines an GtkBox child or such < tristan> child composite widget is added to that in the file of its parent < mclasen> tristan: so I guess there is a few questions here < mclasen> - how much code is this and where does it live ? mostly gtkcontainer.c/gtkbuilder.c ? < mclasen> - what state is the patch in ? < mclasen> - what are the next steps ? < tristan> right, GtkBuilder takes maybe +- 20 lines, GtkContainer does the work (maybe +- 150 lines for now) < tristan> the patch needs documentation but works as is, theres one thing I think would be good to do to it though < tristan> which is, restrict callbacks from the composite builder files to be handled by class methods < tristan> i.e. for now the patch adds the paramspec type to color a property as a "composite child" < mclasen> I think I probably need to see some examples of this in action to get a clear picture < tristan> that can be nice for syntactic sugar from language bindings < tristan> ... the same would be nice to do for class methods < tristan> right. If I could pull out a cocoa or flash project that would do it... < tristan> its become common practice to handle say; a dialog from a GObject with a builder file < tristan> (when using GtkBuilder) < tristan> then to use instance variables to handle the more important screen bits < tristan> and some callbacks handled by the class about that UI < tristan> making the UI reusable and encapsulated throughout the program < 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 < mclasen> tristan: will you have the time to work on this stuff for 3.0 inclusion ? < tristan> well, what would be the work involved there... and what can we provide from Glade (without anjuta) is 2 things... < tristan> and Glade I expect will inevidably lag behind GTK+ regardless with the gseal and all < tristan> some hacks we need to clean up < tristan> but for the GTK+ portion I could dig up some spare time < mclasen> yeah < tristan> what is the schedule exactly ? < jjardon> For the record, there is a demo code here: https://bugzilla.gnome.org/show_bug.cgi?id=612036#c9 < mclasen> gtk3 should be out for the next gnome release, so septemberish < 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 < tristan> and then from an IDE then some language context specific things can be done with instance variable/callback methods < tristan> for instance the ide could allow a visual way for the user to directly relate an instance var with a composite child * mclasen wonders if anybody else wants to chime in on this < ebassi> I honestly have yet to look at the example - though the gtk+ bits are easy to understand < ebassi> I'm more worried about language bindings integration, and introspection < tristan> right thats the most important part < ebassi> but I need to look at it more in depth - sorry, tristan :-( < 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? < thos> unless of course, someone then decides to make their application into a library ... :-) < tristan> thos, well the container class has to let the binding override how signals are connected < tristan> thats one thing to think of < 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 < tristan> and the way its implemented, it *should* allow for cross language derivation < tristan> i.e. the associated code for the associate class in that language runs to construct the class < tristan> and yes, composite classes can be extended < mclasen> so, summary ? < mclasen> intriguing, but we all need to study it some more ? * mclasen feels bad for not having done so yet < tristan> Ive been real busy too no worries < tristan> well, I can try to dish out another iteration that includes a class vfunc restriction < tristan> and considers how language bindings will override that code < ebassi> mclasen: yeah, I think it's the executive summary :-) < mclasen> ok then < mclasen> I will make an honest effort to study it before the next meeting < mclasen> next topic ? gdbus merge status < tristan> thanks :) < mclasen> so, wrt to gdbus, as I said on the list, we have a merge branch now < ebassi> mclasen: I've seen that davidz has updated the TODO < mclasen> and getting it in a branch got some people interested/worried enough to give some feedback and try it out < mclasen> yeah, there is a todo of sorts in gio/gdbusconnection.c < mclasen> I've sat down with david this morning and looked over what we think is needed < mclasen> the todo reflects that < mclasen> there is some internal code cleanup and loose ends, but nothing major < mclasen> the thing I think is most needed atm is fleshing out the porting guide with enough hints to get people started < mclasen> and fleshing out the docs in general < mclasen> david and I plan to get a good chunk of that done tomorrow and thursday < ebassi> is the merge target still the end of this week? < mclasen> and target the merge for friday < mclasen> and then get a snapshot with gdbus out before the weekend * ebassi will man up and look at the porting guide < jessevdk> did anything change for the way to specify introspection data for gdbus? < mclasen> no < jessevdk> it was something I found quite cumbersome, but maybe it's a detail < mclasen> I guess that is a topic we need to cover in the migration guide < ebassi> right now, generating XML is not *too* bad; maybe we should hide the programmatic approach and fix it at a later date? < mclasen> since we have no codegen, things will look quite a bit different with gdbus < shaunm> are there concrete plans wrt code generation? (I know davidz mentioned it) < mclasen> shaunm: I think the answer is: lets land the basics first, and then try various things for codegen < shaunm> that's fair. just curious if anybody had looked into it yet < mclasen> davidz older eggdbus code had something, and there is idl stuff, etc < jessevdk> I'd like to see g-o-i support at some point < mclasen> if there are no specific concerns about gdbus and merging it, we should probably move on < mclasen> next topic is more interesting, anyway: monet < danw> it looks nice from a distance, but from close up it's pretty spotty < thos> oh right, that's me :-) < danw> (thank you, thank you, i'll be here all week) < 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 < thos> hence the seperate repository < thos> also, it might ease transition < thos> I've looked at changing GtkStyle straight off, and it envolves an huge amount of work just to get something started < thos> involves* < thos> so, first off, I guess it would be good to know whether people agree with this approach < mclasen> danw: was that an impressionistic joke, or have you actually looked at it ? < danw> the former. sorry :) < thos> it's fair to say that there isn't a complete system yet < 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 < mclasen> even if only as a compat wrapper < thos> mclasen: essentially MnStyle is similar to GtkStyle, but without references to any Gtk+ types < jjardon> thos, Do you have s smooth porting path, ie, GTK+ 2.22 applications will work with a recompilation? < thos> mclasen: in the short term, it's possible to create an abstraction layer on top of the existing api < mclasen> have you tried to use monet in any other toolkits ? < thos> mclasen: no < thos> jjardon: currently I have a GTK+ 2.x theme engine as a compatibility layer < thos> it may involve some hacks in the future though, as new features are introduced < jjardon> thos, so, any porting guide anywhere? or GTK+ 2.x application will work without any change? < thos> jjardon: currently they work without change < 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 < 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 < jjardon> What happen with GtkStyle and GtkRCStyle? (They are not gsealed) < shaunm> thos: and how would that affect applications that dig into the style for information? < thos> shaunm: colours should still be accessible < mclasen> leio: time and resource constraints < ebassi> leio: the idea is that you can use 2.22 as a trampoline for 3.0 < thos> shaunm: I'm thinking more like properties such as GtkComboBox "appears-as-list" < 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? < leio> (assuming the resource constraints are in porting GNOME3 applications, as keeping compatibility or writing compatibility layer is extra time use) < thos> I think the main issue is actually the theme-engine api < mclasen> thos: appears-as-list is clearly a bad one < 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+ < 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+ < thos> but again, this is quite a large step, and I'm not sure it can be done in the 3.0 time frame < thos> the other important thing that Monet does is to move away from the "abstract" drawing API of GtkStyle < mclasen> thos: how does your work compare to garnachos GtkStyleContext, have you two tried a comparison / synthesis ? < thos> mclasen: I think GtkStyleContext is a valuable idea in decoupling GTK+ from the widget drawing < thos> mclasen: the goal beingn to pass information about a widget between the drawing API and the toolkit < thos> mclasen: personally I think GtkStyleContext is not bound enough (it has the same issues as the detail string in the current API), but it's something we can work on * kris pokes garnacho_ < jjardon> thos, Are the points of the theming hackfest still valid? http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00115.html < thos> jjardon: yes, I think so < thos> jjardon: there are a few things I would drop from there - CSS, Hit detection < garnacho_> thos, there's no detail string in GtkStyleContext API, rather a set of classes an element applies to, with further positioning/child information < thos> garnacho_: yes, I wasn't saying there was a detail string in GtkStyleContext :-) < thos> garnacho_: my last understanding (maybe outdated), was GtkStyleContext was much like a hash table < garnacho_> that has evolved a bit, it's essentially an interface to data provided by GtkStyleProviders < 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 < mclasen> thos: right < 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 < thos> one that has the advantages that we wanted from the theme hackfest last year < 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 < mclasen> obviously, having something for bug 541136 would help the 'future proof' part < thos> mclasen: yes < thos> mclasen: although, I think there is also some stuff we will want to remove as part of that process < thos> (bg_pixmap for example) < jjardon> Also 540392 < kris> is bg_pixmap something that should fully go? < kris> so, that means, we will no longer support custom backgrounds for widgets etc. ? < thos> kris: I don't really think it works as you might expect < kris> (I am asking because I am currently starting to review a large patch that (finally) adds bg_pixmap support for tree view) < thos> ah < thos> kris: won't most themes just draw over the top anyway? < kris> tree view will draw over that background already currently < kris> I still have to figure out how that patch changes it < thos> I guess one issue that introduces then is the colours exposed by GtkStyle * mclasen has to go in 10 < thos> currently people get very confused about text/base and bg/fg < thos> I've seen it used incorrectly so many times < thos> and some people want more symbolic colours available < mclasen> thos: there are many unsolvable problems around color pairs < mclasen> like putting labels in the infobar < thos> exactly < mclasen> where you get text (in the label) on top of the symbolic background color of the infobar < mclasen> and so on < thos> perhaps it would be useful if there was a proposal for a new set of colours in GtkStyle? < mclasen> thos: one issue with symbolic colors is that they come individually < mclasen> not as a per-state array < mclasen> and not in pairs, except by convention < thos> mclasen: right, and not as fg/bg pairs < thos> exactly < thos> mclasen: I'm happy to work on a proposal for GtkStyle, but anything changing GtkStyle is going to be very invasive < mclasen> yeah, thats why it has not been tackled yet :-( < garnacho_> why not using GtkStyleContext as the data source? < thos> garnacho_: would that replace GtkStyle completely? < ebassi> garnacho_: that would imply deprecating GtkStyle, or making it "read-only" < garnacho_> ebassi, I was working towards deprecating it < leio> with sealing of that struct, it needs to be changed in apps already < garnacho_> thos, my plan is to make GtkStyle a shallow object on top of GtkStyleContext < mclasen> garnacho_: that sounds like maybe the most realistic plan for a 3.0 timeframe < mclasen> I have only a few minutes left, should we quickly touch the last two topics ? < ebassi> danw: ? < ebassi> (proxy and tls code for gio) < danw> yup < mclasen> danw: what are the options ? < 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)( < ebassi> danw: using extension points? < 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?) < danw> ebassi: presumably, unless (a). actually, probably even if (a) < mclasen> danw: are there any licensing complications ? < danw> no < danw> everything is LGPL or easier < mclasen> then it sounds like using extension points inside gio might be the easiest ? < mclasen> like we treat file notification already ? < 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?) < mclasen> are there any funny cyclic deps ? is libproxy using glib ? < danw> ah, yes. libproxy has a gnome plugin, that reads proxy settings from gconf (currently. presumably gsettings eventually) < mclasen> ah, fun < mclasen> so that might make a separate module more plausible, then < mclasen> if we make it an extension point, you could also colocate the module with libproxy... < danw> yeah. and i guess we could deprecate the separate module later if we found a good way to put it in-tree < leio> I suggest you split libproxy-gnome to a separate package? < danw> there's also the tls stuff even after figuring out libproxy < 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 < leio> (mostly nvm, I confused with libsoup-gnome) < mclasen> colocating the tls stuff with gnutls/nss is probably less plausible < danw> actually, putting our extension points into someone else's module might cause problems with release schedules too < mclasen> I don't strictly object to having either of these live inside gio as conditionally compiled subdirectories < danw> anyway, don't need an answer today since you've got to run, but soon-ish < mclasen> I can still split them off in distro packages and contain the dependency that way < danw> the circular dep with libproxy is awkward though < mclasen> yeah < mclasen> anyway, I gotta go < mclasen> we should figure this out soon, as you say < mclasen> to land even more cool stuff this cycle < mclasen> :-) < mclasen> see you all soon < mclasen> next meeting in 2 weeks ? < mclasen> or so < ebassi> mclasen: agree < mclasen> later < garnacho_> sounds fine to me < ebassi> there's still one last point from jjardon < ebassi> which I think we can discuss - mclasen can read the minutes :-) < ebassi> deprecations in the 3.x cycle < 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 < 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 < ebassi> we touched it briefly last week as well (deprecation of the H|V stuff, GtkTearOffMenu, GtkRuler, etc.) < ebassi> I think we can go ahead and deprecate GtkTearoffMenu < ebassi> can't wait for the flames < jjardon> :) < ebassi> we discussed about deprecating GtkHSV ages ago, but we never did < ebassi> same as GtkRuler < ebassi> or, at least, make GtkHSV a private widget for GtkColorSelection only < 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 < ebassi> vwduder: I think I did a review on #gtk+ a couple of days ago < 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 < ebassi> shame that mitch's not here for a comment re: gtkruler and gtkhsv < ebassi> codesearch says that gtkruler is still used < jjardon> Maybe more interesting is the deprecation of the H|V stuff, do we agree on deprecate them? (and make base widget not abstract) < ebassi> but gtkhsv is not < jjardon> Here the wiki page for the property defaults: http://live.gnome.org/GTK+/PropertyDefaults < 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 < jjardon> Maybe a mail to gtk-devel-list could help? < ebassi> jjardon: yes, it would help < ebassi> jjardon: at least, it would bring out people from the woods < ebassi> jjardon: could you assemble a list of "deprecatable" classes? < jjardon> ebassi, sure < ebassi> thanks < jjardon> I think the bugzilla list is quite complete, If you add the H|V stuff < ebassi> yup < jjardon> and GtkHSV < ebassi> okay, I think we can adjourn the meeting < ebassi> next meeting: same time, in two weeks < ebassi> thanks for attending, everyone