Issue 96 in xmonad: certain dialogs get dropped in gnucash
Issue 96: certain dialogs get dropped in gnucash http://code.google.com/p/xmonad/issues/detail?id=96 Comment #4 by jcreigh: dons on #xmonad requested a little more detail on the resolution of this bug, so this is my attempt to clarify matters. The version of Gnucash I tested against was 2.2.1 The issue was that xmonad was unmapping a window when it received a synthetic UnmapNotify event but when the (real) UnmapNotify response came from xmonad's UnmapWindow request, xmonad was failing to ignore that event. This gets us in trouble with Gnucash, which, for some reason, sends, one after the other, a MapRequest, a synthetic UnmapNotify and then another MapRequest. So xmonad would map it, unmap it (which generates an UnmapNotify, but we won't get it until later) and then map it again. Shortly thereafter the UnmapNotify would arrive and xmonad would unmap the window. The solution was to change "unmanage" (which gets called on unmap when we aren't expecting any events) to not clear the waitingUnmap number for that window and instead do that on a DestroyWindowEvent so that the UnmapNotify from an unmapping that we request will be ignored. This fix leaves a little something to be desired in that there is a slight flicker because the window gets mapped, unmapped, and then mapped again, but seems like a very minor issue to me and I don't see what we can do about that without getting into some sort of stateful event handling system. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
On Wed, Dec 12, 2007 at 05:35:16PM -0800, codesite-noreply@google.com wrote:
Issue 96: certain dialogs get dropped in gnucash http://code.google.com/p/xmonad/issues/detail?id=96
Comment #4 by jcreigh: dons on #xmonad requested a little more detail on the resolution of this bug, so this is my attempt to clarify matters. The version of Gnucash I tested against was 2.2.1
The issue was that xmonad was unmapping a window when it received a synthetic UnmapNotify event but when the (real) UnmapNotify response came from xmonad's UnmapWindow request, xmonad was failing to ignore that event.
This gets us in trouble with Gnucash, which, for some reason, sends, one after the other, a MapRequest, a synthetic UnmapNotify and then another MapRequest.
I've said this before, but it bears repeating: this looks an awful lot like Gnucash is doing something wrong. Why would some dialogs but not others generate this behavior? It must be something internal to gnucash that is broken or at least odd. GNucash only fairly recently completed the transtion to gtk2.0 and it's likely that some problems exist. WHat sort of things would I look for in Gnucash that might cause this? Is it the type of thing that might be caused by some spurious extra call to a window creation routine, for example? If I get some decent pointers, I could dig into the code and try to track it down on the gnucash end so that your less-than-ideal solution could be cleaned up. A
On Wed, Dec 12, 2007 at 08:12:35PM -0800, Andrew Sackville-West wrote:
On Wed, Dec 12, 2007 at 05:35:16PM -0800, codesite-noreply@google.com wrote:
This gets us in trouble with Gnucash, which, for some reason, sends, one after the other, a MapRequest, a synthetic UnmapNotify and then another MapRequest.
I've said this before, but it bears repeating: this looks an awful lot like Gnucash is doing something wrong. Why would some dialogs but not others generate this behavior? It must be something internal to gnucash that is broken or at least odd. GNucash only fairly recently completed the transtion to gtk2.0 and it's likely that some problems exist.
Well, it's odd that Gnucash does that, but I don't think it's broken: Mapping, unmapping and then remapping a window *should* leave it visible, and the fact that it didn't in xmonad was a bug, which we fixed.
WHat sort of things would I look for in Gnucash that might cause this? Is it the type of thing that might be caused by some spurious extra call to a window creation routine, for example?
I can't imagine caring that much. :) Seriously, it's probably not worth it: Even you if you find what looks like a problem, you'll have to do a lot of research and testing to figure out if that's actually the case, then you have to convince the Gnucash devs to accept a patch, blah blah blah work work work. But your offer to look at the Gnucash source code got me curious, so I downloaded the source for 2.2.1, followed the chain of calls down until I found this in the middle of gnc_search_dialog_init_widgets in src/gnome-search/dialog-search.c: /* show it all */ gtk_widget_show_all (sw->dialog); /* hide the dialog */ gtk_widget_hide (sw->dialog); What that says to me is this: They have some reason for doing what they're doing and it's probably not a simple fix to do it a different way. If I attempt to figure out why, or attempt to figure out a different way to do it, I'll get sucked into a bunch of discussion, research, coding and testing that I don't really want to do. But hey, I could be wrong, and you're certainly welcome to pursue that in any way you see fit. I just don't think Gnucash is broken in this regard, it's just a little weird.
If I get some decent pointers, I could dig into the code and try to track it down on the gnucash end so that your less-than-ideal solution could be cleaned up.
We've done everything we can on the xmonad end, and it works fine. (For me, anyway. Unless you're seeing some additional problems?) I'm not going to lose any sleep over it. Jason Creighton
On Wed, Dec 12, 2007 at 10:53:48PM -0700, Jason Creighton wrote:
On Wed, Dec 12, 2007 at 08:12:35PM -0800, Andrew Sackville-West wrote:
On Wed, Dec 12, 2007 at 05:35:16PM -0800, codesite-noreply@google.com wrote:
This gets us in trouble with Gnucash, which, for some reason, sends, one after the other, a MapRequest, a synthetic UnmapNotify and then another MapRequest.
I've said this before, but it bears repeating: this looks an awful lot like Gnucash is doing something wrong. Why would some dialogs but not others generate this behavior? It must be something internal to gnucash that is broken or at least odd. GNucash only fairly recently completed the transtion to gtk2.0 and it's likely that some problems exist.
Well, it's odd that Gnucash does that, but I don't think it's broken: Mapping, unmapping and then remapping a window *should* leave it visible, and the fact that it didn't in xmonad was a bug, which we fixed.
fair enough. ...
Seriously, it's probably not worth it: Even you if you find what looks like a problem, you'll have to do a lot of research and testing to figure out if that's actually the case, then you have to convince the Gnucash devs to accept a patch, blah blah blah work work work.
I have commit access. It's a part of gnucash I've never touched, so I'd go through the process of getting someone with more experience to review it, but that's not really a big deal. It does affect other WM's as well...
But your offer to look at the Gnucash source code got me curious, so I downloaded the source for 2.2.1, followed the chain of calls down until I found this in the middle of gnc_search_dialog_init_widgets in src/gnome-search/dialog-search.c:
/* show it all */ gtk_widget_show_all (sw->dialog);
/* hide the dialog */ gtk_widget_hide (sw->dialog);
What that says to me is this: They have some reason for doing what they're doing and it's probably not a simple fix to do it a different way. If I attempt to figure out why, or attempt to figure out a different way to do it, I'll get sucked into a bunch of discussion, research, coding and testing that I don't really want to do.
Wow! Nice pointer. thanks! ...
We've done everything we can on the xmonad end, and it works fine. (For me, anyway. Unless you're seeing some additional problems?) I'm not going to lose any sleep over it.
thanks for that. I'm not seeing additional problems, but I'm also waiting (check apt-cache) on debian packages with the fix. And no lost sleep here... ;) A
On Thu, Dec 13, 2007 at 11:54:05AM -0800, Andrew Sackville-West wrote:
On Wed, Dec 12, 2007 at 10:53:48PM -0700, Jason Creighton wrote:
Seriously, it's probably not worth it: Even you if you find what looks like a problem, you'll have to do a lot of research and testing to figure out if that's actually the case, then you have to convince the Gnucash devs to accept a patch, blah blah blah work work work.
I have commit access. It's a part of gnucash I've never touched, so I'd go through the process of getting someone with more experience to review it, but that's not really a big deal. It does affect other WM's as well...
Oh! I didn't know you were involved with gnucash at all. My warnings were based on me thinking that you were some random outsider (like myself) to that project. Your interest in this issue makes much more sense to me now. So you must be andrewsw on #gnucash on irc.gnome.org, then?
We've done everything we can on the xmonad end, and it works fine. (For me, anyway. Unless you're seeing some additional problems?) I'm not going to lose any sleep over it.
thanks for that. I'm not seeing additional problems, but I'm also waiting (check apt-cache) on debian packages with the fix. And no lost sleep here... ;)
Hmm. IIRC, that the fix was commited after 0.5 was tagged, so you might have a while to wait. Jason Creighton
On Thu, Dec 13, 2007 at 10:44:16PM -0700, Jason Creighton wrote:
On Thu, Dec 13, 2007 at 11:54:05AM -0800, Andrew Sackville-West wrote:
On Wed, Dec 12, 2007 at 10:53:48PM -0700, Jason Creighton wrote:
Seriously, it's probably not worth it: Even you if you find what looks like a problem, you'll have to do a lot of research and testing to figure out if that's actually the case, then you have to convince the Gnucash devs to accept a patch, blah blah blah work work work.
I have commit access. It's a part of gnucash I've never touched, so I'd go through the process of getting someone with more experience to review it, but that's not really a big deal. It does affect other WM's as well...
Oh! I didn't know you were involved with gnucash at all. My warnings were based on me thinking that you were some random outsider (like myself) to that project. Your interest in this issue makes much more sense to me now.
:)
So you must be andrewsw on #gnucash on irc.gnome.org, then?
yup. I'm pretty much the only "Developer" (that term should be used very loosely when referring to me) using an alternative WM. There are a couple of users who've complained about this issue as well using some-other-random-WM's, making it an issue that I have interest in fixing. A gui-heavy app like gnucash is already difficult enough to use in a tiling/keyboard situation without it having these little problems. ...
Hmm. IIRC, that the fix was commited after 0.5 was tagged, so you might have a while to wait.
yet another reason to fix it ;) thanks for the pointer to the extra gtk_wdiget_* calls. THere was a little interest on #gnucash about reworking that just because it's ugly and a little hackish. Also, I pulled that extra _hide out and now it works beautifully, though there are possibly other complications. you are jcreigh, I see... see you on #gnucash... A
On Wed, Dec 12, 2007 at 10:53:48PM -0700, Jason Creighton wrote:
On Wed, Dec 12, 2007 at 08:12:35PM -0800, Andrew Sackville-West wrote:
On Wed, Dec 12, 2007 at 05:35:16PM -0800, codesite-noreply@google.com wrote:
This gets us in trouble with Gnucash, which, for some reason, sends, one after the other, a MapRequest, a synthetic UnmapNotify and then another MapRequest.
I've said this before, but it bears repeating: this looks an awful lot like Gnucash is doing something wrong. Why would some dialogs but not others generate this behavior? It must be something internal to gnucash that is broken or at least odd. GNucash only fairly recently completed the transtion to gtk2.0 and it's likely that some problems exist.
Well, it's odd that Gnucash does that, but I don't think it's broken: Mapping, unmapping and then remapping a window *should* leave it visible, and the fact that it didn't in xmonad was a bug, which we fixed.
turns out that dialog gtk_widget_show_all's to get all the widgets visible, hides the dialog, tweaks what is ultimately visible and then reshows it. perfectly reasonable behavior in the absence of gtk_widget_show_all_children(), I guess. meanwhile, commenting out the gtk_widget_hide makes a very usable dialog, IMO. thanks again for the attention on this. A
On Wed, 2007/12/12 20:12:35 -0800, Andrew Sackville-West wrote:
I've said this before, but it bears repeating: this looks an awful lot like Gnucash is doing something wrong.
I don’t know if it’s the same problem, but I’ve noticed similar problems with a couple other applications. In gnome-terminal, I have to right-click and choose “Edit Current Profile…” twice for the dialog to stay open; the first time it flashes and disappears. Also, some CD ripping program I tried wouldn’t let me open a certain dialog box; every time I tried, it flashed and disappeared. The gnome-terminal issue is under xmonad 0.5 and the CD ripper problem was back in 0.4 (I only recently tried gnome-terminal and I no longer use that CD ripper). If I have some time, I’ll try tracking down my issues or seeing if xmonad from darcs fixes them. If they are the same issue as Gnucash, this fix is welcome.
I don???t know if it???s the same problem, but I???ve noticed similar problems with a couple other applications. In gnome-terminal, I have to right-click and choose ???Edit Current Profile?????? twice for the dialog to stay open; the first time it flashes and disappears.
When installing the Linux client for EVE Online ( http://www.eve-online.com/download/linux.asp ) the initial license dialog flickers into existence and then disappears forever. This makes it impossible to progress through the installer at all. It's written in python and uses pygtk and glade for the GUI, so I don't think there's much man-made GUI code at all in it. If it's something common to glade-sourced interfaces, it could be more common that one'd think. The client is publicly available for testing out, even if one doesn't have a game account. I'm running the darcs xmonad from a week ago or so, I'm unsure if the gnucash fix was in then or not. -- Lars Viklund | zao@acc.umu.se | 070-310 47 07
On Saturday 15 December 2007 02:13:33 Lars Viklund wrote:
I don???t know if it???s the same problem, but I???ve noticed similar problems with a couple other applications. In gnome-terminal, I have to right-click and choose ???Edit Current Profile?????? twice for the dialog to stay open; the first time it flashes and disappears.
When installing the Linux client for EVE Online ( http://www.eve-online.com/download/linux.asp ) the initial license dialog flickers into existence and then disappears forever.
Yeah, sounds similar to the gnucash bug
This makes it impossible to progress through the installer at all. It's written in python and uses pygtk and glade for the GUI, so I don't think there's much man-made GUI code at all in it. If it's something common to glade-sourced interfaces, it could be more common that one'd think. The client is publicly available for testing out, even if one doesn't have a game account.
I'm running the darcs xmonad from a week ago or so, I'm unsure if the gnucash fix was in then or not.
It wasn't. Please upgrade to the latest darcs and let us know if the problem persists. Cheers, Spencer Janssen
participants (6)
-
Andrew Sackville-West -
codesite-noreply＠google.com -
Jason Creighton -
Lars Viklund -
lithis -
Spencer Janssen