On June 4, 2011 10:39:28 AM tmodes wrote:
> What would be the advantage of this?
>
> If no stitch is running, PTBatcherGUI is sitting (minimized) in the
> notification area / as tray icon and does nothing, only waiting for new
> projects.
exact replication of what hugin_stitch_project does now.
one icon less in the tray.
one process less to consume less resources and reduce the risk that something
might destabilize the system.
> When a new project is send to PTBatcherGUI this is faster than
> restarting it again.
This is the argument used by every tray-populating software maker. Your
printer will print faster, your open office document will open faster, etc.,
etc.
It's a good argument, but the ultimate argument should be user choice. If the
user prefer a faster restart, he will let it run. If the user prefer a tidy
desktop, it will tell it to close.
On June 4, 2011 10:39:28 AM tmodes wrote:
> What would be the advantage of this?
>
> If no stitch is running, PTBatcherGUI is sitting (minimized) in the
> notification area / as tray icon and does nothing, only waiting for new
> projects.
exact replication of what hugin_stitch_ project does now.
one icon less in the tray.
one process less to consume less resources and reduce the risk that something
might destabilize the system.
> When a new project is send to PTBatcherGUI this is faster than
> restarting it again.
This is the argument used by every tray-populating software maker. Your
printer will print faster, your open office document will open faster, etc.,
etc.
It's a good argument, but the ultimate argument should be user choice. If the
user prefer a faster restart, he will let it run. If the user prefer a tidy
desktop, it will tell it to close.