[Portland] command line interface inconsistancies

Bastian, Waldo waldo.bastian at intel.com
Wed Jun 7 21:24:33 PDT 2006


>On Mon, Jun 05, 2006 at 11:16:50PM -0700, Bastian, Waldo wrote:
>> I have improved the presentation of the command line options in the
>> man-page. Each different action now has a synopsis line of itself.
Most
>> of them are now along the lines of
>> 	xdg-comand --action [--option xxx] --option yyy FILE
>>
>> See
>>
http://webcvs.freedesktop.org/*checkout*/portland/portland/xdg-utils/scr
>> ipts/html/xdg-mime.html for an example. Note that the scripts
themselves
>> haven't been updated accordingly yet.
>>
>> Let me know what you think.
>
>As mentioned in a previous email, `xdg-command action [--option] FILE`
>is a more conventional style.  I would recommend using that in favor of
>--action, as it may confuse the difference between actions and options.

Ok, I'll change it to 

xdg-mime query what FILE 

xdg-mime install { --user | --system } mimetypes-file 

xdg-mime uninstall { --user | --system } mimetypes-file 

>> Xdg-screensaver ... drop "enable" and "disable" as options and
>> remove the <delay> argument from "suspend" and default to 5 minutes.
>
>Please explain why you feel this would improve the script.  I put these
>in to maximize the usefulness of the script, and removing them could
>risk making it not worthwhile to use.

The reason for having the "suspend" option is to make sure that the
application doesn't "forget" to re-enable the screensaver again. By
providing plain "disable" / "enable" functionality without any
safeguard, developers are likely to use that instead of the "suspend". I
don't want to encourage that kind of bad practice. (Compare to the
recently added screensaver suspend functionality in the X server that
automaticaly restores when the client exits)

Having a <delay> option allows for the same lazyness... instead of
pinging the screensaver every 5 minutes, developers are more likely use
"suspend 200h"/"restore" as a poor mans "disable"/"enable".

Personally I don't see strong use cases for these options (but feel free
to convince me otherwise).

>> I'm
>> also inclined to remove "restore" since I don't think it's really
needed
>> if the screensaver gets re-enabled after 5 min. anyway.
>
>Actually, I would discourage removing that.  It is actually one of the
>most useful functions in the package, because it is guaranteed to
>"reset" the system to the starting state.  In other words, this is the
>command applications will call when they terminate normally, in order
to
>put everything back the way before they started.

Is that really needed if the screensaver is delayed for at most 5
minutes?

>Also note that restore involves restoring several settings, not just
>whether or not the screensaver is currently on or off.

What other settings does it control then?

Cheers,
Waldo


More information about the Portland mailing list