On Sat, 2010-02-13 at 00:32 +0800, Allan Caeg wrote:
> Hi All!
>
>
> Thanks for the ideas. To be clear to everyone, I never proposed the
> removal of access to files through a file manager. You're right. On
> the desktop, there's a number of reasons why the file manager should
> be available. Actually, I believe that the file manager should also be
> visible on the iPhone and iPad. It's nice if things work smoothly
> without needing a file manager, but there are some instances when we
> need one.
>
>
> I agree with Allan Day's idea of a document manager. Perhaps, this is
> one of the things operating systems need. It's nice that, by default,
> distros have folders like "Documents", "Templates", "Music", etc.
> However, like what Ian said, I think it would be better if the view of
> the file manager is more fit for the nature of files inside a certain
> folder in general and not just for documents. Actually, I know people
> who play music on the file browser. They look for their songs on the
> file browser then double click them to play them on the media player.
> Personally, I also don't use an image browser. I view them all on
> nautilus.
>
>
> What can you suggest? :)
>
>
> Regards,
> Allan (Caeg)
This discussion (and the Actions spec discussion on FD.org) is quite
interesting to me. I've been quietly poking at something which may work
here :)
Nothing to show yet, since it's mainly just a rough design at this point
(I'm working on a basic implementation, albeit amongst too many other
things, in the interest of having a cohesive vision before putting it
out there). The idea is for individual applications to define sinks and
sources for files. So, Cheese acts as a source for files of type
image/png, Banshee is a sink and a source for various music formats.
Then there's a switchboard daemon running in the middle which will be
aware of all these sinks and sources. Applications looking for files
talk to it, and it provides them a list of possible sinks / sources that
will provide a file of the given type. Ultimately the application
decides on one, so a transaction is created and the application
communicates with the selected sink to either give it a file or get a
file (or multiple files) from it.
It's a little bit unusual because "an application deciding on something"
is usually it asking the user to choose / create something.
This basically allows any application to act as a file save or file open
dialogue. LOTS of cool stuff then appears:
* As discussed here, we aren't torturing the user with the file
system. There is a SERIOUS problem in the current approach.
Applications such as Rhythmbox, Banshee, Cheese and F-Spot try
to abstract files away so that they are music and photos. This
works great, but as soon as the user wants to do something not
supported by those applications (such as uploading a photo as an
identi.ca profile picture), they turn back into photos. This is
WORSE than having no abstraction at all. (And that's saying
something, because making users work in the limited world of
files and folders is ridiculous).
* Android has file pickers running out of process for a fantastic
security goal: an application is only given access to the user's
files if he explicitly chooses them. That could be done here.
* Today's file managers don't work well when we have multiple
applications for a given file type. So, while we're at it, we
can kill off the Open With menu and reinvent the double click.
One click opens a bubble with information about the selected
file and a list of applications which will do stuff with it. A
second click on the file icon opens it in the default
application, or the user can pick a different tool really,
really easily.
* A bit of fiddling with sources and we could have a button
wherever a file does not exist but could. Clicking it could open
a picker much like the file open picker, but to create a file.
The point here is to create a consistent flow of steps for
people, so they don't need to switch erratically between opening
applications from the main menu and opening (or saving) files
from the file browser.
* Hints (open-ended key / value pairs) every step of the way. For
example, I'm jealous of how MacOS's Finder gets a little
animated transition when a folder opens into a new window (it
shows that new window coming out of the icon). I think we can do
better :P
So, err, basically I'm doing something along these lines. If someone
wants to beat me to it, I would love to know so I can help out! :)
Most of the trickery here will be in how the surrounding applications
use it, after all.
Bye,
Dylan McCall
Attachment:
signature.asc
Description: This is a digitally signed message part