[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    User-accessable filesystem metadata (was: [PATCH] Folder icons
From:       Michael Schuerig <michael () schuerig ! de>
Date:       2004-02-29 20:59:51
Message-ID: 200402292159.51628.michael () schuerig ! de
[Download RAW message or body]

On Sunday 29 February 2004 20:47, Enrico Ros wrote:
> > Also, the term "Overlay" is accurate on the technical level, but
> > not on the user level. From the users point of view this is a way
> > to decorate a folder, or give it special meaning.
>
> Somebody suggested to use "emblem" but "decoration" sounds good too.
> The classes refernces to the overlay as overlay but the popup and the
> dialog can be adapted [done now, set it to "Decoration" :-].

On Mac OS these things are called "badges", I seem to remember.

While we're at Mac OS, starting with System 7, around 1991, it had so 
called Labels. The user could define up to 7 (sigh) categories with a 
short string and a color. Files and folders could be assigned exactly 
one (or none) of these categories. Their icons would be tinted with the 
color and it was possible to find files by label.

Now to KDE. It would be a very welcome addition, if it were possible to 
define an arbitrary number of categories, each comprising a short 
description and a color code, and attach an arbitrary number of those 
to items in the filesystem. Beyond that, being able to attach comments 
to files etc. would be nice.

KDE has some infrastructure to support this: .directory files. Their 
drawback is that the content of the .directory file is only loosely 
tied to the files in the directory, thus it's practically impossible to 
keep metadata in .directory consistent with the actual files. Also, 
users can only (let Konqueror) create .directory file in directories 
where they have write access. The first problem could be solved with 
metadata that is handled by the filesystem itself, though this doesn't 
help with the second problem.

Would it be sensible to store metadata in a user-private directory keyed 
on the i-node number of the file? (With paths as fallback after 
restored backups.)

Michael

-- 
Michael Schuerig              The usual excuse for our most unspeakable
mailto:michael@schuerig.de      public acts is that they are necessary.
http://www.schuerig.de/michael/                      --Judith N. Shklar
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]