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
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.