They're not windows, they're GtkDialogs, and Gtk3 complains if they're not made "transient for" the parent window, which also keeps them above the parent in z-order.

There's also a silver lining: By making them transient-for they appear centered over the parent window instead of somewhere strange on large or multiple monitors.

I think that one could make a case for redesigning some dialogs to windows or plugin pages, but the argument would be pretty weak for the three that you mentioned explicitly. IMO the best argument is for the report options because it has the ability to "apply" changes without dismissing it, so one can interact with it while viewing the resulting changes on the report.

I understand your points, but I'm not sure I entirely agree.  Your "silver lining" is not without problems, for example.  I think this also makes these windows revert to their default size which is a pain if I've resized them to fit the data.

I think a good case could be made for rewriting quite a few of these as windows.  It's useful to keep the price data base open since it takes several minutes to open it and one often wants to manipulate several prices (or at least look at them) while doing other things.  Having to open it, wait several minutes, then resize and scroll it to see what you care about is not a good alternative.

Also it's useful to keep the business related find windows like find invoice and find bill open since they contain lists of invoice or bills you can work on.  They also do live updates so the list changes as you change the bills and invoices.  If the find criteria is at all complicated it's time consuming to reopen the window.

The Reconcile window is a particularly good example, I think.  You want to keep it open until you're done reconciling the account (or give up) and go back and forth between the reconcile window and the register to fix things without aborting the reconcile and starting it up again.  But the reconcile window is stuck in front of the register so it has to be moved mostly off screen so you can fix something, then drag it back.

I agree that the Price Editor window is ok as a dialog.  There are probably others that are too, but I think many of these should be real windows.

Yes, there is certainly room for improvement here. We'll need to evaluate this on a case by case basis.

I agree with most of your proposals.

I'm also thinking of the Bills Due reminder and SX since last run dialog. Those are special though because they can pop up at start up. The nice side effect of transient-for is they are guaranteed to be visible and above the main window. In the past they had the tendency to appear behind the main window. So if we want to fix those special care should be taken they still are guaranteed to pop up before the main window. The user may choose to move them behind the main window afterwards. I don't know if that's possible though, that is I don't know if gtk has something between fully transient-for or just create somewhere which can be behind another window.

OK, but that's an enhancement request rather than a regression, so I've changed the title and category accordingly.

We should get consensus on what dialogs should be converted from a broader group than is likely to participate in a bug, so that discussion would be better on one of the mailing lists.

I don't think there's a partly-transient-for state. We can fake it by getting the coordinates of the parent and putting the window there. We could also do plugin-pages so the item appears as a tab; the user can switch it to a window if they want.

I agree that this should be taken to a mailing list, which one? Devel?

I noticed today that the lots browser doesn't display this behavior.  That probably means that transient-for is not being set for it.

