Meeting on irc.gnome.org:#gtk-devel Meeting started September 13 2004 17:04 EST (21:04 UTC) In attendence: Anders Carlsson (andersca) Matthias Clasen (matthias), Owen Taylor (owen), Jonathan Blandford (jrb), Billy Biggs (vektor), Robert Ögren (roboros), Tor Lillqvist (tml), John Ehresman (jpe), Soeren Sandmann (ssp) bg damn focus bugs... ok, so I don't have any agenda items I'll probably do 2.5.3 releases at the end of the week cool I have changed the aliasing business to use the prefix IA__ instead of the suffix __internal_alias, and the if_fail() macros filter that prefix out now cool so one of owens complaints from last week is taken care of. would it make sense to do the same thing for higher-level libraries? (thinking gnome-libs here) but I have already seen a couple of missed includes due to gtkalias.h being all-inclusive (gmorten saved me) one idea which I recently had is that maybe gtkalias.h should be forced off while doing development, and only be effective for tarballs. that would at the same time fix the "everything always rebuilt" complaint and the "include rot" problem andersca: I think we should spend some more time optimizing the mechanism before applying it everywhere matthias: makes sense * tml has a slow machine and certainly wants to avoid unnecessary compilations tml: does the gcc you use support visibility ? If not, gtkalias.h is empty anyway ah, true hmm, empty or just bypassed as G_HAVE_GNUC_VISIBILTY is false? (haven't done a fresh build lately) tml: bypassed andersca: did you make any progress on goption docs ? docs would certainly help people to review the api... ...or even only try it... matthias: are we looking okay for docs for 2.6, btw? Last time I looked, it was in pretty good shape jrb: we're a bit weak for some of the new features. icon view needs a long description, file picker too, goption is undocumented, an we probably also want to maintain the migration chapter by adding section for each of the new widgets replacing a libgnomeui widget matthias: I've been pretty busy with other things, but I'll try to complete the goption documentation andersca: it doesn't have to be complete. If you commit what you have, I can help completing it without duplicating your current state matthias: did we get the visual index in? I forgot about working on it again jrb: it is in cvs, a bit incomplete, but its there same goes for the glossary which federico started matthias: cool jrb: cvs gtk-doc still uses the floating arrangement for the visual index. did you ever complete your tabular arrangement ? matthias: kind of I made it tabular, but wasn't happy with the results ah, that's right; matthias: we decided we needed to redo the images to make them consistent sizes jrb: ah, right * jrb should look into that, now that he's home jrb: and I wanted to look at getting gtk-doc to put the images on the individual refentries as well matthias: yeah that would be slick that reminds me that we failed to get a gtk-doc release out in time for gnome 2.8... can't we do one now? jrb: would the release team accept a new gtk-doc release at this time ? it would't fix any critical bugs... matthias: Intheor,y the gatekeeping is on the commit-to-CVS rather than the make-a-tarball matthias: So if there havne't been any commits since the code freeze date, it should be fine to make a new tarball matthias: yeah. should be fine owen: but the code hasn't been tested in any of the test releases, so that seems a bit illogical to me matthias: presumably jhbuild has been pulling it in all this time the gatekeeping really should be on the changes in the released tarballs, while it shouldn't be necessary to grind all of cvs to a halt. you can always go back to a tagged release... jrb: ah, ok. Well, Damon wanted to do a gtk-doc release in time for 2.8, and he has committed some changes recently, so maybe he still plans to do a release. tml: have you had a chance to look at my possible fix for bug #137551 yet? andersca: have you seen 152483 about alignment of icons in the icon view ? roboros: sorry, not really. roboros: btw, have you looked at bug #107320...? only briefly, I couldn't really reproduce the problem, but I can take another look at it it should be quite easy to reproduce, open a menu in a gtk app, then alt-tab to some other app. The menu stays open. ah yes, I can reproduce it so I can take a look at it, but it would be useful to know if my understanding of how focus events wrt grabs should work is correct or not (#137551) i did read quickly your patch for #137551 last week, but haven't tried or analyzed it more deeply yet. usually your analysis is spot-on, though, so i don't expect any problems... roboros: you want to study the specification of FocusOut in the X protocol spec. It is in freedesktop cvs somewhere...(volume 0 is out of print) * owen tends to think that going down the route of grabs on Win32 is a bad idea Though the alternatives are decidedly far more work roboros: http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/doc/specs/XProtocol/?root=xorg has the roff source, don't know if there is a pdf somewhere... isn't there postscript hardcopy in the X11 source distros? that's from where i printed my xlib and protocol docs years ago anyway tml: Yeah. (Note that the X protocol spec is different thant volume 0.) I'd also suggest reading the Xlib manual rather than the protocol spec, it also goes into obscene detail about focus events. what's "volume 0" btw? owen, don't grabs on win32 need to be fixed even if the menu code is rewritten? * matthias wonders how details can be obscene matthias: ok thanks, will dig through that and see what I can find out jpe: Well, maybe, but it's going to be hard to get them to work just like X. tml: the x protocol reference manual, part of the o'reilly series of x books (Actually, one trick I guess is that if a window is unfocused while it has a grab, we can pretend it was unmapped and then mapped again by the "WM" since that breaks a grab. But we can't do that for menus, because they are override redirect) owen, they can't work just like X and even if they could, it wouldn't be what users expect owen: so you think there should be code in gtk that handle focus changes in situations where there can't be any on x11 (because of grabs that actually prevent task focus switching etc) jpe: Remember for grabs, it's not what the user expects, it's what the *programmer* expects. We have to provide consistent programming guarantees on windows and X11 when at all possible. When user expectations differ, that needs generally to be handled at the gtk level (gtk level, as opposed to the GDK level) owen, I thought I saw another bug related to buttons changing sensitivity while an grab is in affect My feeling is that we generally should get to the point where GTK+ isn't doing any gdk_pointer_grab() calls when running on win32, though we clearly need to support it as best as we can for apps owen, yes it's what the programmer expects, but the expectation that grabs can't be broken isn't a valid one on win32 jpe: I'ts not totallyl valid on X either, except for grabs on override-redirect windows. And even for override redirect windows, a grab can be stolen by the *same* application jpe: So adding some sort of grab-broken event/signal may be possible/useful. I think it's mentioned in some opne bug owen, without gdk_pointer_grab what's the api for tracking the mouse outside of the window? jpe: When do you need to track the mouse outside the window? color selector? owen, when a menu is popped up jpe: (except for mouse-down-in-window before relase). Very seldom - color switch picker in the color picker about all jpe: you don't need to do that for Windows-style menus (click defocus and pops down and is passed through to the other app), and we should be matching Windows style menus owen, it's the mouse down in window before release that's the issue owen, I think gtk does need a grab-broken event or signal jpe: Well, it's tricky,certanlyl, but a GTK+ grab plus translating coordinates ourselves should do. (Emulating theX implicit grab is certainly necessary, but I think that's definitely easier) but alt-tab can also break the implicit grab if I look closely enough, I can see bugs that come from the implicit grab being broken without the mouse up event jpe: On X, if you have it around, try doing something that has an implicit tab then switching desktops with a key binding while the mouse button is still down (heavy objects to hold down the mouse button or gymnastic skills may be required) Sep 13 18:34:02 * tml imagines a fridge leaning on owen's mouse hehe owen, yup I see it owen, it's the same bug, only it's more easily triggered on win32 Sep 13 18:35:39 * tml wonders whether there ever will be a native Mac GDK backend. a potential porter would have to be ready to dig quite deeply into the xlib and/or x proto specs to understand the implied semantics. are there such people? jpe: So I don't have much of an issue saying that to get a widget exactly right you have to listen for a ::grab-broken signal or something like that tml, I don't think it would be that much more difficult than the win32 port (which I realize has been difficult) owen, yes, that's what we need * owen sends out the Pango-1.6.0 release announcemnet with a decidely *wrong* Subject: owen, there needs to be a way to generate it from gdk tml, the OS X backend would need the concept of the main menu to put at the top of the screen owen, should there be a gdk grab-broken event type? jpe: Quite possibly. owen, I need to run now, but I'll update the bug with a possible course of action owen: heh, Subject: Pango-1.4.0 released for pango 1.6.0 ;) ah you noticed already <-- jpe has quit (Leaving) are the exact semantics of the GDK_FOCUS_CHANGE event documented anywhere or must one infer them from the X11 specs and the GDK X11 backend src? like whether such events are sent only to toplevel windows or not yosh: It was "Press Control-return to send the message, look down at the tasklist, see "Pango-1.4.0 Released", fraction of a second see it vanish as the message went off roboros: Not documented anywhere I'm aware of. roboros: Note that GDK_FOCUS_CHANGE has a different meaning for toplevels than for other widgets... owen: ok, looks like I need to do a _lot_ of reading before I could even say whether my patch for #137551 is correct or not :( a golden opportunity to learn new stuff :) roboros: when reading the xlib and/or x proto specs you will notice how nice it is to actually have the behaviour of a windowing system specified that exactly. compare to microsoft's documentation, which is vague as hell roboros: write down whatever you learn - that'll make it easier for the next one tml: no arguing with that :) matthias: sure now I should get some sleep, nice talking with you people sov gott! tack! Meeting ended September 13, 18:58 EST (22:58 UTC)