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

List:       kde-look
Subject:    Re: Accordion Folders
From:       Dave Leigh <dave.leigh () cratchit ! org>
Date:       2000-02-11 13:57:12
[Download RAW message or body]

Andreas Pour wrote:

> Ben Last wrote:
>
> > > From: pour@mieterra.com [mailto:pour@mieterra.com]
> > > Dave Leigh wrote:
> > > > Today a co-worker suggested that an "accordion folder" icon should be
> > > > used for folders that contain other folders.  On the face of it this
> > > > sounds like a reasonable UI enhancement to me, especially if it were
> > > > supported in the tree view.
> > > It would be a nice feature but would also slow things down a lot -- you
> > > would have to open each subdirectory and, in the worst case, determine the
> > > type of each entry in the subfolder.  Listing directory contents is already
> > > too slow IMHO.
> > Apple's MacOS used to do this for folder sizes - it ran a low priority task
> > that recursively added up sizes of all folders.  'Course, without pre-emptive
> > multitasking it was a pain in the patookus...
>
> > Once a folder's been identified as containing other folders, one need only
> > reassess that statement when the directory's been modified more recently than
> > whatever contains the status.
>
> It's also a single-user system and also a system where the GUI designers had
> much more control over the file system.  Problem w/ KDE is, you may not be able
> to write in a directory to cache that info.  This same issue comes up with
> caching file mimetypes -- there's nowhere really to store that info.  Finally,
> directories can have soft links, and can be mounted.  At one moment they can
> point to a file, the next to a directory (if what a link is pointing to
> changes), the next to nothing (if a directory is unmounted).  Thus you could not
> be sure the information is accurate (you may not care, either; you can always
> fix the error when the user selects the folder).
>
> I think telling whether a file has changed is difficult over NFS on some
> systems, but maybe that problem's been solved.
>
> > In other words, there are definitely some elegant ways around the speed issue
> > if it appears that it's a useful feature.
>
> Right, if your concern is less with reliablity (which is quite reasonable in
> this case) and coding quite a bit (caching stuff in light of the various
> difficulties is not a trivial matter to code).
>
> Ciao,
>
> Andreas

Well, this is certainly low priority, and it's only necessary to indicate that
subdirectories exist, not how many.  The recursive Mac task seems to be overkill,
IMHO.  Perhaps for speed the directory can be displayed with the default folder
icon, then a background task can change it as the info is gathered. If you've got
write access to the directory, the appropriate icon could be stored in the
.directory file.  NFS directories and symlinks can be processed last, as they'll
take longer, and (at least with symlinks) you've already got the crooked arrow
overlay telling you there's something different about these folders.

--
    mailto:dave.leigh@cratchit.org
    http://www.cratchit.org/dleigh

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