Meeting on irc.gnome.org:#gtk-devel Meeting started May 4 2005 17:04 EST In attendence: Owen Taylor (owen), Maciej Katafiasz (mathrick), Billy Biggs (vektor), Tor Lillqvist (tml), Jonathan Blandford (jrb), Johan Dahlin (jdahlin), Stefan Kost (ensonic), Urr, sorry folks, my clock is messed up on my computer. Still 20 minutes OK, let's get started now Matthias couldn't make it this week, so I'm goin gto run the meeting Matthias suggested topic was "accumulated patches, important bugs" owen: do we get to play with yarrr this week, or no funk today? So, everybody propose bug #'s they'd like to discuss and we'll just go through them I'm still planning to post a patch for z-order support in GDK, I still have time for 2.8 right? http://mail.gnome.org/archives/gtk-devel-list/2005-May/msg00004.html #58541? owen: ah vektor: Yes, we don't API freeze until July 1 (though it would be good to get something posted considerably before then) #166020 ( just interested in the status of it, I don't plan to do any work) owen: That's great, thanks. owen: July? I thought it was June Either way I have time :) jdahlin: depends on how big a z-order patch vektor is proposing ... http://www.gtk.org/plan/2.8/ 166020 (atomic refcounts) we can't really discuss since that is blocking on rambokid owen: The patch will be quite small. mathrick: no yarrr this week, though we'll probably try again next week mathrick: though we think we tracked down the memory leak Three bugs that mclasen mentioned to me were #171541 (gtk_window_present/gtk_window_focus), #153966 # 301651 (notebook prelighting) owen: does that mean we're going to miss gnome 2.12? (what *is* yarrr, btw, the only thing google found was stuff about pirates...) jrb: mhm, gotcha tml: verbum.org:8080/yarrr/ tml: http://live.gnome.org/_e2_98_a0 jdahlin: gnome-2.12 code freeze is mid-july, so if we stay on schedule, we'll make it http://mail.gnome.org/archives/desktop-devel-list/2005-April/msg00017.html - I'm assuming that is still current OK, let's start talking about the mentiotoned bugs ... keep on thinking of more bugs to discuss :-) http://bugzilla.gnome.org/show_bug.cgi?id=169463 tml: The plug socket bug (58541) is basically just waiting on another review from me, right? owen: yep Were there things about it you wanted to discuss? not necessarily, just a review in bugzilla would be fine In terms of the X11_EMBED_MAPPED stuff, you can either gtk_widget_show() a plug before or after you add it to a socket It must not show up until you show() it and it must show up after you show it it does testsocket test that? tml: properties work well for doing that, but there are probably other ways as well http://bugzilla.gnome.org/show_bug.cgi?id=139486 , is there anyone besides mclasen who intends to work on introspection stuff? It's big change, we need to have some kind of schedule to make it in time for 2.8 tml: How are you handling geometry hints mathrick: He's looking for volunteers to help out. owen: I know, that's why I asked owen: i can't remember right now ;-= tml: They should be pretty similar owen: I want to help, but I'm rather busy, so I need to know how hard I should try to free up some time oh, so you mean geometry hints in general, not in gtkplug/socket context Oh, GetClientRect(), which I commented as wrong in my first review patch :-) tml: review pass tml: no, specifically in the plug/socket context mathrick: I think it's basically just matthias at the moment. I'd like to get some language binding people testing it out, but nobody has really taken the bait on that yet mathrick: And there is a fair bit of work before it is usable for that owen: yup jdahlin: do you count as language binding people? tml: The point is that if I do gtk_window_set_size_request() on the plug, it should propagate as the size request of the socket jdahlin: do we have anyone in pygtk who could take a stab at it? mathrick: I know what I need to have for python, not sure about the others mathrick: might be good to have murrayc and someone else to look at it aswel l One way you could approach language bindings a littel easier would be to take some small library (perhaps not yet bound) add introspection to that, and try to get that going, rather than starting off trying to convert GTK+ over jdahlin: that's what we want, someone who knows his stuff and is willing to spend at least some time prototyping owen: yes, definitely, but glue still needs to be pretty complete and it's gonna take up some time mathrick: it looks very unfriendly, probably a fair amount of work needs to be done to make it bindings friendly jdahlin: you mean mclasen's proposal? mathrick: Well, hyou could hand-write the XML for a small library, which would theoretically make the stuff that is there now almost sufficient mathrick: no the glog api owen: I mean glue on language side jdahlin: ah jdahlin: that's unrelated though, I wonder if you mixed things up? mathrick: perhaps I did jdahlin: glog poses some serious problems in C too .... one of the big ones being that it is baiscally g_log() on steroids and uses many of the same names (as glog_log or whateve,r but when moved back to GLib...) Anways, that wasn't the topic at the moment sorry, my fault jdahlin: I was asking for someone who could try and approach introspection from pygtk side, and prototype implementation based entirely on introspected stuff jdahlin: you're rather busy AFAIK, gjc is too, jamesh too mathrick: I think we need to write a header scanner first, so we have some actual data to display s/display/use/ jdahlin: data can be fed by hand initially jdahlin: or from hand-tweaked .defs owen: the names in glog don't matter, but keeping gst_ prefix was bad, too * Company stops being off topic again jdahlin: much more challenging is the dynamic invocation and whole creation of bindings at runtime Company: What I'm just saying is that it would be hard to integrate it in a way that both it and g_log() make sense in the same library owen: I've been wanting to write python bindings for poppler for a bit jdahlin: however, it's a valid point, glog isn't bindings friendly owen: it might be a good candidate for testing jrb: Hmm, is poppler small and nicely bindable? mathrick: I'm pretty sure that won't be so difficult, at least not for python owen: almost. which is almost? owen: it's small and nicely glib-ized I wonder if there are any big non-gtk users who could screw us up owen: the only thing I'm concerned about is that there's a union * mathrick points at gstreamer jdahlin: you think? could you do that? glog was never supposed to be bindings friendly Company: that shows after all, g_return_val_if_fail isn't in the bindings either it's a debugging library for C * tml would drop the colour crack altogether but glog does things that make perfect sense in non-C Company: you want logging in Py as well mathrick: yeah, but in py you log with py logging tml: the colour code is nice when you parse the output on stderr Company: well, yeah, but if you're writing py gst plugin? what do you use then? tml: it is useful OK, I wasn't really planning to discuss glog here ... I haven't had a lot of time ot look it over yet * tml is just oldfashioned and not accustomed to coloured text coloured text somehow strikes me as old-fashioned ... belongs on a bbs or something :-) owen: i actually wanted to bring glog up at guadec Moving along the list of mentioned bugs matthias mentioned http://bugzilla.gnome.org/show_bug.cgi?id=171541 owen: when i was young terminals where black on white. paper that is. later green on black glass. owen: That's a big scary issue. Company: which reminds me, I don't suppose you looked at http://bugzilla.gnome.org/show_bug.cgi?id=139486 ? It'd be nice to look over gst and see if there isn't anything introspection-unfriendly, and currently you're the second one besides jdahlin who is best qualified for that :) vektor: You know, eclipse is an excellent motivator for making gtk_window_present() a no-op :-) * ensonic belives it would be useful, if anyone who knows the API could just spend a little time to fill docu gaps ;) owen: We never call gtk_window_present(), and I can't figure out why eclipse is switching desktops for some users. It still seems like a weird side effect for gdk_window_focus(). vektor: Could you be unmapping and mapping? vektor: It's doing *something* on async completion that is causing it to hop desktops. Anyways, off topic here unless we know what in the GTK+ API is doing it :-) I don't really have the background to comment on 171541 ... my general feeling is that if you *want* a window to hop desktops, you shouldn';t be using gtk_window_present() you should be writing more directly to the _NETWM apis. So, my inclination would be to close it. gtk_window_present() is still doing something that basically corresponds ot the docs. And it really isn't any GTK+ change anyways. The work that ssp has been doing on notebooks really needs to be written up for gtk-devel-list (two of the bugs mentioned above), so I think I'm going to skip it here jrb: http://bugzilla.gnome.org/show_bug.cgi?id=169463 - your issue owen: I haven't looked at that yet * jrb reads now wow, now I notice status of bug is displayed in header w00t when did that get added? mathrick: I would have thought it's been there for a long time, but I'm not really sure owen: gdk_window_focus() is what causes eclipse to switch desktops, or cause a desktop switch. jrb, in case you have comments on 169463, 302153, I am the submitter ;) vektor: Hmm, gtk_window_present() baiscally just calls gdk_window_focus() with the comment /* note that gdk_window_focus() will also move the window to * the current desktop, for WM spec compliant window managers. */ Which seems quite surprising and confusing to me. ensonic: lemme read the patches If I hae an application with two windows, and I want to give one of them focus, calling gdk_window_focus() seems reasonable to me. matthias's introspection stuff never made it into CVS, did it? But having it switch desktops seems odd :) tml: answering your mail about glog now, ask Company for specifics, he's the boss here vektor: Well, perhaps it's not suprising ... it would be just as bad if the eclipse window was buried and popped up to the top, pretty much (the new behavior of switching desktpos is clearly better than the old version of hopping desktop ... I might even not mind switching desktops that much) owen: you will We're not supposed to call gdk_window_focus() in our code if one of the windows from the app doesn't already have focus. The bug is actually that the eclipse window thinks it has focus, even after it lost it. This is due to our workaround for that big nasty bug with the ion/firefox people complaining on it. vektor: bug workarounds always cause more problems vektor: When does eclipse have more than one window? vektor: Would it be better to grab focus then? Just dialogs, actually. vektor: So, then the dialog you are working on gets unexpectedly buried ... I don't think I understand exactly the steps that eclipse the app is doing to have this happen, so I don't think I can give you a straightforward use case. However, we do use gdk_window_focus() when you have two windows, focus is in one of them (supposedly), and you want to give it to the other one. Bugs in eclipse: 1. we think we have focus even if you've switch to another desktop 2. we call this when some dialogs close vektor: Well, I guess there are multiple problems here ... eclipse the app is doing something bad, and then GTK+ has a focus bug, and swt works around that and causes problems therefore, you can be off on some other desktop, and eclipse will either pull you back, or switch to the other desktop. Right. vektor: The focus when you switch to another desktop should have been fixed in GTK+ a long time ago (last time I tried to fix focus problems) owen: Do you understand FocusIn+NotifyPointer ? :) vektor: it used to always do that ... now it just sometimes gets a bit confused vektor: I thought I perfectly understood it fo ran afternoon, made GTK+ "perfect". The knowledge all pooled and ran out of my brain. Then I discovered GTK+ still had problems and wasn't perfect vektor: I suppose I should sit down, read through the angry-icon-users bug report and try to reconstitute the knowledge It's a hard problem, I think it takes more than one mind. ion-users ,that is I wasted a few hours on it on the weekend, along with my good friends xev and X-without-WM. jrb: Any progress on ensonic's bug report? Emp. on wasted. If focus mode goes to PointerRoot then GTK+ isn't confused to think there is no WM running, but when another window gets focused, it should recover from that owen: I think it's wrong that you can get has_pointer_focus to true from a FocusIn+NotifyPointer event, since I don't think you're guarenteed to get a corresponding FocusOut with that detail. However, I'm really unsure, enough that I can't really back up that claim. owen: reading the second one right now vektor: Well, has_pointer_focus is right, right? owen: I'm not sure, say focus went to PointerRoot but the pointer was above you at the time, is has_pointer_focus right then? vektor: I think so ... it's just like the no WM case vektor: You have the focus but it wasn't explicitely set to the window, so when you get a LeaveNotify you should unset the focus and generate a GDK focus out OK, so how will it ever go FALSE? :) vektor: See handling in LeaveNotify OK but won't has_focus_window be true then? And then the event won't get processed. vektor: It shouldn't be, no. Why would it be? I can't really discuss this in any productive way, requires a specific case + specific WM to understand, and then once you solve that case you have to move on to the next and make sure it's solved there too. vektor: Well, I spent enough time on the current code to hope that there isn't more than *one* bug there owen: Well, at least some problems seem to stem from override_redirect windows, so like when the alt-tab window appears, you still have focus vektor: The GTK+ code is menat to be entirely independent of whatever the window manager is doing I guess you're right, I see what you mean. If you get focus from a FocusIn+NotifyPointer, the pair should be solved by a LeaveNotify. vektor: It's supposed to give you an authoritative answer to "is this window getting key events" by tracking X messages ... no matter what WM craziness is going on So, looking at your test case, the reason XSetINputFocus is different from gdk_window_grab_focus() is just the GTK+ bug that you can't use _NET_WM_ACTIVATE on an override-redifrect window The problems all happen for us when that window is destroyed. is your test case expected to misbehave with metacity? Yes. vektor: And what in particular should I see go wrong? um I'm just trying it now on FC3, seems to be different from RH9/RHEL3. vektor: I think havoc added recover-from-pointerroot code at some point I can't remember, lately I've been testing with eclipse. I think the behaviour of it being in pointerroot mode was weird, but not ever really the problem we saw. I just figured it was related. vektor: So it coul dbe that with RH9/RHEL3 the system really *was* in PointerRoot mode and GTK+ was just reflecting that correctly I mean, it is related. Yes. Why do you think it is related? Because I instrumented the has_pointer_focus / has_focus / ... in gdkevents-x11.c, and was able to get GTK+ into a state where has_pointer_focus was true and never went false. Then I laboured away to try and produce some sort of C test case, which is what you see there. :) So far nothing in that bug report or the linked to bug reports has convinced me that it isn't the *window managers* that are getting confused jdahlin: poke What's the observed problem with Eclipse? Just the workspace hopping? (Of course, gnome-terminal does get confused ... I see tha tmyself, so I can't claim that GTK+ is bugfree) owen: Isn't this the classic problem? :) Eclipse blames SWT, SWT blames GTK+, GTK+ blames the WM, loop :) The original problem with Eclipse was that you'd give focus to an override guy, he'd disappear, and eclipse would not have focus. The WM would think it has focus, but it wouldn't. We fixed it by having an X event filter, and modifying some X focus events to trick GTK+. By "disappear" - you mean that the WM woudl raise the main app above it? mathrick: peek How could tricking GTK+ affect the WM behavior? This has the side effect that eclipse thinks it has focus more often than it does, like sometimes when you alt-tab away or switch desktops. vektor: OK, so you broke the carefully constructed state machine in gtkwindow.c... vektor: gdkevents.c, I mean jdahlin: so, can you be the person who gets bugged when something needs to be written for introspection bug in pygtk land? or should I seek someone else? vektor: So, debugging the *current* state of eclipse isnt' useful... to debug, you'd have to go back to the original state owen: No, you misundersand. The case was: give focus to an eclipse tooltip. Destroy the tooltip by hitting ESC. Eclipse has focus according to the WM, but not accorind to GTK+. owen: Right. vektor: Who had focus according to *X* ? mathrick: try me, I'll see if I have time vektor: That is, who was getting keystrokes jdahlin: k, word if not I'll provide you with the necessary delegation :-) jdahlin: good vektor: GKT+ is trying to track that, not what the WM thinks does muppet IRC? owen: I don't know, maybe the root window (RevertToParent, override's parent is the root?) vektor: If it was PointerRoot, GTK+ should have thought that the window had focus It woudl be the no-window-manager case It would only happen when the pointer was above the override redirect window when it was destroyed. That's a separate case from the pointer being above the eclipse window, or the pointer being above another app. ensonic: I'm not 100% sure that your fix to 302153 is right vektor: Did the focus mode of the window manager matter? owen: Kind of, our override guys with focus don't work very well though with focus-follows-mouse anyway though, since they list for focus lots and destroy themselves. :) In standalone test cases, I cant remember. ensonic: eg, if all cells are inert, then we keep track of column focus so that you can scroll right/left vektor: "with mouse focus" ? owen: You're convincing me that I should be tracking X focus when I try and construct cases, as the GTK+ state may be correct, but the WM state might not be. ensonic: also, the A11Y support expects to be able to move focus to a column owen: Fuck, since the listen for focus lost events and destroy themselves. Am I making sense here? My typing seems to be getting worse as I try and read source code while thinking and discussing on IRC all at once. owen: Would you have time to discuss this again tomorrow? vektor: Well, I guess what I'm saying ithere are three things that need to be in sync, and looking at the color of the border won't necessairly tell you the what window has focus vektor: Hmmm. Maybe in the evening If you catch me after 4:00 tomorrow I should have time then OK. I'll pull out our workarounds and check all of the cases on a newer metacity, and this time I'll pay attention to where the X focus is specifically. jrb, A11Y ? ensonic: Accessibility jrb, best is probably if I break down the patch in some cleanups first (like using g_list_find, getting rid of the goto etc.) ensonic: sure. jrb, I'Ve discussed this with a friend today and we came to the conclussion that allowing single cells to be INERT (unfocusable) is difficult to handle jrb, it would be better to set a whole column unfocusable jrb, I'll post the scenarious to the list soon jrb, any idea about 169463? * owen starts to give up and download and compile ion, then realizes it requires lua and backs off jrb, will go to bed, please post comment to bugzilla Meeting ended May 4, 18:40 EST