Re: Application roles - first steps

[Enrico Sersale]

On 2004-02-21 17:39:18 +0200 Stefan Urbanek <stefan@agentfarms.net> wrote:

> > On 2004-02-20 13:04:38 +0100 Enrico Sersale <enrico@imago.ro> wrote:
> >
> > > On 2004-02-18 22:31:09 +0200 Stefan Urbanek <stefan@agentfarms.net> wrote:
> > <snip>
> > > > You can also add the role into inspector, if it is no problem (it should 
> > > > be shown there regardles of user preferences). However, the point of 
> > > > adding it directly to the viewer and enabling it by default was, that 
> > > > users can see that something like roles exists. For the time being, user 
> > > > defaults can be used to configure that, no need for preferences UI, if it 
> > > > is a problem.
> > > >
> > > > Is that possible?
> > >
> > > Yes, but I don't know if it is a good idea to show something more then the 
> > > file name in a browser column or under an icon. I think that we should 
> > > always use inspectors for these kinds of information.
> >
> > Why not? Browser/icon should show information that is most relevant to the 
> > user. It does not have to reflect implmenetation, which is filename in this 
> > case. You do not need filename for application, you need application 
> > function/name, which is in this case described by its role and optionaly 
> > real name. Well, most of users do need this. And there sill will be an 
> > option for showing filenames.
> >
> > <snip>
> Ok. You convinced me :) (The problem is that, sometimes, I'm a bit 
> reactionary regarding
> this. Probabably I'd still use the old Mac OS 7 Finder, If I could).
> But I can understand that the future is in this direction...
> And, extending your concept, I think that I'll implement this not only for 
> applications but for any kind of file.

Well, I'm thinking at this and the first problem encountered is that I need 
this feature in many places and, splitting GWorkspace in some apps, as I'm 
doing, in many applications.

So, the concept is that I need an external object that, given a path and a key 
representing the desidered information, returns the right representation.

To test this, I've written a little daemon with a method named "-nameForPath:".
For the moment, -nameForPath: does nothing; it waste intentionally some time to 
simulate
its work and then returns the lastPathComponent of the path.

It seems that this doesn't slows down the browser very much; I've tested with two 
"big" directories, /dev and /usr/lib, and I get a factor of 2.1 for /dev and 
1.4 for /usr/lib. But, in the normal use, I don't notice any sensible change.

My only concern, for such a solution, was the speed. After the test, it becomes 
a very interesting thing, also opening the way to some possible extensions to 
this concept.
Moreover -nameForPath:, this daemon could have acces to any kind of metadata associated 
with the path. Think at the "Comments:" field in the Info window of the Mac 
Finder, for example.

So, now I need some suggestion for the name of the daemon and for the keys to 
use to get the representations. (Even if I can write a version returning just 
the lastPathComponent, for the moment).

> <rest removed>
>
> Stefan Urbanek