[Portland] command line interface inconsistancies

[Bryce Harrington]

On Wed, Jun 07, 2006 at 09:24:33PM -0700, Bastian, Waldo wrote:
> >> 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 

Okay cool.  :-)
 
> >> 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).

Hmm, yeah I don't have a strong use case for it either.  It was useful
for testing, but I only included it here because it was an easy thing to
include.  I can see the point that a user could get confused at e.g. the
difference between 'suspend' and 'disable' and call the wrong thing.
I've removed it from the script.  I suppose if a use case turns up at
some point in the future, it'd be a pretty trivial thing to add back in
later. 

> >> 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?

Since you can't count on the suspend functionality recently implemented
in Xorg to be there all the time, yeah this is definitely appropriate to
include in this package, regardless of how long the screensaver is
delayed.

Also, why would anyone bother to delay a screensaver for only 5 minutes?
Most presentations where screensavers become an issue last at least 30
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?

It controls the timeout and cycle values, whether the screensaver is on
or off, whether or not the screensaver is enabled or disabled, and the
power management state/settings too.

Bryce