Pietro Iglio wrote:
> 
> >Date: Mon, 05 Jul 1999 14:27:31 +0200
> >From: Stephan Kulow <coolo@kde.org>
> >To: KDE Developer <kde-devel@kde.org>
> >Subject: Re: localkdedir, kde_appsdir() obsolete...
> >
> >Pietro Iglio wrote:
> >>
> >> At 17.28 02/07/99 +0200, you wrote:
> >> >Pietro Iglio wrote:
> >> >>
> >> >> At 16.24 02/07/99 +0200, you wrote:
> >> >> >Pietro Iglio wrote:
> >> >> KPanel needs to parse the global and the local applnk directories
> >> >> to build the global and the personal menus.
> >> >> Thus it needs a way to get the /opt/kde/share/applnk path and
> >> >> another way to get the ~/.kde/share/applnk.
> >> >
> >> >Hm. Well.. You can get findAllResources() (Something like that)
> >> >to get all applinks (local + global). Then you might still need
> >> >a way to find out if an entry is local or global.
> >> >
> >> >Please be aware that in KDE2.0 a user can have multiple levels
> >> >of globalness e.g global / group / local.
> >>
> >> Isn't much easier to add a method to get the global/group/local
> >> directory for a given type? Eg:
> >>
> >> KStandardDirs::getResourceDirs("apps", KStandardDirs::global)
> >>     (-> $KDEDIR/share/applnk)
> >> KStandardDirs::getResourceDirs("apps", KStandardDirs::group)
> >>     (-> ????/share/applnk)
> >> KStandardDirs::getResourceDirs("apps", KStandardDirs::user)
> >>     (-> .kde/share/applnk)
> >>
> >> Probably you can do the same with the current interface, but the way
> >> I suggest is probably much more readable. Alternatively, please could
> >> you translate the above statements using the current interface?
> >>
> >Actually the new interface removes these assumptions that there are
> >actual dirs for everything completly. Why do you want to differ
> >between local and global at all? I can't see a reason for it.
> >What I would expect as user is that when I place a file in $HOME/.kde
> >it overwrites the file from $KDEDIR.
> >
> >So just rewrite kpanel to not have a personal menu, but have one menu
> >with every applnk in it. For this you can use findAllResources. If you
> >need to save changes the user does (the user should be able to edit
> >every entry in the menu), it saves to locateLocal and next time
> >findAllResources
> >runs, you'll find two entries and when you ignore the later, you'll have
> >what
> >the user expected to happen when he changed the entry (it changed).
> >
> >Greetings, Stephan
> 
> I had already discussed with Matthias what you suggest. I don't dislike the
> idea of having a single menu (no global/personal).
> The personal menu would shadow the global menu. We discarded the idea because
> the implementation can be hard and it can be hard to understand for the
> average user.
> The semantics of overlapping menus is not clear to me
> (what happens when a menu entry is moved from a submenu to another?
> what if the application is uninstalled? and so on), and AFAIK there is
> no GUI environment that implements that.
> If someone can come out with a reasonable specification for that, we can
> consider your solution. I'm not satisfied with the current personal/global
> menu, nor with the latest MS solution (each submenu has mixed entries for
> global/local applications).
> Anyway, in my opinion more that two levels of overlapping menus (eg.
> personal / group / global) can be too confusing for users.
> 
> I would like Matthias involved in this discussion.
> 
Well, then the best is to still findAllResources("apps") and filter out
the entries that start with getSaveLocateion("apps") and put those in
the
Personal menu

Greetings, Stephan

-- 
As long as Linux remains a religion of freeware fanatics,
Microsoft have nothing to worry about.  
                       By Michael Surkan, PC Week Online