some modal dialogs hidden behind other windows

[KFJ]

for some time I've been annoyed by a quirk in hugin: some modal dialogs are not displayed on top of all other windows, but remain hidden behind other windows on the desktop. This has the effect that hugin becomes unresponsive until one Alt-Tabs to the dialog in question and responds to it. I've noticed this behaviour with two dialogs:

- the stitcher dialog asking whether existing images should be deleted

- the dialog reporting the return code of a python script

I doubt this quirk is system-specific - the python script response has behaved this way for a while, but it only mattered when I ran woa, because the other plugins respond quickly, and the dialog is at least displayed on top initially - woa takes much longer, and if I do something else in the meantime, the dialog is hidden when it finally comes up. With the stitcher it's much more annoying: the dialog never even shows on top and has to be looked for in the list of available windows. I suppose the problem has been newly introduced by always using the batch processor for stitching.

I reckon wxWidgets has a simple flag somewhere for dialogs to display 'always on top' which has simply not been set, but I haven't investigated.

Currently I'm using Kubuntu 11.4 on an intel system:

Betriebssystem: Linux 2.6.38-10-generic-tuxonice i686
Architektur: 32 bit
Freier Speicher: 2000244 kiB

Hugin
Version: Pre-Release 2011.3.0.723668d8c4cc
Ressourcen-Pfad: /usr/local/share/hugin/xrc/
Datenpfad: /usr/local/share/hugin/data/

Kay

[Yuv (yuv)]

bug 815367 seems to be another such annoyance.

in some cases we need to add wxSTAY_ON_TOP, and in others we need to question if the window really needs to grab attention by being modal.

[tmodes (tmodes)]

Does this still happens?

[tduell (tduell-iinet)]

OK, tried to test this using hugin-2014.1.0 (changeset 6666) Fedora 20 x86_64.
Stitcher dialog asking whether existing images should be deleted opens on top OK.
Didn't see any window opened by "woa", but it was clear that it had completed. I haven't used "woa" previously and maybe its behaviour has changed.
"Crop control points" opened window on top OK.
I haven't experienced any other windows not displaying on top.
Not conclusive, additional tests by others would be helpful.

Cheers,
Terry

[KFJ (kfj)]

Am 01.07.2014 08:35, schrieb tduell:
> OK, tried to test this using hugin-2014.1.0 (changeset 6666) Fedora 20 x86_64.
> Stitcher dialog asking whether existing images should be deleted opens on top OK.
> Didn't see any window opened by "woa", but it was clear that it had completed. I haven't used "woa" previously and maybe its behaviour has changed.
> "Crop control points" opened window on top OK.
> I haven't experienced any other windows not displaying on top.
> Not conclusive, additional tests by others would be helpful.
>
> Cheers,
> Terry
>

Initially, I (kfj) wrote:

 > Bug description:
 > for some time I've been annoyed by a quirk in hugin: some modal
 > dialogs are not displayed on top of all other windows, but remain
 > hidden behind other windows on the desktop. This has the effect that
 > hugin becomes unresponsive until one Alt-Tabs to the dialog in
 > question and responds to it. I've noticed this behaviour with two
 > dialogs:

 > - the stitcher dialog asking whether existing images should be deleted

 > - the dialog reporting the return code of a python script

 > ...

The first bug is still present here:

Betriebssystem: Linux 3.13.0-30-generic x86_64
Architektur: 64 bit
Freier Speicher: 4766072 kiB

Hugin
Version: Pre-Release 2014.1.0.0f320becf3dc
Ressourcen-Pfad: /usr/local/share/hugin/xrc/
Datenpfad: /usr/local/share/hugin/data/
Hugins camera and lens database: /home/kfj/.hugindata/camlens.db

Bibliotheken
wxWidgets: 2.8.12.1
libpano13: 2.9.19
Boost: 1.55.0
Exiv2: 0.23.0
SQLite3: 3.8.2

The second one is probably still there but doesn't show very often,
because, if I remember correctly, the C++ code has been changed to
not show any notification of the resturn code of a python script
if the script returns zero, which is the standard return for error-free
completion.

I still suspect there should be a flag to open the modal boxes so that
they are 'always on top', e.g. the wxSTAY_ON_TOP style for wxDialog, but
this is only a guess.

Kay

[KFJ (kfj)]

