Re: Rethinking emblems

On 4/4/05, Alexander Larsson <alexl redhat com> wrote:
> On Sun, 2005-04-03 at 15:15 +0200, Andreas Nilsson wrote:
> > I have done a small writeup on some smarter way of using emblems.
> All interesting ideas. I like the automatic embleming. 

I think that having Nautilus add emblems to folders automatically is a
very good idea. I have been doing some thinking about the possible

First of all, I think that a custom emblem should be added to a folder
where a very large percent of the content is one one mime type. For
example, my music folder shared on the Network as a samba share, and
windows media player adds one cover art to each album's folder. For a
folder of 12 mp3 files and one jpeg file, the emblem should of course
be the music emblem. Maybe for example, if more than 90% of the files
in one folder are of one mime type, Nautilus should give that folder
the appropriate emblem automatically.

There has been a lot of talk recently in the Gnome community recently
about optimation across the dektop, and of reducing disk-access. If
automatic emblems were to be implemented, disk access would be
increased. If I have a folder called 'Music' on the dektop, that
contains 2000 mp3 files, Nautilus would have to read the contents of
the folder to know the mime type. This would require 2000 more file
loads than a file manager that does not automatically add emblems to
folders. Obviously the major mime-type of a folder could be cached in
a hidden file.

Another point that needs consideration is recursion. My music is
arranged [My Music\Artist\Album\] The Artist folders themselves
contain no music files, but I would expect nautilus to know that their
subfolders only contain music, and thus they should have a musical
emblem, and that the My Music folder also should have a musical
emblem. Having such recursion, however, would increase the need for
disk access even further.

Has anyone else any ideas?

Best Regards,

Marc O'Morain

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]