(In reply to Geert Janssens from comment #3)
> Yes, there is certainly room for improvement here. We'll need to evaluate
> this on a case by case basis.
> 
> I agree with most of your proposals.
> 
> I'm also thinking of the Bills Due reminder and SX since last run dialog.
> Those are special though because they can pop up at start up. The nice side
> effect of transient-for is they are guaranteed to be visible and above the
> main window. In the past they had the tendency to appear behind the main
> window. So if we want to fix those special care should be taken they still
> are guaranteed to pop up before the main window. The user may choose to move
> them behind the main window afterwards. I don't know if that's possible
> though, that is I don't know if gtk has something between fully
> transient-for or just create somewhere which can be behind another window.

I'd suggest a special tab that contains all (or summary with a link to all) of the content from Bills Due/Invoices Due/SX Since Last Run, opening as in focus. There have been requests for a 'dashboard' of sorts. If this included a summary balance sheet, and possibly a simple income/expense chart and/or a chart depicting the results on net-worth or income/expense of future SX, lots of people would be very happy. But I know that's beyond the initial request here. Just a thought if you're going to do some redesigning anyway.

Note, I second the find invoice/bill and reconcile dialogs to be changed to tabs/windows.

+1 for the Reconcile window
+1 for the Report Options window

I will assert that all dialogs that could be related to more than one register window or other primary window while open, or even where they cannot be easily completed efficiently without viewing a single underlying primary window would need to be moved out of the way from time to time.  The price editor may be related to more than one security account, the import wizards, SX editor and reconcile wizard can relate to multiple account windows or underlying in some cases too.  I am not by any means trying to name every case, just a couple that come to mind.  When users are restricted to 600 x 800 displays in some cases that can be important.

*** Bug 794951 has been marked as a duplicate of this bug. ***

I think now Geert has dup'd 794951 (and I think one of mine will be dup here as well once we figure it out) this is looking like a nomenclature issue in part.

My observation is that calling the beasties Dialogs rather than Windows might work on a bug list but is going to take a lot of user training.

Insert wry smile emoticon.

(In reply to Wm from comment #10)
> I think now Geert has dup'd 794951 (and I think one of mine will be dup here
> as well once we figure it out) this is looking like a nomenclature issue in
> part.
> 
> My observation is that calling the beasties Dialogs rather than Windows
> might work on a bug list but is going to take a lot of user training.
> 
> Insert wry smile emoticon.

Wm, don't worry about it. Developers often speak in strange languages amongst themselves.

Another +1 for making the Reconcile window a true window rather than a dialog.  My workflow under 2.6 was to have the Register window full screen, with the Reconcile window and statement PDF tiled side-by-side above it.  With the Reconcile window now a dialog, I am constantly having to move it out of the way and then move it back, which gets annoying fairly quickly.

(In reply to Daniel Harding from comment #12)
> Another +1 for making the Reconcile window a true window rather than a
> dialog.  My workflow under 2.6 was to have the Register window full screen,
> with the Reconcile window and statement PDF tiled side-by-side above it. 
> With the Reconcile window now a dialog, I am constantly having to move it
> out of the way and then move it back, which gets annoying fairly quickly.

This particular one will be fixed in gnucash 3.2.

*** Bug 796049 has been marked as a duplicate of this bug. ***

Bug 796049 reports the following use case:
- open the preferences window
- then open the import map editor (the preferences window doesn't block menu actions on the main gnucash window)
- next try to do anything in the open preferences window

=> other than bringing the preference window to the front, no other interactions are possible. This leads to confusion and should be avoided. This is yet another variation of side effects caused by the transient window setting on dialogs.

Reading over the Gnome HIG, perhaps some of these should be changed to child-primary windows. This way they can be positioned independently of the parent window and there should be no stacking issues. (focused window should always be on top)

The only caveat is that even child-primary windows do not automatically depend on the parent for their continued existence. Care would need to be taken to close any child windows when exiting the application. (this might be available as an option depending on what is transitioned to this window type.)

Another consideration, would be to make some of these into Sidebars. (GtkStackSidebar) This might be particularly useful for the main application Preferences (though not really necessary) but certainly the Reconcile dialog, where you'd likely want to see both the reconcile info and the register being reconciled at the same time. I'd suggest a sidebar here instead of a child window because the reconcile functions are specific to that particular account register and not independent.

Alternatively for the reconcile situation, perhaps changing the register to a selection mode for this case, with balance and reconcile actions might better follow the Gnome HIG, but that of course will likely require a substantial re-write. Such a change might not also mesh with MacOS HIG. (and does Windows have such a thing or is it still 'anything goes'?)

Finally, another plug for the 'dashboard' recommendation from Comment 6 is that it seems multiple dialogs open at once is discouraged.

Just some thoughts.

> and does Windows have such a thing or is it still 'anything goes'?

https://msdn.microsoft.com/en-us/library/windows/desktop/dn688964(v=vs.85).aspx

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=794853. Please continue processing the bug there and please update any external references or bookmarks.