< ebassi> meeting time! < ebassi> :-) < ebassi> as usual, the agenda is at: http://live.gnome.org/GTK+/Meetings < ebassi> 1. Decisions about the latest missing accessor functions < ebassi> 2. Potential API changes for better introspection/bindings. See Bug #621590 < ebassi> 3. GDateTime in GLib? See Bug #50076 < ebassi> 4. Proxy suport in GIO ? (need for reviewer) Bug #580341 < ebassi> 5. miscellaneous * mclasen still in another meeting < jjardon> for the accessors, I think the most importatn ones are the ones that block some applications to be GSEAL-compatible. check the blue lines in http://live.gnome.org/GnomeGoals/UseGseal < ebassi> I think that mclasen said in a couple of occasions that he's not expected to comment on every single new accessor - but the GtkMessageDialog issue is an example of requiring some reviewe < jjardon> Altougth the problem with gnome-terminal was fixed today by federico < mclasen> I think the remaining ones are mostly head-scratchers where it is not clear that they represent a valid use case or should be done in a different way < jjardon> We should mark them as not valid then < mclasen> after sufficient head-scratching, yes < jjardon> make _gtk_window_group_get_current_grab() public has some explanations by the devels: https://bugzilla.gnome.org/show_bug.cgi?id=620832 < jjardon> GtkButton::in_button and GtkRange->has_stepper_X are less clear < jjardon> also, I propossed gtk_font_selection_dialog_get_font_selection () for glade and for completeness: we already have gtk_color_selection_dialog_get_color_selection () < mclasen> I'm pretty sure I remember prior discussion with owen where he was opposed to exposing too much of the grab machinery < mclasen> but I can't find the bug now < jjardon> yeah, the problem is thar fontsel is exposed by the GtkBuilder api: http://git.gnome.org/browse/gtk+/tree/gtk/gtkfontsel.c#n1702 < mclasen> this may be what I remember: https://bugzilla.gnome.org/show_bug.cgi?id=69934 < mclasen> an oldie... < ebassi> nice :-) * jdahlin would like to add glib extensions such as bug 622396 to point 2) of the agenda < ebassi> anyway, I guess most of this stuff requires some sort of work around or API addition < ebassi> so - discussion in either the mailing list or bugzilla < jjardon> gsealed GNOME is scheluded to nex week < ebassi> jdahlin: eeek, iterator API! < mclasen> I think that is an artificial rush < ebassi> architecture astronauts < jdahlin> ebassi: only useful for language bindings, intended to solve real problems < jjardon> well, the glade bug is lees important as there won't be gsealed glade by next week < mclasen> things should get ported, yes, but only when they (and gtk) are ready for it.. < ebassi> also, API/feature freeze date is aug 2/4 < ebassi> so - seriously, we still have one month < mclasen> I think it is perfectly fine to have the one or other corner case not work with 2.90.x, either < mclasen> like libnotify using stuff < ebassi> it's not like distributions will switch to gtk 3.0 istantaneously < ebassi> and never ship gtk 2.x ever again < jjardon> My reasoning is that is not a valid use case, we shold mark them as that < mclasen> we will likely ship 2.x forever... < ebassi> forever, and then some < jjardon> yeah, but It would be nice that at least the GNOME core apps use GTK+3 < jjardon> what about the gtk_font_selection_dialog_get_font_selection () api addition? < mclasen> bug # ? < ebassi> jjardon: you mean set_font_selection()? < jjardon> no bug, but is needed to gseal glade < jjardon> http://bugzilla.gnome.org/show_bug.cgi?id=594957 < ebassi> do we bother sealing deprecated libraries? < kalikianatoli> no < ebassi> for deprecated libraries, I mean < ebassi> or you mean glade-the-application? < jjardon> fontselection is not deprecated < jjardon> oh, glade -the app, yes < kalikianatoli> deprecated means "already dying", dosn't it? so why would it help to seal it? < ebassi> mmh, tristan doesn't think Glade is going to be ready anyway < ebassi> so I'd say there's no hurry for that * mclasen fails to keep up with 2 meetings < kalikianatoli> would seem a bit sad, though, if Glade is supposed to be the standard gtk+ designer :-/ < ebassi> kalikianatoli: yeah; but it would mean a lot of people starting to fix glade < jjardon> There are only 2 issues in glade: GTK_FONT_SELECTION_DIALOG (dialog)->fontsel and GTK_WIDGET_UNSET_FLAGS (widget, GTK_TOPLEVEL) < mclasen> I don't think a get_font_selection() method is going to be a problem < mclasen> we should probably just add it < jjardon> but the last one is not trivial < ebassi> or at least a single, highly motivated developer < kalikianatoli> jjardon, imho the unset flags use case is something that should change in glade < kalikianatoli> not trivial, though < mclasen> but as I said elsewhere, we really need someone to do a altogether new font dialog < ebassi> kalikianatoli, jjardon: maybe switching glade to GtkOffscreenWindow/Widget/Whatever < jjardon> ok, I'll add the new getter < jjardon> ebassi, yeah, that's the plan I think < jhs> mclasen: shouldn't be that difficult, see http://live.gnome.org/Design/GTKFontDialog/MockupSet1 < kalikianatoli> mclasen, how do we find out what design is preferred? I would certainly be interested, but the discarded ideas make it seem difficult :-) < mclasen> mairin and behdad were looking at doing a font dialog design at some point < jjardon> jhs, nice, I didn't know that page < ebassi> it would be nice to have some UI interaction designer time on that < jhs> kalikianatoli: look at my link < mclasen> I can ask them if anything came out of that < kalikianatoli> jhs, do you belong to the font dialog crew? < jhs> jjardon: maybe search/file a bug and CC some interested people < jhs> kalikianatoli: no < kalikianatoli> ah, misinterpretaed the "my" then < ebassi> okay, let's not sidetrack the discussion :-) < ebassi> new font selection dialog can be a topic for gtk 3.2 ;-) < mclasen> in any case, a new dialog would be a new widget, so is not affected by us adding accessors to the guts of the current one... < kalikianatoli> it *could* be the same as soon as the sealing is done ;-) < jjardon> kalikianatoli, are you sure? < jjardon> what will happen with the current api exposed bu GtkBuilder? < kalikianatoli> Well, I'm guessing the api we have is not too specific, we'll see when we have it < jjardon> I mean http://git.gnome.org/browse/gtk+/tree/gtk/gtkfontsel.c#n1702 < kalikianatoli> Poke me when you find out what the preferred mockup is :-] < ebassi> jjardon: other issues with sealings? < jjardon> yeah < jhs> ebassi: Ihttps://bugzilla.gnome.org/show_bug.cgi?id=622186 < jjardon> this ^ < jhs> It's kind of a hack though. I rather would like to have a cleaner solution for the problem than using in_button directly but seems tricky. < ebassi> jhs: you're using in_button to basically simulate a enter/leave? < jjardon> ebassi, context: https://bugzilla.gnome.org/show_bug.cgi?id=577469#c16 < kalikianatoli> jhs, that is not "kind of", that is pretty obviously working around a problem :-D < kalikianatoli> it even says literally so in the bug < jhs> kalikianatoli: yeah but I am just not so much into gtk+ details to know how to fix it and I didn't create the hack that is used. gdl code base is rather old... < ebassi> GtkButton::leave-notify-event already sets the in_button to FALSE - why is it required to set it explicitly? < ebassi> by the code, faking a leave-notify-event with that event would lead to in_button = FALSE < jhs> ebassi: faking? < ebassi> (though I admit that faking an event is not the best way to handle this kind of stuff) < ebassi> jhs: you're creating a CrossingEvent and then emitting ::leave-notify-event directly < ebassi> in gdl_dock_item_grip_fix_iconify_button() < kalikianatoli> goes a bit in the direction of the pressed/ released functions which were deprecated < ebassi> yeah < jhs> ebassi: ok, sounds kind of reasonable! I would very much appreciate if someone could attach some example code to the bug. Otherwise seems fine - let's go on. < jjardon> ok, the last one GtkRange->has_stepper_X: https://bugzilla.gnome.org/show_bug.cgi?id=621250 < jjardon> It's blocking gtk-engines < kalikianatoli> the last comment seems pretty clear to me < ebassi> yup < kalikianatoli> maybe I can have a look at that tomorrow, should be straightforward < mclasen> should not be hard, indeed < mclasen> there's examples of this kind of stuff in gtktreeview, eg < jjardon> so: I'll make a getter for the fontsel, there are solutions for the rest and _gtk_window_group_get_current_grab() needs mor discussion < ebassi> cool < mclasen> I'll ask owen if he remembers the old discussion about grabs < jjardon> If anyone can provide some code to jhs issue would be great < ebassi> jjardon: the patch looks already good - without the explicit in_button = FALSE < ebassi> right, next item? < mclasen> did we have more topics ? I'm sure we did < ebassi> • Potential API changes for better introspection/bindings. See Bug #621590 < jjardon> ebassi, comment in the bug then ;) < ebassi> jjardon: roger * mclasen comments in 621590 < ebassi> so, walters was asking if we could bend the rule of minimal recompilation for API that's hard/impossible to bind < kalikianatoli> is this about gtk_quit_add? < mclasen> gtk_tree_path_get_indices < jjardon> well, as people has already to do some port work (use accessor functions), I think little changes like this can be allowed < jjardon> If they are really needed < kalikianatoli> it would suck for anyone trying to keep supporting gtk2 < kalikianatoli> which is one of the reasons to not allow it < pbor> on the other hand we could come up with a slightly different name, keep both in gtk2 and just the new one in gtk3 * kalikianatoli is with pbor on that one < jjardon> yeah, I was going to suggest the same as pbor < jjardon> and deprecate the old one < mclasen> what better names are available ? < ebassi> get_path_indices() < ebassi> though a bit redundant < ebassi> get_components(), though slightly a misnomer < ebassi> split() < ebassi> decompose() < kalikianatoli> _get_current_indices < ebassi> to_indices() < kalikianatoli> (based on the documentation calling it that) * mclasen had thought about to_ * tadeboro votes for to_ * kalikianatoli likes to_ as well < ebassi> we have from_indices(), from_string() and to_string() < ebassi> so to_indices() would map < kalikianatoli> a good chance to increase consistency :-) * ebassi likes symmetry ;-) < jjardon> great, anyone can comment in the bug? < ebassi> sure < kalikianatoli> I will do < jjardon> Also, we should announce that we are open to this kind of fixes to help bindings people < jjardon> ebassi, Can you in the meeting minutes? < ebassi> sure < mclasen> tbh, I don't see how this specifically helps bindings < mclasen> the function was already there, just with a slightly clunky name... < ebassi> mclasen: overriding the name requires ad hoc code that introspection-based bindings not always can afford < mclasen> do we have annotations that let us fix that, theoretically ? < jjardon> mclasen, http://live.gnome.org/GObjectIntrospection/WritingBindingableAPIs < jjardon> and the mail from tomeu: http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00105.html < mclasen> like do-not-bind and bind-as-some-other-name ? < davidz> Rename To:? < ebassi> mclasen: we can hide functions, but I don't think bind-as-another-name is implemented/works < davidz> I saw Rename to: being used in gdbus for the _with_closures() stuff.... < davidz> (see http://live.gnome.org/GObjectIntrospection/Annotations ) < mclasen> ah, nice < davidz> see http://git.gnome.org/browse/glib/commit/?id=45e604d029980f90a7304b6311fc43cc0cc2ab69 < davidz> for the commit < mclasen> in this case, and we should just take the _to_indices name it to improve the C api (with proper deprecations for the _with_depth variant) < mclasen> but good to know that a renaming facility exists < ebassi> right, so the message is: we can fix API warts that make the life of bindings harder, but only by deprecation+addition, not changes < danw> no < danw> you can leave the warty method as is, and rename the more-bindable method to have the name of the old warty method < mclasen> well, the problematic part is having the same name for different functions in 2.x and 3 < danw> and then C sees the old method still, but bindings see the new method (with the old name) < jdahlin> there are both ways to hide apis from introspection and export apis with different names < mclasen> next topic ? < ebassi> GDateTime < ebassi> but 50076 < ebassi> another oldie, but goldie < ebassi> I did a review - there are some issues * mclasen just doesn't have the time and inclination to get involved with that < ebassi> mostly: the timezone support in the API relies on tz_data, and this means not supporting XP pre-SP2 < ebassi> AFAIR < ebassi> the API looks good, and in theory we could land the timezone API at a later date < ebassi> I'd just wish to have a proper date/time API in glib :-) < mclasen> how does this relate to GDate ? does it obsolete it, extend it, or none of the above ? < thiagoss_> None of the above < jjardon> then can be used in GtkCalendar < ebassi> thiagoss_: well, no - it mostly obsoletes it, though a date-only API can be kept if you need day/month resolution < mclasen> I would be much more receptive if it was a wholesale replacement < mclasen> having a GDate and GDateTime unrelated next to each other in the same library seems like a nonstarter < thiagoss_> ebassi: I guess you're right. Everything in GDate API could be done in a GDateTime as well < ebassi> yeah < ebassi> I see DateTime as an enhancement with smaller granularity < ebassi> you can ignore the Time part and still have a propert Date API < jjardon> So, GDateTime can deprecate GDate. Rigth? < kalikianatoli> yes < ebassi> I'd like to see GtkCalendar get some support for it as well; then we could judge the impact < jjardon> ebassi, Did you ask tml about the tz_data issue and XP ? Maybe he knows < ebassi> jjardon: that was thiagoss_ task :-) < jjardon> thiagoss_, ^^ ;) < ebassi> jjardon: in theory, XP post-SP2 (which is what microsoft supports) has the API < ebassi> pre-SP2 is not supported any more < jjardon> not a bug problem then, I'd say < jjardon> big* < kalikianatoli> ah, so that sounds good enough then. I thought it were vista-only < danw> and if people are running pre-SP2, we can just hack into their machines remotely to upgrade them < ebassi> and, if we wanted to support it, we could eventually ship the tz_data database ourselves - though it would require sync with upstream < kalikianatoli> (imho good enough) < ebassi> danw: hahahaha < danw> we don't want to ship tz_data ourselves < ebassi> g_date_time_win32_hack_xp_and_update() < danw> it changes too often, and it's vaguely important that it be up-to-date-ish < kalikianatoli> well, we could leave anyone who *really* wants, to ship it < jjardon> danw, or install other thing directly :P < ebassi> agree < danw> btw i think glib may currently still support windows 2000, though i'm not certain of that < thiagoss_> FYW libgweather has a --timezone-info-dir configure option that allows people to tell where their tzdata is installed. If pre-sp2 xp users want it, they can install and configure with this option < danw> and it might just be a "nothing has broken it yet" thing rather than than a "this is important" thing < thiagoss_> let me get the list of supported windows versions < thiagoss_> (for the timezone api, that is) < kalikianatoli> so... do we mostly agree on leaving the ancient windowses to those who care to ship the archive? < ebassi> aye < kalikianatoli> cool < danw> i think we should have a special magic name for "the local timezone", and on pre-API windows, glib would only support the local timezone and UTC, and it would just not recognize any other timezone names < kalikianatoli> danw, yeah, that's what I suggested sometime before, to hardwire "local" and "UTC" < thiagoss_> According to: http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx -> Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows Server 2008 (Server Core Role not supported), Windows Server 2008 R2 (Server Core Role not supported), Windows Server 2003 SP2 < danw> that's a .NET API not a Win32 API... < ebassi> we probably need tml's expertise on this < ebassi> right, we can punt this until we know what kind of support win32 has and how much alcohol do we need to stop caring :-) < mclasen> sorry, I lost network here < mclasen> so I missed the last 10 minutes < ebassi> thiagoss_: it would be nice to get tml's opinion on the bug < thiagoss_> ebassi: Ok, I'll keep searching here for the correct win32 API < thiagoss_> I've seen it around once, just can't find it anymore < ebassi> mclasen: generally, the idea is that win32 has some issues with the timezone data < ebassi> mclasen: we can ideally ignore that and just allow localtime+UTC on win32 < ebassi> mclasen: tml will probably know more < ebassi> thiagoss_: thanks < jjardon> mclasen, http://pastebin.com/SutJnfFF < ebassi> I'll keep reviewing the patch < mclasen> me ? win32 ? no < thiagoss_> Think I found it: http://msdn.microsoft.com/en-us/library/ms725473(v=VS.85).aspx < thiagoss_> Doesn't look promising to full timezone support < mclasen> where do timezones show up in the api currently ? * mclasen doesn't see it < kalikianatoli> mclasen, in g_date_time_new_full < kalikianatoli> you can pass it as the last argument < mclasen> but there seems no way to query the timezone ? < mclasen> if that makes conceptual sense in the first place < kalikianatoli> the patch was stripped for easier review < kalikianatoli> I think we likely want that in the end < thiagoss_> mclasen: I have another patch that adds a _get_time_zone < ebassi> mclasen: in theory, you can create a GTimeZone by giving it the name - glib would fetch the data from the timezone database < ebassi> that would be the automagic way of having a per-timezone date+time and then converting it < thiagoss_> So, summarizing: we need to ask tml about win32 support availability and I need to port GtkCalendar to use it? < ebassi> thiagoss_: yes to the former, would-be-nice to the latter < ebassi> you always find interesting caveats when porting API :-) < danw> see what they do for evolution... maybe they're already shipping tzdata for that i guess... < ebassi> right, good point < ebassi> okay, final point? < ebassi> well, apart from jdahlin's iterator api? < ebassi> • Proxy suport in GIO ? (need for reviewer) Bug #580341 * danw pokes stormer < stormer> yeah, so as it says < stormer> We need a reviewer < danw> part of this is "when is the feature freeze for glib?" is it the same as GNOME? < sjoerd> danw: assuming for a moment that it is the same, (thus august 2, would that be problematic? < sjoerd> or are you worried that glib should be freezing earlier even? < danw> not "should" but maybe "is" < danw> glib and gtk are often on an earlier schedule than the rest of gnome < jjardon> AFAIK, not in the latest releases < danw> anyway, there's problems either way, which is that stormer and i disagree on how it should work and alex is mostly missing this cycle and no one else is paying attention, and so regardless of whether we do it my way or stormer's way, there's a chance that it will be wrong < sjoerd> gtk was quite late in the last round, not sure about glib < jdahlin> ebassi: < jdahlin> ebassi: I'll think a bit more about it < sjoerd> Right so basically we need some other people to pitch in/speed up the discussion? < stormer> danw, one of the problem is that you never took time to explain on what you disagree exactly < danw> i thought i did several times? < danw> https://bugzilla.gnome.org/show_bug.cgi?id=580341#c39 in particular seems to sum it up < stormer> I've been continuasly updating the code < danw> and the problem is, *i don't know if i'm right* < stormer> Ok, conclusion we need more people in that loop < danw> right < sjoerd> I'm happy to spend some time to go through the discussion and give my pov if that would be helpful < sjoerd> Is there anyone else knowledgeble about the gio networking stuff we could try to get involved? < danw> alex, desrt, maybe Company < stormer> sjoerd: I think as one of the user of GSocketClient it would be great < danw> but i don't know if any of them know anything about proxies either... < danw> my worry is that the API is being tailed for a use case that affects like 0.0001% of users < danw> tailored < sjoerd> Which use-case is that ? < danw> gssapi encrypted socks < sjoerd> I can agree that's a not very important one, but it would be nice to at least have the possibility to support it right ? < danw> as currently written, adding support for that means we cannot support using GSocket directly when there is a proxy < stormer> I think we can accept the compromize the you cannot have tunneled proxy with GSocket < danw> OTOH, i'm not sure that people are really using plain GSocket < sjoerd> I never saw a reason to use plain GSocket < stormer> I don't see a reason either, for me GSocket is just a thin wrapper over FD to make it friendlier < sjoerd> That might be because where i'm coming from, but i want to be able to layer may communications protocol over whatever underlying thing (which may not have a direct socket) < sjoerd> Also i'm guessing in a lot of cases you want to be able to work over SSl anyway, in which case GSocket is also not very useful? < danw> well, SSL is another problem; all the SSL libraries assume a posix-like API underneath then, and it's extremely awkward to try to put a GIOStream underneath them instead (as already discussed in that bug) < sjoerd> That's what we do in wocky and it works quite well for us tbh < sjoerd> both gnutls and openssl you can use without giving them the fd directly.. < danw> are you using async I/O? < sjoerd> I'd actually suggest not given gnutls a socket, we used to have loads and loads of pain in loudmouth because of bugs there < sjoerd> all our I/O is async yes < danw> well, i'll have to look at your code then < sjoerd> I'm not familiar with nss unfortunately < sjoerd> Our code actually came from gnio back in the day and was hacked up to our needs a bit < danw> for purposes of the current discussion, it behaves identically to gnutls and openssl < danw> oh, well, yeah, but that code is kind of a monstrosity as compared to using a GSocket directly < sjoerd> That code is scary yes, but that's more because of how it's written then anything else imho < danw> no, it's inherent to the problem < danw> anyway < danw> so perhaps the outstanding question is, do we expect applications to use GSocket directly? < danw> s/expect/want to encourage/ < sjoerd> I'd encourage them not to < stormer> Aside UDP of course < sjoerd> One of the nice things about GIO is to have these nice stackable streams, encouraging apps to use GSocket breaks that part < sjoerd> To give you an idea of the crack we might be doing in telepathy at some point: we want to create direct secure peer to peer connections through nat, for which we use a reliable protocol over udp (which can punch a nat).. Which in turn we want to expose as a GIOStream to higher levels < sjoerd> If we can just stack SSl on top of such an io stream that would be immensely helpful < danw> yeah... < sjoerd> That's a quite extreme use-case but still :) < danw> still no mclasen. guess we lost him for good < stormer> he said he had network issues < danw> yeah, he disappeared before but eventually reappeared < sjoerd> I guess it's basically impossible to target both TLS and proxy support for this glib round, so imho we should focus on getting the proxy stuff done < sjoerd> Shall i go through the bug and some of stormers code and maybe start a discussion on gtk-devel (or is there a better list for this) to see if we can get more attention to it ? < ebassi> sjoerd: gtk-devel would be good < danw> or d-d-l < danw> let me try to re-sum-up some of the issues in the bug < danw> i think i'm convinced on the socket vs socketconnection thing < danw> definitely feel free to look through the code though < ebassi> okay, we finished the items on the agenda - unless someone has new items (though we ran over the 2 hours mark) we can close the meeting for tonight? < danw> also, we lost mclasen, so... < stormer> good for me, danw we could start back on the mailing list tomorrow and start with the remaining issues, will let people think and have a look maybe < ebassi> right :-) < ebassi> next meeting should be july 6th < ebassi> then I guess we can have something at guadec < ebassi> depending on the attendance < ebassi> I personally look forward to a real-life gtk meeting; if it's like the past years, I'll bring knives and other weapons < jjardon> haha * stormer hmm wonders if GUADEC safe place to go finally ? < ebassi> jjardon: you weren't there in istanbul - that was fun ;-) < ebassi> it was the time when we started discussing the 3.0 roadmap < jjardon> ebassi, oh < jjardon> I understand now ;) < ebassi> have a good night/evening/afternoon everyone