[Panel-devel] The ALI: do we really need or want it?

[Janne Ojaniemi]

On Monday 09 January 2006 18:07, Friedrich W. H. Kossebau wrote:
> [Resent, as the first did not seem to make it to the list]
>
> Hi,
>
> Am Sonntag, 8. Januar 2006 12:16, schrieb Janne Ojaniemi:
> > On Saturday 07 January 2006 22:08, Brian Beck wrote:
> > > I'm sorry I still don't understand, if this new system is going to work
> > > like
> > >
> > > 1. select songs
> > > 2. juk opens
> > >
> > > I prefer todays
> > >
> > > 1. juk opens
> > > 2. select songs
> >
> > It doesn't quite work that way in reality. In first case, you locate the
> > content you want to use, and be done with it.
>
> But before that you
> 0. locate the app where you can locate and select the songs ;)

I do not consider Kmenu/Content-menu to be an application. But if we want to 
go down that road, then using apps has three steps: 0, 1, 2, while using 
content-menu has two steps: 0 and 1.

> Do not forget that in the presentation of some content there is always a
> program involved. Content does not appear by itself on the screen :)

But the user does not have to know about those systems. I do not know about 
all the whiz-bang technology that gives me the Kmenu. And this is pure 
semantics anyway. The Content-menu would be quite similar to Kmenu. 
Difference would be that instead of categorizing and listing apps, it would 
categorize and list content. So, as it happens, most of the criticism thrown 
against the content-menu could be applied against Kmenu as well.

> The trick is to make the program disappear so one feels to deal with the
> content (via some program) rather than to deal with a program.

Again: content-menu is not a program IMO. It's a menu used to access content. 
There might be all kinds of whiz-bang technology involved (tenor, 
virtual-folders etc.) but there is no need for the user to know about any of 
it.

> So take the all-content browser/handler (konqueror) and a special-content
> browser/handler (for music e.g. amarok).

This approach has the problem of being application-driven. I mean, if you want 
to access your content, you have to do it with an application (Konqueror). 
And that is exactly the thing I'm trying to move away from. The focal point 
would be the content. If there's an app acting as a gatekeeper, the 
focal-point becomes that app.

> Do you really care that
> clicking on this icon starts the registered music browser/handler? All you
> care for is that you get access to that content. And you do.

Yes. My proposal is not really about how we use content. In my proposal they 
would be used in same way as they are used today: with relevant applications. 
My proposal is about how the content is presented to the user. Today, it's 
presented through several different applications. Some show the content right 
(like Amarok and Juk do with music), others just show the raw files 
(Konqueror). 

> So if there were mimetypes and/or rather urls/uris for all my music files,
> all my emails, $your_special_content_or_subset_of, etc. you could register
> your favourite handler/browser program like you do now for other things.
> Then put a link to that content somewhere, have it display the content
> type, but starting the registered program if clicked.
> Have a close look and discover the pattern yourself :)

Yes. In the end, this is not that different from how things are today. You 
have bunch of different files (video, music, pictures, documents etc.) and 
each type of file has an application associated to it. When you click that 
file, it gets opened in the associated app. If you want to open it with some 
other app, you right-click it, and select the correct app. And that would be 
EXACTLY the same with the content-browser. Only difference is how the content 
is presented to the user. Instead of going through different apps, we could 
access the content directly. 

Having a system like this would put KDE at the forefront of 
content-management. Vista and OS X have something similar, but their attempts 
seem to be half-hearted attempts, whereas this attempts to be a total 
solution :).