On Fri, May 27, 2011 at 11:54 AM, Aaron J. Seigo <ase...@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?
