[haiku-development] Re: Some Tracker capabilities I'd like to see
- From: <looncraz@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 28 Dec 2012 17:04:49 +0000
---- pete.goodeve@xxxxxxxxxxxx wrote:
>
> First, it would be nice if a file (or mimetype), as an alternative to
> Preferred Application, could have a "Preferred Shell Command". This
> would satisfy Jimmy's desire to be able to invoke a Java command line
> on a jar file by clicking it. Presumably this would need a new attribute,
> set by some extension to the FileType(s) prefs and add-on.
>
Okay, this is a good idea - on the surface.
But, I don't see the need for any new attributes. Why not, instead, allow
refactoring the execution string of the preferred application for a specific
file type right in FileTypes. That way I could set a default action in
FileTypes for, say, '.loon' that will execute a series of commands - which
could include opening a Terminal and running a script...
I see an issue, however, with allowing files to have a hidden script. I could
send you a harmless text file and add be-shellcmd with "rm -rf /boot/home/*"
or something mean like that... System-wide or bust - I say. If you need
anything more specific and limited in scope (to say a single file)... just make
a script.
> Sort of in the other direction, could an app icon be allowed to accept
> other items than a file being dropped? I quite often want to process,
> say, a link dragged from the browser, or a clip of some kind. Currently
> I use my 'Ycon' invoked by a script, but that all has to be running first,
> rather than just being able to drop the drag onto a desktop icon to start
> things.
>
This occurs though BApplication::RefsReceived(...) on application launch. In
order to open an application and send it anything other than the appropriate
refs or args (BApplication::ArgsReceived(...) / main(...[args]...)) it would be
necessary to send the dropped message directly to the BApplication object -
which most apps are currently designed to handle - so whether or not the app
would behave properly is a huge unknown and could result in programs launching
in an empty state and losing the contents of the dragged message. You also
need to know if the program can handle the message type - so you need to know
the data type of the message. A file compressing program won't know what to do
with anything other than files (in most cases), an image viewer wouldn't know
what to do with text, and so on... Here, new attributes might come in handy,
with an app declaring that it can handle text or bitmap (or both) messages
dropped on its app icon in addition to file refs of a certain type (or no file
refs as the case often is...).
> why don't executable scripts have a distinct icon?
+1
I also feel the source-code icon is too pastel and indistinguishable from the
generic icon until you zoom in (at least at 1080p). I changed the colors to
greens to make source files stand out - much better!
Overall, good ideas. I have a few ideas and issues with the responsiveness of
Tracker on Haiku (vs BeOS) as well, but that is its own topic for later
discussion...
--The loon
Other related posts:
