Comment 12 for bug 361735

I think the WulforUtil::parse*Arguments() can probably be moved to main. Most other programs seem to handle command line arguments inside their main file. We can then just pass the args to mainwindow like we mentioned.

On the other hand, I've seen some programs use a combination of G_OPTION_FLAG_NO_ARG and G_OPTION_ARG_CALLBACK to connect a callback to handle the argument. Apparently it's purpose is to parse the argument, but a lot of implementations just handle it right there inside that callback. What do you think about that approach? Instead of having to store the arguments somewhere we can just handle them right there. Callbacks seem like a much cleaner approach.

There is duplicated code in MainWindow::handleCommandlineArguments_gui() and in MainWindow::onExternalData() that needs to be consolidated somehow. The previous suggestion of using a callback might take care of this since regardless of whether the arg was coming via IPC or direct, it would be handled by the same method.

Another issue is that linuxdcpp --connect --show will try to open up a hub called "--show". We need to either validate args are passed to --connect/--magnet before sending IPC or to send some delimiter in IPC command. Or both.

Yes, N_() is just so they can be extracted to the pot file for translation, so it needs to be added even if glib is calling gettext() on them. I wonder how do long name options get translated though?

Hmm...nevermind, I don't think --existing would be better. It would make sense if linuxdcpp opened up multiple instances for the same config dir and you want to tell it to not do that, but it doesn't. But if we were to make --show default like we said, is it even necessary to keep this option? I guess the reason for it in this case is that we don't want to bring the window to the foreground if a url was passed unless they explicitly say so? What do most other programs do in this scenario?

So no thoughts on dbus?