PTBatcherGUI annoying window handling

[Andreas Metzler]

With 2011.2.0 the old <Stich Now!> is gone, I am using PTBatcherGUI instead.

The window handling is very annoying. The main autobatcher window and the progress window are automatically if switch to another virtual desktop and back again.

It would also be very nice if closing the hugin apllication would close (the not manually started) PTBatcherGUI instance, too.

[Andreas Metzler (k-launchpad-downhill-at-eu-org)]

adding second screenshot ...

[Yuv (yuv)]

had the wish for closing of PTBatcherGUI after termination of the batch outstanding in bug 792659

it is not exactly what you wish for, but do you really want Hugin to close PTBatcherGUI, even if it is still in the middle of a stitch?

Anyway, scratched my itch. Test default branch after changeset 5426:04e6287fb38a and let me know if it works for you.

[Andreas Metzler (k-launchpad-downhill-at-eu-org)]

Hello Yuv,

I have run 2011.2.0rc1 + 04e6287fb38a. The "autoexit PTBatcher when finished" functionality works nicely for me.

The Windowhandling does not seem to have changed. Both main window and execution details still autohide after a Desktop switch. Was this caused by not running HG default, but rc + single patchset?

*However* reading your commit message made me browse the configuration menu and to my absolute delight I found that hugin_stitch_project is still available as an option.

cu andreas

[Yuv (yuv)]

On July 19, 2011 02:04:52 pm Andreas Metzler wrote:
> The Windowhandling does not seem to have changed.

No, I have not changed the window handling (yet).

The next thing I want to do is to start PTBatcherGUI minimized to the tray.

> Both main window and
> execution details still autohide after a Desktop switch.

I did not notice that, I do not switch Desktop usually. Will try and see what
can be done.

> *However* reading your commit message made me browse the configuration
> menu and to my absolute delight I found that hugin_stitch_project is
> still available as an option.

Yes, when *I* am adding new features I try not to remove existing ones and
leave users the option to fall back on their tried and tested features. There
is always an inherent conflict between new and old. I try not to get into
such conflict. When I do, I try to discuss this first with as many stake
holders as possible. The decision to make PTBatcherGUI the default stitch
engine happened on Hugin-PTX, because the change of default does change the
world to some of us. At some point hugin_stitch_project will be discontinued,
but that's only after users like you are happy to make the switch to
PTBatcherGUI. Sometimes this kind of ideal change management is not possible
- e.g. the effort to maintain the legacy behavior is too big. But it was not
the case with this change.

Yuv

[Stephen Bennett (smb-nyx)]

Yuval

I think the following changeset is breaking the compile of PTBatcher?
Changeset: 5427 (04e6287fb38a) * add option to PTBatcherGUI to quit application at the end of the batch

On Windows, with wxWidget 2.8.11 and Visual Studio 2009 I get the following compiler time error:

36>Linking...
36>Batch.obj : error LNK2019: unresolved external symbol "class PTBatcherGUI & __cdecl wxGetApp(void)" (?wxGetApp@@YAAAVPTBatcherGUI@@XZ) referenced in function "public: void __thiscall Batch::OnProcessTerminate(class wxProcessEvent &)" (?OnProcessTerminate@Batch@@QAEXAAVwxProcessEvent@@@Z)
36>C:\HuginSDKLatest\builds\src\hugin1\ptbatcher\Release\PTBatcher.exe : fatal error LNK1120: 1 unresolved externals
36>Build log was saved at "file://c:\HuginSDKLatest\builds\src\hugin1\ptbatcher\PTBatcher.dir\Release\BuildLog.htm"

In short Batch.cpp is used in both PTBatcher and PTBatcherGUI but wxGetApp() is only defined in the GUI project.

I assume this just needs to be conditionised out, but I can't immedaite see an appropaite way to.

Regards
Stephen

[Stephen Bennett (smb-nyx)]

>>In short Batch.cpp is used in both PTBatcher and PTBatcherGUI but wxGetApp() is only defined in the GUI project.

Actually I'm wrong here, the issues is which headers gets included into Batch.cpp.

It is easy to re-range the header so they both contain the DECLARE_APP().. Then all that is needed is to conditionally include either Batcher.h or BatcherGUI.h. But is not that easy when this file is compiled it does not know what is being compiled with it, to select the appropaite header.

Regards
Stephen

[Yuv (yuv)]

Hi Stephen,

Thanks for the feedback. I don't have access to a development environment on Windows and was not aware of the issue. Sorry for causing this trouble.

It seems that it is easier to remove my contribution rather than fix the headers as you suggest:

http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/rev/6cc3ce4c3bbb

So PTBatcher is back to the sub-optimal behavior coded by somebody who has no understanding of human-machine interaction...

[tmodes (tmodes)]

The observed behaviour is related to the window manager. First it does not support the tray area. Second the virtual desktop seems to be implemented by only minimizing the windows, which are not on the active desktop.
wxWidgets 2.8 does not offer an option to get an information about the availability of the tray area. So deactivate the tray icon on *nix, this should restore the old behaviour. -> therefore setting to incomplete.
If there are more information set the status to new again.

[Andreas Metzler (k-launchpad-downhill-at-eu-org)]

Joy, forgot a word in the original report: "The window handling is very annoying. The main autobatcher window and the progress window are automatically *hidden* if I switch to another virtual desktop and back again."

[Andreas Metzler (k-launchpad-downhill-at-eu-org)]

On 2011-09-11 tmodes <email address hidden> wrote:
> The observed behaviour is related to the window manager. First it
> does not support the tray area.

Correct. This is wmaker FWIW.

> Second the virtual desktop seems to
> be implemented by only minimizing the windows, which are not on the
> active desktop.

Any way for me to check whether wmaker really implements virtual
desktops this way?

cu andreas

[Andreas Metzler (k-launchpad-downhill-at-eu-org)]

On 2011-09-11 "T. Modes" <email address hidden> wrote:
> Hi Andreas,

> some questions to your bug report:

> Have you also tried current tip? I did a change in the last week to
> deactivate the tray icon. Does the mainwindow also disappear if no
> stitch was started (because I don't really understand, why the
> PTBatcherGUI main window disappears.) Please test minimizing windows and
> switching desktops.
[...]

In current tip the strange behavior is fixed, neither the PTBatcherGUI
main window nor the verbose-execution window are automatically minimized
when switching desktops. :-)

Is there any point in me trying out the other thing you suggested?
thanks cu andreas

[tmodes (tmodes)]

Hi Andreas,

thanks for feedback.
No need to test the other things. They were only for the case the fixes in default branch did not fixes the issue.