Am 01.07.2014 11:29, schrieb KFJ:
> Am 01.07.2014 08:35, schrieb tduell:
>> OK, tried to test this using hugin-2014.1.0 (changeset 6666) Fedora 20 x86_64.
>> Stitcher dialog asking whether existing images should be deleted opens on top OK.
>> Didn't see any window opened by "woa", but it was clear that it had completed. I haven't used "woa" previously and maybe its behaviour has changed.
>> "Crop control points" opened window on top OK.
>> I haven't experienced any other windows not displaying on top.
>> Not conclusive, additional tests by others would be helpful.
>>
>> Cheers,
>> Terry
>>
>
> Initially, I (kfj) wrote:
>
> > Bug description:
> > for some time I've been annoyed by a quirk in hugin: some modal
> > dialogs are not displayed on top of all other windows, but remain
> > hidden behind other windows on the desktop. This has the effect that
> > hugin becomes unresponsive until one Alt-Tabs to the dialog in
> > question and responds to it. I've noticed this behaviour with two
> > dialogs:
>
> > - the stitcher dialog asking whether existing images should be
> deleted
>
> > - the dialog reporting the return code of a python script
>
> > ...
>
> The first bug is still present here:

I'd like to add a more detailed description of what happens:

In my settings, I have chosen PTBatcherGUI as 'Processor'.
I have also chosen to execute stitch jobs instantly and to show detailed
progress information, but I haven't chosen parallel execution or
deletion of existing images.

- when I start the stitching for the first time, the batch
   stitcher is launched and if pictures need to be overwritten,
   the 'delete existing images' dialog shows.

- if the batch stitcher is already active from a previous use
   and I ask for a stitch to be done which would require images
   to be deleted, then the error occurs and the 'delete existing
   images' dialog is hidden. At the same time, both the batch
   stitcher's window and the stitch log window (which is empty)
   remain unresponsive, until I Alt-Tab to the 'delete existing
   images' dialog box and okay or cancel it.

I can get to see the dialog box when it pops up if I move hugin's
window out of the way before I press 'stitch'- the dialog always opens
in the center of the screen and normaly my hugin window covers that.

So the problem seems to be that if hugin is in the foreground and
PTBatcherGUI is in the background, the dialog is hidden by hugin's
window. Maybe bringing the batch stitcher to the foreground when
it receives a job and immediate stitching is activated would mend
the problem.

Kay

>
> Betriebssystem: Linux 3.13.0-30-generic x86_64
> Architektur: 64 bit
> Freier Speicher: 4766072 kiB
>
> Hugin
> Version: Pre-Release 2014.1.0.0f320becf3dc
> Ressourcen-Pfad: /usr/local/share/hugin/xrc/
> Datenpfad: /usr/local/share/hugin/data/
> Hugins camera and lens database: /home/kfj/.hugindata/camlens.db
>
> Bibliotheken
> wxWidgets: 2.8.12.1
> libpano13: 2.9.19
> Boost: 1.55.0
> Exiv2: 0.23.0
> SQLite3: 3.8.2
>
> The second one is probably still there but doesn't show very often,
> because, if I remember correctly, the C++ code has been changed to
> not show an...

[tmodes (tmodes)]

> So the problem seems to be that if hugin is in the foreground and
> PTBatcherGUI is in the background, the dialog is hidden by hugin's
> window. Maybe bringing the batch stitcher to the foreground when
> it receives a job and immediate stitching is activated would mend
> the problem.

This sound easy. But this is not supported by all (?) window managers. An inactive window can not automatically bring into the foreground by the program itself. This is done only by the window manager.

So the exact behaviour of the window manager seems to be responsible how the windows react.

[tduell (tduell-iinet)]

On Tue, 01 Jul 2014 19:29:40 +1000, KFJ <email address hidden> wrote:

>
> Initially, I (kfj) wrote:
>
> > Bug description:
> > for some time I've been annoyed by a quirk in hugin: some modal
> > dialogs are not displayed on top of all other windows, but remain
> > hidden behind other windows on the desktop. This has the effect that
> > hugin becomes unresponsive until one Alt-Tabs to the dialog in
> > question and responds to it. I've noticed this behaviour with two
> > dialogs:
>
> > - the stitcher dialog asking whether existing images should be
> deleted
>
> > - the dialog reporting the return code of a python script
>
> > ...
>
> The first bug is still present here:
>
> Betriebssystem: Linux 3.13.0-30-generic x86_64
> Architektur: 64 bit
> Freier Speicher: 4766072 kiB
>
> Hugin
> Version: Pre-Release 2014.1.0.0f320becf3dc

Just tried this again using hugin-2014.1.0 (6666:e91faade4ad6) on Fedora
20 x86_64, and using PTBatcherGUI, all the PTBatcherGUI windows and dialog
boxes are opening on top of other windows.

--
Regards,
Terry Duell

[tduell (tduell-iinet)]

Further to my previous post (Comment #7), I should have added that my window manager is Mutter (Muffin).

Cheers,
Terry