GNOME Bugzilla – Bug 134100
Find invoice window doesn't pop found invoice to front
Last modified: 2018-06-29 20:41:14 UTC
Using the 'Find invoice' window, the relevant invoice window isn't popped to the front of the stack when opened - it's behind the 'Find' window, which is annoying. This contrasts with the (correct) behaviour of the 'Find customer' window.
What version of gnucash are you using?
Actually, this is my code so I'll take ownership
I'm using 1.8.8.
Hmm, I cannot reproduce this problem. From the find-invoice window, if I try to open an already-opened invoice it raises the already-opened invoice window to the top of the windows stack. So, could you provide me more details on how to reproduce this problem? The code seems to work fine for me.
Odd. I get this by simply following these steps. 1) Launch GnuCash 2) Business->Customers->Find invoice 3) Enter "1", click 'Find' 4) Select invoice, click 'View/Edit invoice' The invoice window then appears behind the Find window, but the new invoice window does have the focus. Which suggests something - do you have focused windows forced to the front of the stack?
Nope. I can focus on windows that are not in the front. The code is just calling gtk_window_present() which should raise the window. It's the exact same code that's called for invoices, customers, etc. Does it raise the invoice window and the re-raise the "find" window? When I run through your steps I get an invoice window on the top of my stack. I can then push it to the bottom, click on 'find/edit invoice' again, and it will bring the window back to the front again. So... I suspect the problem is your window manager not behaving properly.
This is strange - especially that it happens with this one window and no others. I can't see a double raise being done - it looks like the invoice window is actually opened behind the find window. I'm using xfwm4.0.3 as my WM. However, if I switch to metacity, the problem goes away. So it does look like some odd interaction with the WM. I'll raise it with the XFce people as well and pass back their comments here.
I've passed this to the XFce people and their suggestion is that it's happening because GnuCash is setting some windows as transients and not others, which leads to unexpected effects with a standards-compliant WM (i.e. xfwm4). Olivier Fourdan wrote: > Ok, I took some time digging into it and what you see is > the normal expected behaviour. > Let me try to explain (so you can pass that info the the gnucash people) > - xfwm4 places transient on top of their parents window. Fine. It's > a nice feature in xfwm4, > - The "find" dialog from gnucash specify the root window as > transient_for property, which is a (not so std, but fairly common) way > of specifying a transient fro group window, > - From EWMH specs (freedesktop std): > *Implementing enhanced support for application transient windows* > If the WM_TRANSIENT_FOR property is set to None or Root window, the > window should be treated as a transient for all other windows in the > same group. It has been noted that this is a slight ICCCM violation, > but as this behavior is pretty standard for many toolkits and window > managers, and is extremely unlikely to break anything, it seems > reasonable to document it as standard. > So, the find dialog is treated as a "transient for group" window and, as > transients appear on top of their parents in xfwm4, xfwm4 place the > gnucash "find" dialog on top of the "show/edit invoice" window which is > a regular window of the same group (same window id # of group leader) - > No bug in xfwm4 here.
Uh, the find window is a top-level window, just like the invoice and customer windows. It is not a transient window. It has no parent. Can you get the FXce guys into this conversation, because I've never seen this behavior with any other windowmanager, and it's clearly the window manager that's behaving irradically. You're welcome to play with the glade settings of search.glade to see if there is something I have set incorrectly.... But it all looks right to me.
Well, I used xprop on the Find window (as Olivier Fourdan suggested) and found that it returned (among other things): WM_TRANSIENT_FOR(WINDOW): window id # 0x40 Which seems to suggest that it's appearing transient. Indeed, this is the difference between the two settings I mentioned (finding customers and finding invoices) - both the 'Find customers' window and the 'View Customers' windows have this WM_TRANSIENT_FOR set and so are ordered correctly, whereas only the 'Find invoice' window has it set (the 'View invoice' window doesn't) and so always appears at the top of the stack. Anyhow, this is definitely over my head now - I'll pass the URL of this bug report to the XFce list and hopefully they'll come and join in.
Greetings, Search window has WM_TRANSIENT_FOR set to the root window, which means "transient for group" as mentionned by the EWMH standard in the quote I sent by email to John. So it basically means that the Search window should be treated as a transient to all windows of the same group. Since xfwm4 places transient on top of their parents, then the Search window is rightly placed on top of all other windows of the same group, including the invoice window. The obvious solution is to remove the WM_TRANSIENT_FOR property on the Search window in gnucash. PS: The fact that other WM don't implement this doesn't mean xfwm4 is broken, nor behaving "irradically". Cheers, Olivier.
I'll see what I can do and try to come up with a patch. Cheers, Olivier.
John: test the "find transactions" feature. I bet it does the same thing as the "find invoices"... Oliver: There are times when the find dialog needs to be modal, and other times when it is not, so you can't just ignore the parent in all cases.
Nope - the "Find" window disappears and displays all found transactions in a ledger. So chalk that up as a third way GC deals with the find function! (If I'm understanding you properly - using Tools->Find transaction.)
Oh, right.. They specifically close the window in that case, because the account-window is the actual results (rather than showing results in the find window)...
Humm, maybe I missed something. kwin (kde 3.2) does implement that "transient for group" just like xfwm4 but the invoice window still gets placed on top of the stack. By looking at the xprop fields, I still believe it shouldn't, but I might be missing something. I keep investigating on my side.
Ahhhhh! I think I found out! Creation time, it's the only thing that changes. kwin is smart, really, it does exactly the same as xfwm4 but it also check the creation time so that particular case we see in gnucash doesn't happen *because* the invoice window is created *after* the dialog that is "transient for group" :)
So you can fix xfwm4, right? :)
Yeah, it's done in cvs. I'm using the creation date to determine if the "transient for group" property should be honored or not. It works, as expected, although such things aren't documented in any standard I know... Well, interoperability is prolly more important than written standards, isn't it ? ;)
OK, this new version of xfwm4 solves the problem for me :-)
Ok, then I'm going to close the bug report here.. Thanks.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=134100. Please update any external references or bookmarks.