[openbeos] Re: clipboard, etc

"Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
 ...
> > 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.

I realize it would break a few scripts, but if it was up to me,
I'd combine all of the *index commands into one.
Same with the *attr commands.

There are enough /bin entries as it is, and it'll only get worse.

Anyway, cpindexes could definitely be part of mkindex, 
perhaps like this:

  mkindex --copy /source /target

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

This is what BeTips knows about it:
http://www.betips.net/chunga.php?id=414

This BeTips example works with the original but fails with Haiku's 
desklink:
desklink "cmd=Open TipServer:/boot/beos/apps/NetPositive http://www.betips.net/ 
&" /boot/beos/apps/NetPositive

The original desklink:
   desklink remove=/foo/bar

Haiku's desklink:
  desklink --remove=/foo/bar

There's no --list feature in the original, AFAIK.

There's a conceptual glitch in the Haiku version: It lets you add 
desklink replicants, but not "real" replicants. It lets you remove 
desklinks, en masse, but it won't let you remove any other type of 
replicant, yet the --list feature lists all replicants, regardless of 
type. 

The original 'desklink' was only intended for desklink replicants, the 
Haiku version doesn't add much of anything except being able to list 
all Deskbar replicants. My 'deskbar' utility is meant to work for all 
replicants, exposing useful BDeskbar functionality. (And, so what if it 
overlaps with what you can accomplish using 'hey'.)

If a combination is desired, I'd say the desklink funtionality should 
be put into 'deskbar', or deskbar_control or whatever, (ie, a more 
generic name), rather than the other way around:

deskbar --link=/foo
deskbar --list-links
 etc

Or, one could simply rely on the BApplication::ArgvReceived()
of Deskbar itself and have it do all these things internally, as the 
BApp of a Single Launch application will receive additional
arguments on subsequent launches, while already running.

(In a post-Deskbar future it might be a less desireable idea though, 
or for people using replacements, having Deskbar spontaneously 
relaunch now and then would be annoying.)

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

Sure, I know you've been adding all kinds of things.

It's just that around the time I rewrote ZipOMatic, some shell tools, 
etc, I tried to get some things included which got shot down. And then 
there was the ShowImage slideshow hoopla and Michael put his foot down. 

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

I don't see how it could be wrong to expose the C++ API (BDeskbar) as a 
shell command.  Sure, it would overlap with 'hey' and it won't be 
useful or worthwhile to everyone all the time, but it would enable some 
script making, or Spicykey madness. (Prognathous wrote on BeBits that 
he uses deskbar and SpicyKeys to move Deskbar to a better location when 
using Mozilla.) The binary itself would be small and out of harms way.

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

'open' appears to be intended primarily for user interaction,
given its syntax:

 usage: open <file or url or application signature> ...    

The consequence of this is that, unlike with siglaunch,
there's no means to launch an app with a set of arguments.
They would be interpreted as "stuff to be opened", and fail.

It could be given an optional --something,
allowing for an alternative, more rigid syntax, 
primarily for non-interactive use, effectively 
incorporating all of the siglaunch functionality.

/Jonas Sundström.                  www.kirilla.com

Other related posts: