Disallow duplicate windows.

[casey]

Fixes #3569.

This change disallows the creation of multiple instances of the command line options, used send addresses, and used receive addresses windows.

[jonasschnelli]

Nice!
Tested a bit.

Two points:

• why is the "Sign message" dialog is modal and the "Sending Addresses" and "Receiving Addresses" not? (indirectly related to this PR)
• This PR works, but it would be nice, if the window would get the focus when a user selects "Sending Addresses (or "Receiving Addresses") if the window is already open in background.

[laanwj]

Concept ack.

[casey]

I tried adding calls to widget->activateWindow() and widget->raise(), but my weirdo window manager (xmonad) isn't respecting them so I can't test. @jonasschnelli, can you pull casey:duplicate-windows-foreground and see if that fixes it?

As far as modal vs non-modal, I can't really come up with a compelling argument for it either way. Do users leave up the sign/verify dialogs while they do other thing?

[jonasschnelli]

@casey I also don't have an strong opinion on modal/non-modal. Just tested on Ubuntu and OSX and the focus issue is still unsolved.
Could you not just call activateWindow() (http://doc.qt.io/qt-4.8/qwidget.html#activateWindow). IIRC I once have implemented that also in https://github.com/bitcoin/bitcoin/blob/master/src/qt/macdockiconhandler.mm#L129.

[casey]

@jonasschnelli Which version of ubuntu and which desktop environment are you testing with? When I test with ubuntu vivid with unity, I can't actually get the main window to the foreground when the "sending addresses" or "receiving addresses" windows are up, they stay in the foreground, although I can focus the main window.

[jonasschnelli]

@casey: Right. On Ubuntu the "sending addresses" or "receiving addresses" windows are always in front. On OSX (and probably also on Windows), the window does not keep in front always. There it would be good if the window gets the focus if one selects "sending addresses" or "receiving addresses" again from the menu. On Ubuntu focusing the window (even if it is always in front but un-focused) would also be good.

[casey]

@jonasschnelli I still can't get the windows to come to the foreground on all platforms; even with calls to activeateWindow(), behavior is still inconsistent.

What about just making all three dialogues modal, so that they're just always in the foreground, and users have to dismiss them to continue? This would make everything consistent.

[maflcko]

I think the "* addresses"-windows are non-modal so the user can easily copy more than one address into the "Send"-tab. But then there is also the "Choose previously used address"-button in the "Send"-tab providing an alternative to copy-paste sending addresses... So, making all three dialogues modal sounds ok to me.

[laanwj]

I personally prefer being able to open multiple windows at a time (not of the same type obviously - I agree with this pull). Modal dialogs are meant for when some action has to be completed before another, but if there is no sequential control flow, there is no reason to not allow interacting with them at the same time.

[casey]

In that case I think we should merge the PR as is. I haven't been able to get the right behavior in a cross platform way, no matter how many calls to activateWindow() and raise() that I insert :-P

[jonasschnelli]

Tested ACK on merging this as it is.
The non-focus while reselecting over the menu is a nitpick.

[fanquake]

utACK

On Friday, September 4, 2015, Jonas Schnelli notifications@github.com
wrote:

ACK on merging this as it is.
The non-focus while reselecting over the menu is a nitpick.

—
Reply to this email directly or view it on GitHub
#6594 (comment).

[jonasschnelli]

@casey: This commit (jonasschnelli@a272c80) would fix the focus issue. Mind cherry pick this commit?

[laanwj]

This shouldn't include the commit "rpc-tests: re-enable rpc-tests for Windows".
(nor the two commits before that)

[maflcko]

Tested ACK (5ffaaba, Fedora)

@jonasschnelli If you are happy with 5ffaaba maybe you could also create a windows build at https://builds.jonasschnelli.ch/pulls/6594/ ?

[jonasschnelli]

@MarcoFalke: just triggered a gitian build of this PR: https://builds.jonasschnelli.ch/pulls/6594/

[maflcko]

Great, thanks for the build!

Tested ACK (Win 7)

[jonasschnelli]

Tested ACK.

[btcdrak]

@casey just a little github trick, if a PR fixed another issue, you can put "fixes #3569" in your commit message and it will close the ticket when this gets the PR gets merged.

[fanquake]

@btcdrak I'm pretty sure that also works with when you have it in the PR description.

[btcdrak]

@fanquake Maybe, they are always adding new features but it's not documented if it does. https://help.github.com/articles/closing-issues-via-commit-messages/