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

List:       kde-usability
Subject:    Re: Directory Editor
From:       Christoph Niemann <cnieman () suse ! de>
Date:       2004-03-17 15:26:00
Message-ID: 200403171626.00896.cnieman () suse ! de
[Download RAW message or body]

On Tuesday 16 March 2004 02:27, Jamethiel Knorth wrote:
> As I noted in 'A fair critique to KDE usability' I think there needs to be
> a directory-types editor for KDE, just as there is a file-associations
> editor. I have been brainstorming for a bit, and have enough for suggesting
> it.
>
> As far as the interface, I have only made as much progress as saying it
> would be basically like the file-associations editor. I can do more, but I
> don't even think this will be implemented soon, so I haven't gotten on it.
>
> First, a Directory-Type would be defined according to a lot of criteria:
> - Protocol
> - File Types
>   - Amounts of File Types
> - Being at a Specific Path
> - Containing Specific Files/Directories
>
> Also, those could be restricted by whether or not to count directories and
> whether or not to count hidden files.
>
> Then, it would have settings according to that such as:
> - Directory Icon
> - Viewer
>   - Viewer Options
> - Sorting Method
> - Previews
>   - Preview Settings
> - Special Actions to Perform on Opening (split view, add files to some
> database, etcetera)

If I am correct, the logic to do such distinctions is already there in 
Konquror. If you switch to icon view, Konqueror already uses different icons 
depending on the content of a folder. (I haven't looked at code, I am just 
guessing because of behaviour here.) So, maybe it isn't so difficult to add a 
feature which sets the view mode accordingly.

> Although this sounds like it might be overkill, allow me to show a list of
> what I think this would be useful for. This is a sample of what my
> Directory Types list might look like. Feel free to skim over it to get to
> more text, as it is a little long and maybe more than is needed to explain
> my point.

[cut some examples]

> Obviously, that was a lot of examples and a lot of space. I know that this
> is a complex tool, but it is powerful. The main use of this would be for
> Distros to configure things before end-users see it. However, I am a big
> fan of allowing users to change any setting the Distributor can, so I would
> want it accessible from an end-user app.

Of course, there should be an option to change these settings. However, the 
logic behind should be very sound and unsurprising. If that is the case, the 
need for cofigurability lessens a lot.

> This adds custom icons to directories to help show what they are, and makes
> those easily configurable. It allows the file viewer to change logically
> according to what the user is viewing. Adding in good backgrounds for
> directories on a case-by-case basis wouldn't be too far off. It allows for
> some very custom directories, as with the home directory. It helps obviate
> the need for the viewer-buttons on the toolbar.
>
> Also, I should not that the viewer settings should be overridden (possibly
> add a special option to negate this for some views) if the view type has
> been explicitly changed by the user, and the view should never change if
> the type of directory has not changed.

This is easily accomplished by the now famous .desktop files. Whenever one is 
present, there will be no autodection whatsoever.

> Okay, big proposal. Thanks for listening, please get out the shredder now.
>
> PS: If you wondered about what I meant by all those 'if I had my way'
> things, go to: [
> http://www.csis.gvsu.edu/~abreschm/designs/ideas/split-kparts.php ] for a
> very out-of-date bit of suggestions regarding that. The design has advanced
> a lot in my notebook and mind.

As I said, most of what I wrote are assumptions on technical side. If I am 
mistaken, please correct me. 

Greetings,
Christoph

-- 
 | Christoph Niemann <cnieman@suse.de>
 | SuSE Usability Guild
 |
 | Contrary to popular opinion, the plural of 'anecdote' is not 'fact'.
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]