[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application roles - first steps
From: |
Enrico Sersale |
Subject: |
Re: Application roles - first steps |
Date: |
Sun, 22 Feb 2004 18:02:55 +0200 |
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
- Application roles - first steps, Stefan Urbanek, 2004/02/16
- Re: Application roles - first steps, Enrico Sersale, 2004/02/17
- Re: Application roles - first steps, Stefan Urbanek, 2004/02/18
- Re: Application roles - first steps, Enrico Sersale, 2004/02/20
- Re: Application roles - first steps, Stefan Urbanek, 2004/02/21
- Re: Application roles - first steps, Enrico Sersale, 2004/02/21
- Re: Application roles - first steps,
Enrico Sersale <=
- Re: Application roles - first steps, Stefan Urbanek, 2004/02/22
- Re: Application roles - first steps, Enrico Sersale, 2004/02/23
- Re: Application roles - first steps, Helge Hess, 2004/02/23