Re: Applications Unnecessary

["Mike Bursell" <mike hingston demon co uk>]

I worry about the "applications unnecessary" view. One problem, as pointed out elsewhere, is that I may often wish to open a file with various different apps: the GIMP to edit a photo, f-spot to categorise it, nautilus to view it. 

Worse, what if I want want to start a new email, or document, or eclipse project or subversion repository or unison sync or ...? There seem to be lots of tasks that aren't centred around existing files, where templating would just lead to an explosion of files (and do I want to open a text doc in the gnome editor, openoffice or emacs?).

-Mike.

-original message-
Subject: Re: Applications Unnecessary
From: José Luis Ricón <artirj gmail com>
Date: 03/05/2009 9:48 pm

What you are proposing would require the apps to expose their capabilities
(maybe through Dbus) and luckily there's a GSOC project on that line, so the
base will be there if needed.

2009/5/3 Dylan McCall <dylanmccall gmail com>

> > While ideally I tend to think users should not have to care about
> > applications, but only about content, i.e. documents, people, websites
> > and so on, I fear we've not tackled many issues with that approach. I
> > think we really have applications that have the status of first-class
> > objects: think of Rhythmbox, F-Spot, Evolution, even Firefox and
> > possibly OpenOffice.org.
> >
> > These applications can be used to work with a collection of contents,
> > and we're not going to fill the recent documents list with e-mails,
> > music tracks or photos. You could make them be a single meta-document
> > called "Music Library", "E-Mails" or so, maybe, that's a debate.
> >
> > Designs about that are welcome! But IMHO that's not so easy to replace
> > without losing functionalities, and would require a complete redesign of
> > our desktop conception (we're here to do so!).
>
> My thought on this is that the desktop has the need to be both document
> and application-centric at the same time, where some tasks require
> different kinds of workflows. A basic example is that a game is thought
> of as an application that the user directly executes. Another example is
> that a shell like F-Spot, Evolution, Banshee or Nautilus is
> application-centric; you open it to get at documents.
>
> An issue right now that hurts the document-centric approach is that
> applications are only really presented in one way (the towering
> Applications menu, which can quickly become a monstrosity since every
> application is in it). Further, there is nothing to help the user move
> content between them. In fairness, I have yet to see a system that
> does /better/; everything is equally bad at it.
>
> There are a few feeble pipes like drag and drop, and the file chooser
> widget in any UI toolkit, but nothing fully functional. In the process
> of getting a document from one place to another, the abstraction we have
> will inevitably burn down, leaving the user to contend with raw file
> management. The most obvious example is when uploading a photo to a web
> site. It very quickly stops being a "photo" and starts being a "file,"
> because the only integration we possess with the local system is the
> file picker opened by the web browser.
>
> Two solutions. The bad one everyone seems hung up on is over-engineering
> the one, poor, generic file manager so it does everything from rating
> music to playing slideshows and paging through PDFs. Don't do that.
>
>
> I've been pondering this issue, poking REALLY cautiously at a dead
> simple framework that should accomplish better interconnection between
> applications for the end user.
>
> Going against common sense, I'll post a link to some early ponderings...
> http://docs.google.com/Presentation?id=dgv4sbqn_23857c92hg
>
> The reason I'm poking carefully is because it feels too trivial and I'm
> afraid of building "yet another component framework" or a bizarre clone
> of drag & drop without the dragging. The plan is to plug in to what
> exists today for most types of data, allowing for seamless transition to
> awesomeness with very little extra infrastructure. It's really more
> about the design philosophy.
>
> My writing skills today are seriously broken, so I'll leave it to that
> little slideshow thing. Basically, I'm thinking of a framework and UI
> toolkit stuff that lets an application say "I provide content" or "I
> take content". This way applications could better interconnect, for
> example with nice context-sensitive application choosers. Opening a file
> from an application? Get a list of applications to browse for that file
> with. No more clicks than with a generic file manager, though
> considerably more logical. For example, the user may want a photo, so he
> chooses to open a photo and conveniently has the option to find said
> photo with F-Spot, or gThumb, or whatever application he had "stored it
> in" to begin with.
>
> It's about glue. It has to work both ways and it must be applied in lots
> more places. You can't have a towering menu and call that sufficient
> gluing, even if we do have drag and drop:)
>
>
> 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!).
>
> 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.
>
>
> Bye,
> Dylan
>
>
> PS:
> Sorry, my homework-fatigued brain thinks this message may be a complete
> jumble. Hope it isn't too bad...
>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>

_______________________________________________
gnome-shell-list mailing list
gnome-shell-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list