FreeLists / openbeos / [openbeos] Re: clipboard, etc

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

"Jonas Sundström" <jonas@xxxxxxxxxxx> wrote:
> "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> > > cpindexes
> > > http://www.bebits.com/app/3928
> > That one could be taken over into mkindex, though.
> > Would be a nice addition.
> Personally I wouldn't mind if the *index utilities were
> combined into one, to reduce clutter.

Hm - at least mkindex and lsindex are far enough from each other to 
justify different commands.

> > Although it's probably not known, the desklink command
> > provides at least a part of this functionality.
> My 'deskbar' and the original 'desklink' didn't have any overlap. The 
> Haiku 'desklink' has been pushed beyond its original concept. 
> Desklink, 
> as the name implies, was meant for making links (or command menus) on 
> Deskbar's replicant shelf. I don't think the name implies that it's a 
> "link" to [the features of] Deskbar. (but since when are computers 
> and 
> apps logical?..)

AFAIK (but I could be wrong here) the desklink command always had these 
features but nobody knew.

> I created 'deskbar' to be a complete BDeskbar shell command. The 
> concept is clear, as is the argument syntax, unlike that of desklink, 
> which has always been a little strange, IMO. (Many of Be's shell 
> tools 
> have poor argument syntax, and poor --help texts.)

Definitely, Be's commands are often close to crap - the commands in our 
repository are often far better with this.

> Anyway, all this is in vain, as desklink in its current form is in 
> cvs, 
> the "R5 feature freeze" prevents any additions beyond mere mutations 
> (e.g. desklink), and I have neither cvs access nor the power to 
> conjure 
> any kind of consensus on the issue. Feel free to prove me wrong 
> though!

Well, you probably don't have CVS access or you should know better at 
least :-)
We have certainly added and improved commands, so a deskbar command 
could be a sensible addition as well.
I am just not sure how many Deskbar related features should be on the 
command line anyway. What makes sense and why or where?

> > Almost completely covered by the "open" command.
> 'open' can't open the preferred app of a mime type, like this: 
> 
>       siglaunch  text/plain
> or 
>       siglaunch  text/plain  /path/to/whatever.txt

"open" always uses the preferred app to open a file, but it also allows 
you to specify a different "open with" application - in any way, I 
think (thanks to François) the "open" command is much more useful and 
completely sufficient. Just another similar command would just add 
confusion IMO.

Bye,
   Axel.