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

List:       kde-devel
Subject:    Re: localkdedir, kde_appsdir() obsolete... (fwd)
From:       iglio () fub ! it (Pietro Iglio)
Date:       1999-07-07 8:19:56
[Download RAW message or body]

>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.

-- Pietro

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