Command line options stripped for KUniqueApplication

[Urban Widmark]

On Fri, May 27, 2011 at 11:54 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> one other little "gotcha" is that some unique apps do open a new window when
> launched a second time, just in the same process. it would be really nice if
> such applications could note that they do so and thus always leave the flags
> alone.

Thanks for your comments. Have had a further think and look at this.

konsole uses KUniqueApplication and opens windows like you describe.
There is an inconsistency between a KApplication and
KUniqueApplication regarding options. Probably doesn't matter, but a
KApplication gets to keep the kde/qt specific options but a
KUniqueApplication always loses them. So if I make a utility class of
some kind that looks at options, it would work differently depending
on the application class used, even for the initial instance.


Why doesn't KUniqueApplication::newInstance() get the options that
were used to create the new instance as a parameter?
That way it could react to them if it wanted to, but the options for
the main program would be unchanged - unless the application decides
to update them.

To do that would require some changes to KCmdLineArgs and its internal
helper classes. Today you can only have one instance of options, since
it all depends on KCmdLineArgsStatic. I think that can be done without
removing anything from the API, but probably need to add some
functions to be able to manipulate additional  KCmdLineArgs instances
(or possibly better with a separate class for this). To avoid
duplicating code the static version could be expressed in terms of a
dynamically allocated one.

KCmdLineArgs::saveAppArgs() / KCmdLineArgs::loadAppArgs() would not
remove all QT/KDE args. No options would be overwritten automatically
when a second instance starts, which is what happens today for
non-KDE/QT args and a KUniqueApplication.

Any objections to that idea?