Meeting on irc.gnome.org:#gtk-devel Meeting started October 05 2004 17:02 EST (21:02 UTC) In attendence: Owen Taylor (owen), Jonathan Blandford (jrb), Manish Singh (yosh), Shaun T. Amundson (Snorfle), Tim Janik (rambokid), Federico Mena Quintero (federico), Anders Carlsson (andersca), Matthias Clasen (matthias), Robert Ögren (roboros), John Ehresman (jpe), Sven Neumann (neo), Federico Mena Quintero (federico), Carol Spears (carol), Elijah Newren (elijah), Carlos Garnacho (garnacho) Impressive roundup of GTK+ oldtimers today... :-) i plead to put #145270 on the agenda. * rambokid goes gets some food yosh: ops! ok, so let me list my agenda items: website move/reorganization (Snorfle) clipboard api (andersca) icon caching HIG dialog api (garnacho) EWMH take activity patch (Eliah Newren) sounds good and then there is release timing, as always. Maybe we should start with that. I want to do 2.4.x releases of glib and gtk+ this week, so that they are ready in time for 2.8.1 If there are any urgent fixes which should really be in the next 2.4 release, please bring them up. I plan to do the next 2.5.x releases sometime next week ok, if nobody has issues with that, maybe we can move to website move/reorganization. Snorfle, do you want to outline your plans ? mclasen: i plan to merge down the sizing fix to 2.4 once i got a hold on owen. other than that, i'd like to finally fix #145270. can talk about that later with owen alone if nobody has input on that though. owen is theoretically in here... I am here owen: ok. want to defer talk about the two bugs util after the meeting? rambokid: Probably best to handle other issues first. I responded and said "go ahead and merge to 2-4" on the NEED_REQUEST issue, though so, since Snorfle doesn't seem to be here, let me repeat what he said to me earlier: he will move the gtk.org site to a different host (and move it physically from berkeley to michigan) owen: ah, haven't seen the reply yet. and he also asked me what I think about converting the web site to a wiki mclasen: I 'd sort of like to know more about the reasoning for the move. There would be something to be said of switching gtk.org to the gnome.org servers if we are going to move it at all mclasen,snorfle: hm, is there any need to physically move the site? owen, rambokid: I don't have any insight in that... In terms of a wiki - in some ways, I think it could be a lot better. I'd like to see it at gnome.org too owen: i'd start out with a few wiki pages first, and not move the whole site. owen: but converting things could be quite a bit of work. Right now, the web site is kind of low maintainance... jdub has grandios plans for converting developer.gnome.org to a wiki, so there might be possible coordination with that mcalsen: Yeah. wiki's are not lower maintainence than regular websites, just different maintainence Let's give Snorfle some time to show up again and talk about other issues ok, andersca, do you want to talk about clipboard handling ? Is that something we should discuss here ? yes so, I've been doing some work on the clipboard support I've written up a doc which can be found at http://andersca.org/stuff/clipboard/clipboard-enhancements.txt and I'd like to hear your comments, and if this is something that can be put into gtk 2.6 andersca: I think there are basically two independent parts here, right ? tracking supported targets, and persistance yeah andersca: the tracking of supported targets looks like a clear 2.6 candidate to me. The challenge with the persistance part is that you need a clipboard manager to make any use of it andersca: and we need to pick up the discussion of the clipboard manager spec on xdg-list again and actually move the spec to f.d.o and write a reference implementation of a clipboard manager mclasen: I've tried these changes with your reference implementation and fixed a few bugs in it andersca: do we have any idea how many apps quit by calling exit() versus gtk_main_quit()? jrb: they can call gtk_clipboard_store explicitly... andersca: how well does calling clipboard_store() from main_quit() work in practise ? mclasen: I made set_text call set_can_store, and that made pretty much all basic applications work wrt text mclasen: so I'd say it works pretty well I don't like calling store() from main_quit() owen: I kinda figured you wouldn't like that Thoughh maybe I'm favoring cleanliness over easy-of-use... owen: it's a bit dirty yeah, I mean owen: do we have a cleaner alternative ? owen: we start up a new main loop to wait for the clear_selection event mclasen: Well, the clean equivalent is just to require every app to make some call... owen: that was my initial idea owen: and then I thought "hmm, we could make this work automatically by adding it to gtk_main_quit" the accelerator map also requires an explicit call to be saved. andersca: Are you triggering off main loop level to catch rescursive main loops? owen: yes in order for people to know that, the docs for accel-change related functions point out the need to call the function explicitely rambokid: clipboards are more commonly used than dynamic accel maps, people expect their apps to store the clipboard when their applications exit... andersca: you really use gtk_main_quit, and not a gtk_main quit function? rambokid: + + if (gtk_main_loop_level == 0) + _gtk_clipboard_store_all (); andersca: I'd say its tentatively an OK thing. I think the number of apps that use multiple calls to gtk_main() *and* have different clipboard levels is small. andersca: i think it's the same scenario, because when you enable dynamic accels, you also want every application to save the accels away. Oct 05 17:37:11 * Snorfle returns andersca: *where* is that code? rambokid: at the end of gtk_main_quit owen: nod gtk.org is moving to U of MN CS dept Snorfle: Well, you own the domain... but... :-) owen: what do you think about the rest of the proposal? Snorfle: Maybe it would be good to have some background? the only thing I haven't implemented here is the TARGET_SIZES support the ongoing stability problems of the machines at XCF are a major problem I am pouring some money into machines well, one machine :-) yosh: can you give some input on the stability issue? other than the new machine I got having issues, the *current* machines are stable Snorfle: Hmm. It's great that you are volunteering, I'm just wondering if the gnome.org servers make more sense? Since any GTK+ developer already will have a ssh key there, etc. well, this is eventually going to be a gimp.org move as well Snorfle: well, supplant rather than move wholesale, cause a wholesale move doesn't make much sense Snorfle: and beast, and evilplan, and etc...? what exactly are your plans? andersca: I think we should get the target tracking in for 2.5.4, and move the persistance spec to f.d.o, together with a the reference implementation of the clipboard manager. Once we have the spec on f.d.o, we can look at the GTK+ side of the persistance support again, and decide whether doing it automatically is acceptable or not... mclasen: ok mclasen: I'm going to write some tests for the clipboard manager too (this is paid work) rambokid: any free software site currently on wilber can move over andersca: hey, cool mclasen: anyway, do you think it's ok if I put up the latest version of the clipboard manager spec on fd.o and then post it to xdg-list mclasen: I have some additions to it, and I'd like to discuss those on xdg-list andersca: when I was last working on this back in May, lubos agreed to replace his current (unimplemented) clipboard extension with my spec mclasen: cool mclasen: the changes are just minor clarifications andersca: I think it would be good to announce on xdg-list that you picked up the ball, and discuss the remaining issues cool andersca: but that shouldn't stop you from putting the spec on f.d.o, if you can get cvs access... (sorry, work keeps interrupting) mclasen: the web page's a wiki, right? ok, further input on the website discussion, or should we move on to the next topic ? andersca: yes mclasen: cool, I'll send mail tomorrow mclasen: I guess the question is how we move forward on the website topic I'd like to drive it forward, as in times of old, and I'm hoping you guys will trust me to do that with the interests of the project in mind. What do people think - would they have a preference to see gtk.org move to the gnome.org servers? Would they dislike that? Do they care as long as the autocheckout still works? I wouldn't mind having it on gnome.org It'd make it easier for people in the team to do releases Hmm, I think we are mostly talking web here, not ftp. (ftp would also move) ah Snorfle: Certainly we'd be glad to see help on the website, and I'd trust you pretty implicitly to do the right thing :-) I think we can make a better website for www.gtk.org and www.gimp.org, and I've been pondering this for a *long* time The main concerns I'd have would simply be access to the machine, especially if you start having less time again, and whether gnome.org hosting would work better with the other infrastructure that people use. owen: I don't care where it is hosted, as long as updating is not less convenient than the current cvs-based setup Snorfle: does this mean you will be more involved than you have been? carol: obviously Snorfle: that would be very nice. it would also have been nice (since i have stayed involved) to hear of these plans before a gtk-devel meeting It would be a little hard to do worse than the the current gtk.org ... OK, plan/ works fairly well, there's a link to the API docs, there's a link to the ftp site, there's a link to bugzilla, but other than that it's not much of a resource for developers owen: do we *have* much more content to put in a new site than that ? I mean, there are misc tutorials for gobject and treeview somewhere else on the web, but we link to most of that material now I like the idea of a wiki for the site, perhaps; and I want more content on www.gtk.org and less links. My initial vision of www.gtk.org was much more grand than it is today. (than www.gtk.org is today, not my vision :-) Snorfle: I guess the bottom line is that if you have time and ideas to work on gtk.org, you really should be driving the technology and location. the other topic is license of site content that needs to be clarified I am going to setup RT and respond to webmasters (unlike now), and one of the primary questions is "can I use this" and the like actually is a nice thought here that someone might renew some of those ideas they had when they were first thinking about things with this gimp* stuff :) Snorfle: do you have any interest in working within the current gnome.org framework? There's a good amount of infrastructure there what I'd like to avoid, and this is probably more a concern on gimp.org, is contributions which do not have a clear license cgo is being used in classrooms throughout the world Snorfle: Well, if we go with Wiki, there isn't going to be a clear definite licesne ... the best we could have is some vague click-through when you register with the Wiki I thought it would have been interesting if gnome.org had started out on gimp.org or gtk.org owen: seems to work for wikipedia the largest content on the current site with unclear license is the api docs owen: an author of gimp.org content threatened to remove it, and that bothered me; I want a more clearly stated policy that contributed work is going to exist in the future http://creativecommons.org/license/ owen: given, I'm not worried about that looking at the gtk.org ChangeLog, but trying to get more content contributors will make it more of an issue owen: handling things the way wikipedia does should be good enough. it's not like this would be a new, unique and unsolved problem on the web... rambokid: THere is also php.net as precendent - not sure what they do http://creativecommons.org/technology/web-integration yosh: BTW, have you had reports of recent connectivity problems ... gtk.org isn't accessible from here, but it is from, say, NC owen: nope. traceroute? Snorfle: The activity on the gtk mailing lists is actually very good at the moment ... I get the feeling there are quite a few people out there with lots of knowledge they want to share. Having some forum other than constantly repeated faqs on the mailing lists would be good with as heavily linked as www.gtk.org is everywhere, I think it deserves a bit of serious loving 11 CENIC.hsa1.Level3.net (209.247.159.110) 102.495 ms dc-svl-m10.cenic.net (137.164.12.170) 133.154 ms 93.842 ms 12 inet-ucb--svl-isp.cenic.net (137.164.24.106) 134.835 ms 116.354 ms 112.628 ms Stops there owen: and from NC? Goes through cenic, but on a different route 10 hpr-lax-gsr1--abilene-LA-10ge.cenic.net (137.164.25.2) 75.199 ms 75.257 ms 75.283 ms 11 svl-hpr--lax-hpr-10ge.cenic.net (137.164.25.13) 82.783 ms 82.802 ms 82.807 ms 12 hpr-ucb-ge--svl-hpr.cenic.net (137.164.27.134) 84.176 ms 84.261 ms 90.760 ms 13 vlan187.inr-201-eva.Berkeley.EDU (128.32.0.33) 84.116 ms 84.139 ms 112.303 ms 1 ok, I fear we're running out of time. Lets go quickly over the remaining issues before staring at traceroute logs... <-- elijah has quit (Ping timeout: 600 seconds) mclasen: Right Regarding icon caching, I think we should try to get that into 2.6, I will try to get the file format written down and published on f.d.o, and I want to get the icon cache patch into gtk+ relatively soon, probably not in 2.5.4, but in 2.5.5 if anyone wants to personally flame me for my ideas, just fire off an email :-) so please, test it and check that it actually works as promised... the next topic is the HIG dialog api, for which garnacho sent another take to the mailing list some time ago... I think our consensus was more or less to keep authentication (and more general add_widget()-type things) out of the simple message dialog api Snorfle: I don't really understand your ideas. Perhaps a message to gtk-devel-list about what you have planned would be good If there are no other issues with the latest iteration of the HIG dialog api, I would like to include that in 2.5.4 The new API is just gtk_message_dialog_format_secondary_text() ? (and format_secondary_markup()?) mostly yes And if you call this, the normal text automatically gets reformated as bold/larger/whatever? mclasen: what somewhat worries me about not adding some kind of _set_extra_widget() is that some apps (such as nautilus) will still use their custom dialogs but as you say maybe it's nice to keep the API simple garnacho: So? owen: yes What happens if the primary text is markup? How do you integrate the two? One obvious question is that we have set_markup() now ... do we want to deviate and have the different format_secondary_* names? Oct 05 18:18:23 --> elijah (~None@amr.math.utah.edu) has joined #gtk-devel for the same printf() style operation (This hsa all been discussed before, I think. BUt I've forgotten...) owen: set_markup() doesn't take varargs Snorfle: just for the record, you could paste your email here mclasen: What's the ... for? owen: void gtk_message_dialog_set_markup (GtkMessageDialog *message_dialog, const gchar *str); no ... here yeppers! carol: amundson@ any of the domains like gtk.org or gimp.org mclasen: it's in my proposal, I commented it in the past iteration oh, I see owen: is_viewable walks "parent" but checks "window" on each iteration Oh, carlos's header is a little munged there rambokid: Wait, I think there is a patch for that in bugzilla somewhere Snorfle: thanks :) kinda silly... rambokid: Yeah, and amazing that it has been that way for 4 years or so yep ;) Don't see it in bugzilla. garnacho, owen: I don't think we can compatible turn set_markup() into a varargs function, can we ? mclasen: No, we can't no? oh, my fault garnacho: Leaving calling conventions aside, what if someone had a % in their markup? owen: if we don't convert set_markup() to varargs, the naming difference between set_markup() and format_secondary_markup() becomes an advantage... hmmm mclasen: Yeah. The format() names I think are right anyways. mclasen: We'd probably want to add at least format_markup() though. one could conceivably add format_primary_markup() or that garnacho: In general, I think the current api of simply adding setters for the secondary text and "doing the right thing" is a convenient one I think we should try to land this in the next week nice :) I'll work to on the gtk-demo stuff, and add doc for the new API ok, I have about five more minutes before I have to run out...the last topic I had on my list is the take activity patch, and thankfully elijah is here today... :) Was I supposed to be here before? (Sorry, if I was--I didn't know) elijah: no idea, I just noticed you here. I guess if you don't know, its just a lucky coincidence... Well, Ithink your item is the only one on the agenda we haven't gotten to yet Though it's getting a little late for extensive discussion yes. The patch needs more work anyway, since it currently hardcodes the dnd threshold. What I want to know is whether the patch implements something which is already in the current EWMH draft ? Does KDE have an implementation ? http://mail.gnome.org/archives/wm-spec-list/2004-April/msg00013.html It is a bit too much like the gross hack that lubos had for Qt to maek me like it much Oct 05 18:32:41 * elijah checks the EWMH and is suprised to find it isn't there yet crap ooh, see also http://mail.gnome.org/archives/wm-spec-list/2004-October/msg00001.html elijah: I think the hardest part of f.d.o work is figuring out how to update the stuff on the website... anyway, I really have to go now. Feel free to continue the discussion, I'll keep the logs and put them on www.gtk.org tomorrow... summary of those emails: Lubos had an implementation for KDE months ago, Havoc just recently responded and asked to get it in the spec. Any quick pointers on how to get rid of the hard-coding of the dnd threshold in the patch I have? elijah: It has to involve the GTK+ layer, IMO What I don't understand really is what the relationship of the _NET_WM_TAKE_ACTIVITY message to the button press is That's not realyl specified in Lubos's patch to the EMHW rambokid: BTW, if you are still around - you'll take care of fixing up is_viewable()? As far as I understood, that's when the window manager sent the message to the client; the client merely updates the starting-drag-position upon ButtonPress. owen: yes. just got something to ddrink So how should it involve the gtk+ layer? That is, how is that implemented? (for the clueless gtk+ newbie) elijah: I need the information about what he relationship of this message is to press and release events to answer that WM receives ButtonPress -- sends TAKE_ACTIVTY to client. client receives ButtonPress -- it updates drag-start-position. But the button press has to also go to the client, right? Does it get received before or after TAKE_ACTIVITY? Don't think it matters. Definitely hsa to be specified Okay, for now, assume it's: 1) WM gets ButtonPress first, sends take-activity message to client 2) client gets ButtonPress second, records new drag-start-position 3) client receives take-activity message from WM then, later, client receives ButtonRelease and determines whether to return a take-activity pong to the WM. Here's one strawman (names not thought through). We add gdk_event_get_is_activate_click() If a widget (or here, the DND code) gets a "activate_click" message, they can call gdk_event_set_activate_pending() - if they call that, they are responsible for, on the paired release, calling gdk_event_activate_end (gboolean do_activate) If the widget doesn't call set_activate_pending() then GDK will handle sending _NET_WM_TAKE_ACTIVITY on the release, otherwise GDK sends TAKE_ACTIVITY only igdk_event_activate_end() is calledf Or, it could be even simpler. We simply add gdk_window_cancel_activate() - if that is called between a button press and a button release then GDK cancels any pending _NET_WM_TAKE_ACTIVITY messages gdk_window_cancel_activate is much closer to the current patch and what I had in mind. gtk_drag_begin() could even call that automatically Anyways, the point is that the *policy* must be at the GTK+ layer. What lives at the GDK layer should be simple, and shouldn't worry about things like dnd. So, the basic idea is add a gdk_window_cancel_activate() function (should that be gdk_x11_window_cancel_activate?), have gtk_drag_begin() call it, and then start searching for other special cases that need it (moving sliders at least a minimum distance, etc.), and remove the dnd stuff in my patch from gdk... Is that right? elijah: I'd make it generic ... if it is called from GTK+ it has to be generic elijah: Though it would be very much worth your time to see what sort of API windows has in this area OK, think meeting is over Meeting ended October 5, 19:10 EST (23:10 UTC)