On Sun, 2009-05-03 at 22:04 +0100, Alex Anthony wrote: > El dom, 03-05-2009 a las 13:24 -0700, Dylan McCall escribió: > > > On the other hand, this also suggests that I think calling GNOME Shell > > "the shell" is somewhat flawed. The underlying philosophy with Calcium, > > no matter where it goes, is that /everything/ is the shell. (Hence the > > name; shells have a lot of calcium. There, if it has a pun THAT great, > > it must be awesome!). > > Want it to be a fd.o standard? Call it FileKit. Sorry, had to say it. > But it does have the sort of standard interaction ring to it. > > > > When an application is added to the system, it is an addition to the > > shell. Rhythmbox's music library should be no less a part of the shell > > than Nautilus or the GTK file chooser. It abstracts the storage of > > files, in this case music, allowing the user to choose them for some > > purpose. If we can accomplish that type of seamless, smooth bridge > > between everything, users will never need to think "files" unless they > > want to. > > Is there a library for each type of file? Which is metadata indexed? > Which is similar to a new windows concept I believe, but we can do it > properly. > Also, how does it get presented at the start to the user? > > Alex > I look at this from a slightly different perspective. I think the View / Edit distinction is, while an improvement from the mere "open" we have today, totally arbitrary. It creates unnecessary limitations for the simple purpose of limitations and down the line we'd be adding to that spec "view quickly" "annotate" and "print", because we failed to make it flexible enough. Instead, each application should present each of its tasks with an icon, a description and a name. It's up to that application to be coherent. We rely on a wonderful thing called natural language to explain to the user what is going to happen with the user's content when a task is invoked. For example, "Edit image with GIMP" and "View with Eye of GNOME." It is strangely trivial, but I seriously think (done right) such a system would solve a boatload of usability problems and make developer's lives a lot easier. Granted. the View / Edit distinction saves us from having redundant tools in that list, but then different applications are different so they aren't /really/ redundant. Besides, we'd still need "View with" and "Edit with" for the former. I think applications can easily make sense to an end user; they are tools to accomplish tasks on documents. The problem today is that documents keep turning back in to plain files and applications cannot be accessed smoothly, for example in a context-sensitive way (and when that is the case the best solution is changing on the fly from a document-centric to an application-centric workflow, launching the application then the document from it). Because they get MIME type associations one at a time, applications tend to be monolithic beasts of insanity because they have to do everything one could need done with the file. "But wait, can't you just go to Open With in the context menu in Nautilus?" That's the funny part :) A lot of this is just philosophy. I rarely encounter users who use (or know of) "open with." (I also encounter tons who despise double clicking because it makes no sense at all). Open With right now is treated as a secondary function in a dark corner of a few applications - something we don't really anticipate users wanting. The concept of choosing a tool to use on something should become normal, initiated by a PRIMARY click. The first step is getting a centralized technology that handles the information for such stuff, then the second step is a set of GTK widgets to make the matter consistent and friendly. Bye, Dylan PS: Sorry about changing the subject line :( PPS: "In this case music..." was a miswording. I meant just in the case of my example. Calcium, of course, should be completely generic. Possibly too generic ;) PPPS: Oops. On another note, I wonder what would happen if applications handled creating their own files in the same direction as templates? Instead of "Create spreadsheet" (copied from Templates folder), we could have "Create a file here with Gnumeric," leading from the user clicking on a GTK widget representing a file yet to be created. It's the same process as opening the tool then creating the document, except the user is getting the document /then/ using the tool.
Attachment:
signature.asc
Description: This is a digitally signed message part