>Date: Mon, 05 Jul 1999 14:27:31 +0200 >From: Stephan Kulow >To: KDE Developer >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