Comment 13 for bug 361735

At first it was in main, but I thought it cluttered the thing a bit. I'd say a separate function is better (doesn't have to be in WulforUtil). We can move it to a regular function defined in wulfor.cc. I've already changed the parse function to use separate struct passed to instead of using one in WulforUtil. Just have to check that diff before I commit it.

I'll look into the handleCMDline & external data..

About the --connect --show, don't do it :P. I actually hoped that GOption would have done that kind of validation already, but as it seems it doesn't I don't think we should bother with the validation either. Current connect dialog already behaves similarly and does no validation at all. (Plus if you happen to add space before adc hub address in connect dialog it opens the connection, but after that just sits there...)

The current show parameter is a bit useless, since it will be changed to default action if the profile is locked. I replaced the --show with --existing, but changed the behavior so that it won't start a new instance if one isn't already running. Running linuxdpp with no parameters brings it to visible are, and giving some other command just executes the command. If other commands are combined with --existing it would bring also the window up which doesn't make sense, so maybe --show should also be added? This needs some more thinking to make the behavior logical.

Didn't really think about DBus at any point. Pipes are more lightweight and easier to handle and I think in case of multiple running instances the commands are easier to direct to specific instance (of course when linuxdcpp is used as a remote that isn't such a huge deal, but echo to pipe vs. dbus-send). Not saying that we couldn't switch to DBus at some point.

--RZ