Kde-3.2.2 and kicker

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri July 9 2004 12:49, Antti T. Niemi wrote:
> Hello, I'm wondering how kicker generates it's user specific kickerrc
> files. We are launching KDE desktop in our systems at the HUT and there is
> a need to do some system wide configurations. I've made most of those
> tasks, but configuring kicker the way I'd like has found to be a little
> problematic.
>
>  I thought there was one system-wide kickerrc file, which gets copied to
> users homedirectories once they log in, but I guess it is not handled that
> way. 

kicker reads both the system-wide kickerrc and the user specific kickerrc, 
changes made by the user are written to the user specific kickerrc. If the 
user doesn't change anything it will remain mostly empty.

> By editing files in /usr/share/kicker/ I have made neccessary changes 
> that I wanted, but getting quickbrowser and bookmarks away from kmenu
> apparently is not as straightforward as I thought. Anyone has an idea on
> how to do this?

Add the following to the system-wide kickerrc:

[menus]
UseBookmarks=false
UseBrowser=false

>  Secondly there seems to be a bug or so, because by fully customizing the
> default menus in /etc/xdg/menus has broken the possibility to start
> kmenuedit by right clicking the kmenu in panel and selecting menu editor.
> Starting kmenuedit from the konsole works like charm as it's supposed to.
> Anyone knows how to fix this?
>
>  Hmm... There is still one more thing that seems confusing. Konquerors
> filemanagement profile breaks if the <KDELegacyDirs/> is not present in
> applications.menu. Trying to start kfmclient openProfile filemanagement
> produces error, which complains that the file konqueror.desktop can't be
> located. This seems to be a bug also, because shouldn't the
> konqueror.desktop file be located in /usr/share/applications/kde? Copying
> the file to /usr/share/applications/kde doesn't correct the problem, so
> the crucial file konqueror.desktop is only looked from /usr/share/applnk
> directory. The fast fix was to empty the /usr/share/applnk directorytree
> excluding konqueror.desktop, this way our menus didn't get messed.

The idea is that if something doesn't appear in the menu, it doesn't exist.

So if you can't start the menu editor then that's most likely because the menu 
editor doesn't appear in the menu.

For things that should exist but should not appear in the menu, the menu has a 
hidden section in the form of share/applnk/.hidden

When you remove <KDELegacyDirs/> it will no longer include this hidden 
section, which is a problem because it contains stuff that should exist.

I hope this explains things a bit, I agree that there is room for improvement 
here.

Cheers,
Waldo
- -- 
bastian at kde.org  |   KDE Community World Summit 2004  |  bastian at suse.com
bastian at kde.org  | 21-29 August, Ludwigsburg, Germany |  bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFA7s2ON4pvrENfboIRAldKAKCpiH7dUfki9YPJSC7kxERSbQ6LtQCfTFnr
K0JLVWJoYUWmubOBX1wvLvM=
=jjQh
-----END PGP SIGNATURE-----
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.