night lads :) hey aruiz hey ebassi as usual, the meeting agenda is available on the wiki: http://live.gnome.org/GTK%2B/Meetings hi everyone * mclasen goes for coffee hey hey behdad who is cheerleading today ? i like ebassi for that :) heh I'd make a fantastically bad cheerleader :-) anyway, the agenda points for the meeting are: 1. fundamental types for gint16/guint16 (bug: 562498) 2. use target milestone field in bugzilla 3. features set for gtk-next 4. features set for glib-next points 3. and 4. are fallout from last week's meeting looks like someone cheated and avoided settling on actual points :P point 1. I think has been requested by davidz for GDBus mapping to the DBus type system do we have any platforms where short != 16? point 2. is part of jjardon's set of queries for glib and gtk+ bugzilla products, which are fantastic ebassi: well, yeah, for a type mapping from C/GObject <-> D-Bus it's kinda needed timj was notably against it when the bug was filed now, also the Vala people have been asking for it * mbt notes that #1 makes it possible to be more consistent about type strength (such as in Vala, for consistency) so how true is timj's assertion that it's the wrong way to map types? bug # for reference? ah. nm. bug #562498 davidz: i disagree with your assertions in comment #6 there timj's argument is kinda broken, because we wouldn't have G_TYPE_CHAR that way for a lot of the same reasons that timj gives in comment #15 desrt: that comment is pretty old desrt: I think I disagree it with myself nowadays ok e.g. for D-Bus you want to pass the signature anyway exactly tim's "or use your own metainfo system" right considering that gvariant will bring its own anyway, is this such a blocker ? lacking fundamental types it's not a big deal for C/GType <-> D-Bus mappings - the only downside is that properties on the GObject will have type guint32 with a range [0, 65535] the gvariant branch already contains code to serialise/deserialise gint/glong/gwhatever to dbus int16 without extra help you just give the right type to the serialiser function and *magic* desrt: I see you still haven't fixed the spelling ;-) it even does the boundschecks and errors out as appropriate desrt: btw, did you add the GError to the Serializer yet? would be neat davidz, you can set limits on the paramspec regardless of the type davidz: no. aruiz has been slave-driving me to work on another project this past couple of weeks, so i've done very little gvariant work :p kalikiana: yes desrt, :P desrt: maybe it's time to send some goons to talk to aruiz ;-) davidz: but i absolutely agree that it's a good idea only blocking on my free time right now davidz, in my defense I'd say, that work would be done already if desrt didn't chewed nicotine gums gtype should decide if it wants to follow C conventions or space conventions for naming its integers aruiz: hah. but that's 3.0 stuff Company: i think the current mix that we have now is appropriate desrt: i disagree so, from the gdbus side of things not having fundamental types for guint16/gint16 is not a big deal - however it's just pretty ugly having to use a guint32 with limits for GObject properties instead of, hey, a guint16 as a general sentiment even desrt: long is useless for example i love long so, are we done with 1. ? not urgent for gdbus, thus timj wins ? * Company agrees with mclasen mclasen: I guess as someone who has written serialiser code, i have to agree with the point of "please no more new int types to put in my switch statement" ok then yeah, but it just feels incomplete this way * davidz OCD but meh 2. 'target milestones' - what is that about ? I don't think that's OCD, I think it's just consistent. who presents that point ? jjardon, i guess that's jjardon's job and he's not here.... I can talk about that mbt: that'd make it CD - consistent disease it's basically a request, when we are planning a release, to use the target milestone for bugs ebassi: I'd like that very much so that we can have queries to check the status of the release and also when writing the release notes it's mostly QA stuff but requires some developers time by the way, if you want to look at the current queries, here: http://live.gnome.org/GTK%2B/BugzillaLinks the queries can also partly replace the patch nagging emails on the mailing list, or at least make them easier to write I've been using them and splinter to review trivial patches, and it's really easy to get things going * mclasen has some doubt how well this is going to work in the giant pile of bugs that we have... mclasen: bugzilla is faster nowadays, and this mostly helps tracking down unreviewed patches - which, sadly, are a minority of the bugz bugs, even I'm open to trying it did we start at 21? * kris is so confused e.g. the unreviewed query returns 501 bugs but I'm unclear on what we would target milestone, beyond the handful of big features we target for a release kris: utc has no daylight savings kris, time shift this week .... kris, to the winter time and the meeting time doesnt switch? meeting time is set in UTC north america and the entire southern hemisphere changes timezones differently than europe :p mclasen: jjardon was asking if the TM could be set when the maintainers decided to plan to land a bug for a release I'm mostly worried of abuse from non-team members ebassi: I don't really ever decide to 'land a bug in a release'... mclasen, but there are things like widgets or features that are planned for a release so it just makes it easier to track and you don't have to collect old mails for that blah, timezonres kalikiana: yeah, thats the 'handful of features' I mentioned.... * kris continues debugging his compiler I think it can also be tracked retroactively for distributors anyway, I'm just reporting the suggestion :-) as I said, I'm open to trying this, though I'm a bit dubious on how useful it will turn out to be and it can help people who are not up to date and attending meetings what's the use case for setting the target milestone on bugs? just for release-based queries? kris: yes I mean, its an extra hassle and handling and what do you do if you put the fix in two releases? (ie. stable and stable-1) kris: tracking releses progress and see what's still pending haven't we tried milestones in the past? I recall setting them in the 1.3 / 2.0 times and we also had to punt half of them ... changing milestones again yey bugmail :-) but if it helps people, why not you should just do it on the visible tracker bugs * kris shouldnt speak up so loudly since he does only 1% of the work ... kris: you should really check out http://live.gnome.org/GTK%2B/BugzillaLinks ebassi: oh, what a list bugzilla in being actually useful shocker :-) ebassi: I use only two bugzilla links ebassi: 1. tree view bugs ebassi: 2. mac bugs ebassi: and I barely manage to keep up with only those unfortunately Company: that might make sense kris: I think these are mostly useful for new contributors, to easily grok what's going on, and for drive-by reviews anyway, I'll shut up now :-) kris, I think there's no problem if you keep doing that. jjardon does a good job at tracking bugs and others can also do that kalikiana: and he's leaving the breadcrumbs behind for new people joining :-) ebassi: it will only help if the milestones are kept up to date, which basically fell apart in the past kris: fair point I think we have mostly overcome the point where gtk was stalling Yeah, I like what jjardon's doing except for how he links all the bugs together and if one bug changes then you get a shitload of emails for all the linked bugs. :) kalikiana: it even fell apart when we had 3 full-time maintainers kris, but bug triaging doesn't have to be done by a maintainer as you can see kalikiana: but I assume maintainers are in charge of setting and updating the milestone? in charge of decisions, sure. but that doesn't mean they have to do every part of the work it's only 10 bugs total per release anyway, no? * kalikiana wonders why this kind of topic always causes this extremely loud silence. hehe next point! I'm not saying much because it doesn't affect me that much and I don't care enough. did we come to a satisfactory resolution yet? desrt: I think we all agreed that its cool if jjardon puts milestones on the bugs we work on... :-) And I'm busy hacking in another window anyway. :) ok. so gtk-next features? next == 2.20 ? or 2.20 + 1 ? agenda just says "gtk-next" :) it says next because I screw up the version number i'm pretty sure we're talking 2.20 + 1 next stable release for gtk and glib Next stable is 2.20. as the featureset for 2.20 was pretty much set in stone 3 weks ago quick summary for 2.20 is that we have landed spinner widget + cell renderer yay mclasen: Are the things that were on your blog for F12 things going into 2.20? (is F12 using 2.20?) and tbf promised to brush up the tool palette before end of november what spinner? and I would like to propose some tooltip refresh, indeed bratsche: F12 is using 2.18 F12 is using 2.18 + patches mclasen: the one you blogged about? kris: GtkSpinner kris: the tooltip stuff, yeah mclasen: Minor thing, but I want to add some API for getting the primary display, as I talked to you one night. Err.. primary monitor. sounds like a good idea to me we're still lacking the setter ui for that though * mclasen looks at federico mclasen: I am unsure about the blue, but thats a theming thing really I'm back home as of yesterday so I can test it out since I have an extra monitor now. mclasen: I would love to help out reviewing the updates to the positioning algorithm kris: the color is entirely theme-land https://bugzilla.gnome.org/show_bug.cgi?id=599617 has the patch about visual things mclasen: the new tooltip stuff is pretty cool https://bugzilla.gnome.org/show_bug.cgi?id=599618 has the positioning patch if people want to review, that would be great metacity tooltips still kind of suck, though :-) I can put the positioning thing on my list ebassi: oh, I patched that as well :-) ah, nice to finish up the 2.20 feature list, I have no idea where we stand wrt to missing accessors any progress on that ? Uh, kind of tangentially related.. gtk_button_pressed() and similar API is deprecated since those signals moved into GtkWidget. What was the purpose of that API anyway, and does there need to be gtk_widget_pressed() type stuff? Or at least that's my understanding of what I read in irc late last night, so was just curious. we have gtk_button_clicked hum not that I know what for :P mclasen: oh, BTW, I meant to ask you about fedora's fixes for the RANDR stuff At first I thought maybe it's used for testing, but I guess stuff like Strongwind and Dogtail does everything through ATK so I'm not sure what those functions are used for now. mclasen: you know, for now I guess it's fine to commit your patch to enable the "primary monitor" checkbox... I don't have time to do the full UI rework I want to do :( federico: I lost that patch :-( the only other significant randr fixes i've done lately is to make gnome-screensaver actually work with hot-plugging multihead bratsche, for testing there are gtk_test_ functions the only thing gtk_button_clicked does anyway is g_signal_emit Okay anything else for gtk? we move to glib 2.24 features? possibly diagnostic mode, if I find time for that at least I intend to kalikiana: if you can get me a list of requirements and ideas on that I'd gladly give a hand ebassi, I have a long document about that, I should try to get that on the list or bugzilla I suppose kalikiana: I remember discussing it a GUADEC in Istanbul, but I never got a solid list of what the diagnostic mode would require kalikiana: cool, thanks ebassi: there's a list of ideas, but nothing concrete may I ask, what's diagnostics mode? giving out warnings about using old properties and signals or poking inside widgets aruiz: something that will tell you if you're using obsoleted signals, properties for runtime checks, as opposed to compile-time ones uh, funky #521707? (class private data) didn't we talk about that last week ? ah. i missed that. and it's sitll on the list as 'to do' jjardon: hey :-) i guess that means that it's decided to be included but needs more work? okay, i can once more re-iterate that status on that bug there's a patch it has been pre-reviewed we even found a bug during that pre-review and that bug was fixed its valgrind clean ebassi, hello ;) and hello all kris: so what holds up the commit? timj uncloaked a while ago, so maybe we can get him to approve ? also, if we are going to use this functionality for adding new vfuncs as the table gets full, do we have 'best practice' for that? also, also, does it become customary to have a *priv; pointer in class structs now? desrt, Are you seeing the http://live.gnome.org/GTK%2B/Roadmap ? I've set todo because Class private data bug is still not fixed, but I don't know the real status. Feel free to modify it if you want I created http://live.gnome.org/GTK+/BestPractices to collect suggestions on how to do things ^^ desrt jjardon: yes. that's exactly what i was looking at. understood. timj: ? I think priv is an obvious choice, unless you hide structures in c files danw: anything to say about gnio issues? otherwise the sealing would be moot :P kalikiana: obvious choice for new sturctures that have space for it... yes, not old ones of course looking up private data has always been costly, I doubt that will change desrt: not beyond what i said a few weeks ago. (planning to work on tls and proxies) sorry. linode chose a very bad time to start having connectivity problems. did i miss anything? 21:17 < kalikiana> looking up private data has always been costly, I doubt that will change 21:18 < danw> desrt: not beyond what i said a few weeks ago. (planning to work on tls and proxies) nothing else cool. i want to merge gvariant to master asap several people have been using it now and they all seem to like the API a lot and it has been stable for a fairly long time so i think in that regard it's ready to go it's also strictly an addition so it's not going to break anything that exists * mclasen will give it another look where do I find the current merge candidate ? mclasen: oh, interesting - I thought gnome-screensaver already did that mclasen: ok, no problem - I'll redo the primary monitor thing 'gsettings' branch but i propose only to merge the stuff in glib/ i can make a separate branch for that if you prefer one blocker, though, is the 1-bit mutex lock stuff http://bugzilla.gnome.org/show_bug.cgi?id=548967 mclasen, http://git.gnome.org/cgit/glib/log/?h=gsettings * mclasen goes to look i can do the merge without the 1-bit mutex locks if you prefer mclasen: refresh my memory, please - that info is already in the XML and there is a gnome_rr*() API to get the primary value, correct? we just need to select that in the GUI? (and add thread-safety later) hmm, theres also a gvariant branch desrt, Could you create a bug to integrate gsettings branch and then we can set http://bugzilla.gnome.org/show_bug.cgi?id=548967 as a blocker? federico: yes, I think thats accurate mclasen: ok, should be easy bratsche: so from GTK+'s viewpoint you just want to add an API to get the primary monitor? *sigh* cats biting in your internet cable? :) when linode went down i wondered if it was the local connection so i tried one of my neighbour's not so reliable there either :p desrt, desrt, Could you create a bug to integrate gsettings branch and then we can set http://bugzilla.gnome.org/show_bug.cgi?id=548967 as a blocker? jjardon: sure. i'll do that. i can also create a branch that contains exactly the parts that i want to commit ASAP (ie: no gobject/ or gio/ changes yet) if that would help desrt_, great with gsettings and gdbus both inside glib wanting to use this... and dconf outside of glib already shipping its 4th tarball... would be really helpful to get this into master branch soon desrt_: having such a branch would be nice ok. i'll have that ready for the next meeting, then should i include the 1bit mutex stuff on that branch or leave it out for now? (i don't currently have any code that uses GVariant multi-threaded, so i don't care) federico: Yeah, that's what I was going to do. (sorry, was afk for awhile) federico: I'll file a patch soon and ask you and mclasen for review. desrt, waiting for an application to stumble into threading once it's in glib isn't attractive, though :) imho but it's easy to fix in the future since the design was made to allow it easily and for the time being, i'm happy enough to say "not threadsafe yet" Yes, the point is that it will be a pain for the one trying to use it * desrt just trying to remove blockers to a speedy merge :) hehe * bratsche tries to start thinking of new blockers just to annoy desrt "merge must be performed by someone in dallas" * desrt is all over that one * mclasen would rather see threadsafety issues worked out first... mclasen: i'll include the mutex stuff in the branch i make and mark that bug as a blocker ,then davidz: poke desrt: yes? davidz: gdbus is marked 'further discussion' desrt: for today? or what? on the roadmap desrt: I talked to mclasen and we seemed to agree it should be reviewed, then merged for this cycle ok. i'll move it out of the 'more discussion required' section, then my branch is basically feature complete sans some GDBusProxy surgery/fixes the plan is to get alexl to review it once he is back nice. davidz, Do you mind if I post that info in GTKRoadmap page? jjardon: already editing :) desrt, oh, great :) it's late does anyone have anything else they want to discuss? I'd like to show you this page, maybe It's useful to review patches and bugs: http://live.gnome.org/GTK%2B/BugzillaLinks It was posted earlier. jjardon: already pimped it :-) jjardon: if i'm to understand this milestone stuff correctly, i target my gvariant bug against that? for 2.24.0... desrt, exactly cool ebassi: want to call it? but someone should add 2.24 to posible target milestores in glib and 2.20 in gtk+ desrt: let's call it then :-) sweet thanks everyone food time :) jjardon: I can do that ebassi: thanks, as always :) Yum. mclasen, thank you * ebassi ate in front of the laptop jjardon: go for it ;-) desrt: btw, should I file bugs for the gvariant issues I have? is there a gvariant component in bugzilla? * jjardon forgot the change to GMT+2 to GMT+1 in his country :/ yes desrt: (not really 'issues' per se - just the stuff raised on the list) to keep the issues from annoying everyone i made the gvariant component under 'dconf' for now desrt: okey-dokey, I'll file away i'll move the bugs over when the merge happens davidz, please use the target milestore field and set it to 2.24 ;) will do will any of the feature branches get merged for 2.20? Extended layout, xi2, Resolution Independence or Client Side Decorations? Sorry if this was discussed before bratsche: sure jjardon: whatever is ready and reviewed davidz: have you looked at gvariant past the API? davidz: like, implementation.... desrt: only very briefly jjardon: that was discussed three weeks ago davidz: probably will be helpful to have at least one other person familiar with it davidz: and you are obviously the best choice desrt: increasing the bus-factor is always good ;-) ebassi, The question is if I can move them out of the 'more discussion required' section? davidz: i'm working on data model API stuff for at least the next couple of days davidz: but i'd be happy to schedule some sit-down time with you on thursday or friday? block out a couple of hours and bring you completely up to speed desrt: that might work - I need to finish some polkit stuff but that should be done tomorrow - still, let's say Friday? ok 1pm? desrt: sounds good to me jjardon: have there been any bugs wrt the filesystemmodel merge? Company, no, as far I know so noone is using git master yet or our code is bugfree our code is bugfree :) what is FSModel? maybe when 2.19.0 will be released we will have more testers desrt: filechooser rewrite i did about that... * mclasen meant to do releases this week * desrt was under the impression that GIO *was* the filesystem model for gtk but so far not sufficient breathing room to do it desrt: gio didn't implement GtkTreeModel last i checked :p oh. i see. it'll all be a moot point when i propose the model API next week :p as long as it has the same performance characteristics for 40k entries mclasen, Is there any plan to do gtk 2.19.x releases based in time, instead by features? * desrt wanders away maybe we can use target milestore field to 2.19.x releases too. As "objectives" between meetings sorry, jjardon - same linode issues desrt had I lost everything after "can I move the branches from the needs discussion" jjardon: there's just not that much going on for 2.19.x from my perspective; get the remaining accessors in and get toolpalette merged, anything beyond that is just extra goodies ebassi, no problem :). So can move feature branches out of the 'more discussion required' section? (in http://live.gnome.org/GTK%2B/Roadmap) mclasen, only a idea to focus the development between releases: if something can't be done for 2.19.1, it can be converted as a objective for 2.19.2 man, you must have been a fedora developer in a former live so much love of process :-) mclasen, only a student for now :) Think: if I'm a new contrinutor and I want to help, I need a list of bugs to focus, because bugzilla database is quite big: and a list of bugs that are important for the next release is quite motivating do developers really turn up and say "i'm gonna implement a new feature" and deliver without having any previous hacking experience? usually they either know what they want or they start small and I think that would be useful for core devels too its ok, just making fun... Company, not only for newbies. Imagine a experience GTK+ hacker that want to help in gtk+ development: they can take a look in the bugs targeted for the next release to see what the people is working on. I think this is more easy than search in bugzilla for a bug mclasen :) jjardon: i've never seen any of the gtk devs do that jjardon: they usually have their own todo lists I look at easy bugs sometimes, whether I hit them myself or not. But then again, I do have my own list based on gtk bugmail I would guess for someone not receiving all gtk bugmail it should be useful