Hi,
I forgot one topic:
enabling/disabling options
This one is tricky. I really like the +/- syntax for enabling and disabling
options. For instance, we can enable or disable the wallpaper this way:
+wallpaper or /wallpaper enables the wallpaper
-wallpaper disables the wallpaper
This allows for creating an enable *and* a disable option from the same
option in an automated manner.
With the old syntax, we had --disable-wallpaper. Not only this is twice
longer than the new option, there is another issue: there is no equivalent
option to *enable* the wallpaper. What happens if the wallpaper is turned
off by default, and you want to turn it on? Default options now being
configurable through many different means, such as .rdp files or registry
keys, you can't assume the default is always the same and for most toggle
options you need both an enable and a disable option.
How would you map the +/- syntax to the --option syntax?
Should we automate the creation of --disable-wallpaper and
--enable-wallpaper for the "wallpaper" option? Is there anything standard
for this? What about --no-wallpaper, --with-wallpaper, --without-wallpaper?
We have a LOT of such options that we need and that can be configured
through various means so the default can't be assumed any more.
What would you suggest for this particular issue?
In the old syntax, we had options like this:
--disable-wallpaper
--disable-full-window-drag
--disable-menu-animations
--disable-theming
Now, it's definitely much shorter and flexible:
+fonts (default:off) Smooth fonts (cleartype)
+aero (default:off) Desktop composition
+window-drag (default:off) Full window drag
+menu-anims (default:off) Menu animations
-themes (default:on) Themes
-wallpaper (default:on) Wallpaper
Let me know if mapping +/- to --enable- and --disable- is the way to go, or
please point me to a more standard way to do it. It's definitely much less
efficient than +/- anyway.
On Sat, Dec 1, 2012 at 1:20 AM, Marc-André Moreau <
marcandre.mor...@gmail.com> wrote:
> Hi,
>
> Yes, the command-line interface has been completely changed. There are
> reasons for this, such as the fact that the old syntax was very inefficient
> and not flexible enough. I did some research on existing command-line
> syntaxes, their strengths and weaknesses, and came to the conclusion that
> the most efficient syntax in our case would be the syntax which is more
> "windows-style" with / and +/- for enable/disable. The +/- option is very
> practical, but requires that - does not mean something other than minus.
>
> I have worked on a generic command-line parser that accepts a variety of
> command-line syntaxes. It would therefore be possible to work on adding
> support for a more "linux-style" command-line interface as an alternative
> syntax if there are some of you who really like to type longer commands.
> Trust me, it does look weird, but there is definitely a gain in how
> commands are shorter in the end. Some users on IRC seem to like it better
> once they've come over the fact that this is a more of a windows-style
> syntax.
>
> I have based my command-line parser based on this article:
> https://pythonconquerstheuniverse.wordpress.com/2010/07/25/command-line-syntax-some-basic-concepts/
>
> I will look into the other links which were sent for the standard POSIX
> command-line syntax and will consider adding support for it. Both syntaxes
> would then be usable, making everybody happy.
>
> However, besides the command-line syntax, the option names were changed.
> The new options are mstsc-compatible from the start, and then extend with
> our set of options. For your code that invokes FreeRDP, you should
> basically have to migrate only once, when you decide to upgrade to the
> upcoming FreeRDP 1.1 release. FreeRDP 1.0 will simply be the last release
> with the old syntax, 1.1 and later will use the new set of options and the
> new syntax. Otherwise, we'd have to forever be stuck with the old syntax
> and its issues.
>
> If in the previous syntax, you would launch a remoteapp program this way:
>
> xfreerdp --app --plugin rail --data "||cmd" -u username -p password -d
> domain hostname
>
> The equivalent now becomes:
>
> xfreerdp "/app:||cmd" /u:username@domain /p:password /v:hostname
>
> That's putting aside huge gains for loading sub-plugins, like for device
> redirection or dynamic virtual channels:
>
> xfreerdp --plugin rdpdr --data "drive:media:/home" -- hostname
>
> which now becomes:
>
> xfreerdp /a:drive,media,/home hostname
>
> Or for multimedia redirection:
>
> xfreerdp --plugin drdynvc --data tsmf -- hostname
>
> which now becomes:
>
> xfreerdp /dvc:tsmf hostname
>
> Some of the issues with the POSIX standard command-line syntax is mainly
> with the usage of spaces inside argument values. From the link you've
> given, I see the following guideline:
>
> *Guideline 10:* The argument *--* should be accepted as a delimiter
> indicating the end of options. Any following arguments should be treated as
> operands, even if they begin with the '-' character. The *--* argument
> should not be used as an option or as an operand.
>
> Ok, we can definitely handle that, but it means that for any
> variable-length list of values to an argument, we need to follow this
> guideline, since there is effectively no way of knowing where exactly the
> list ends. This is why we had the -- as a end delimiter for the list of
> --data parameters.
>
> /option:value drops the space, and makes it unambiguous from the start. A
> single element in the argument vector argv contains both the option and its
> value, period, no need to look for the value over multiple other elements
> of the argument vector.
>
> As for lists, I've decided to simply use comma-separated lists, which
> usually do not conflict with other symbols. For the previous syntax, we had
> the issue of : conflicting with paths like C:\, it was extremely annoying
> for drive redirection and remoteapp.
>
> So, here's what I suggest:
>
> Take a look, see what the real issue is. If there is enough demand for it
> I can look into simply adding support for the standard POSIX syntax and
> have exactly the same set of options usable with either one of the
> syntaxes, where the default syntax will remain the current one. Before
> parsing the options, a simple detection function will check for which one
> of the two syntaxes has been detected.
>
> This will still not fix your problem of compatibility, because option
> names have been changed. I can't help for this, as we need to move forward
> with a more suitable set of options.
>
> You can find the current generic command-line parser here:
>
> https://github.com/FreeRDP/FreeRDP/blob/master/winpr/libwinpr/utils/cmdline.c
>
> And here is where the client command-line options are being parsed with it:
> https://github.com/FreeRDP/FreeRDP/blob/master/client/common/cmdline.c
>
> You'll notice I'm passing flags to the parser indicating which syntax to
> parse the arguments with. We could basically implement the standard POSIX
> syntax and use the same options but with an alternative syntax.
>
> What do you think?
>
> Best regards,
> - Marc-Andre
>
> On Fri, Nov 30, 2012 at 7:49 PM, Kevin Dalley <kdal...@vmware.com> wrote:
>
>> I recently noticed that the master branch of FreeRDP has a change in the
>> command line interface.
>>
>> The new command line options no longer follow the POSIX standard for
>> command line interface or the GNU standard for CLI.
>>
>> Here are references for both standards:
>> POSIX:
>> http://pubs.opengroup.org/onlinepubs/009604499/basedefs/xbd_chap12.html
>> GNU:
>>
>> http://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html
>>
>> I strongly recommend that any tool which runs on Linux follow these
>> standards,
>> rather than create a new command line interface. This interface is
>> completely different from
>> any other tool which I have used on Linux.
>>
>> At VMware, we ship an application which runs xfreerdp, or alternatively,
>> rdesktop.
>>
>> A change in the command line interface breaks compatibility for us. We
>> would have to verify which version
>> of xfreerdp is available, and then choose which version of command line
>> arguments to use. Of course,
>> this problem can be worked around, but it is an ugly addition to the code.
>>
>> For those who haven't looked at the new command line interface, here is a
>> summary.
>>
>> Usage: xfreerdp [file] [options] [/v:<server>[:port]]
>>
>> Syntax:
>> /flag (enables flag)
>> /option:<value> (specifies option with value)
>> +toggle -toggle (enables or disables toggle, where '/' is a synonym of
>> '+')
>> /v:<server>[:port] Server hostname
>> /port:<number> Server port
>> /w:<width> Width
>> ...
>>
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> _______________________________________________
>> Freerdp-devel mailing list
>> Freerdp-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freerdp-devel
>>
>
>
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
