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