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

List:       kde-devel
Subject:    Re: Problem with kfm unifying dirs
From:       Waldo Bastian <bastian () ens ! ascom ! ch>
Date:       1999-04-19 8:57:44
[Download RAW message or body]

Sven Radej wrote:
> This is for all kde-system files whichare duplicated in local/
> global manner. When I say items I mean icons/kdelnks or whatever. 
> When I say "user's dir" I mean ~/.kde/share/applnk (or
> ~/.kde/.../icons). When I say "global dirs" I refer to
> $KDEDIR/share/applnk.
> 
> This is idea I had and still have in mind:
> 
> User doesn't have to know that there are global items and local 
> items. We the KDE, give some defaults int global dirs; root can
> administer them. If user wants to change something (icon, applnk,
> mimelnk...) this change goes into his
> local directory. This works now with mime/applnks in kfm: try Edit
> applnks and change any of them as user - the changed item is copied
> int your local dir (unless you're root)

I don't think having a automatic local/global thing in place is
confusing. I think it is confusing to show a mixed global/local
directory _WHEN BROWSING THE FILESYSTEM_.

I like the behaviour of the mime/applnks, I just don't think it the
filesystem should be overloaded like this. Make it explicit that it 
is a "magic" directory. 
Tell the user that these files are not really in the directory. 

A way to do this, could be to reserve a special URL ("applications:" 
or perhaps "kde:/application") and show the "merged" directory when
accessing this URL, while showing the normal directory when accessed
via the regular file:/... url.

Very draft proposal:
Create the following URLs to show/edit/change the icon/applnk/mimilnk
dirs:
"kde:/applnk", "kde:/mimelnk", "kde:/icon"

Cheers,
Waldo
-- 
KDE, Making The Future of Computing Available Today       
http://www.kde.org

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