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

List:       kde-usability
Subject:    Re: OT: problem changing KMenu (was: Re: KMenuEdit vs. direct
From:       tak2 () kent ! ac ! uk
Date:       2003-08-26 0:24:03
[Download RAW message or body]

> This happened to me some time ago (SuSE 8.2 KDE 3.1.3 by the way), and
> solved it by removing my user kde temporary files in /tmp  ("rm -Rf
> /tmp/kde-user"). I also removed my .ICE* and .DCOP* files but I don't think
> that had anything to do with it.
>
> Good luck!
>
> J.A.
>

I wanted to chip in the latest results of this. While on the topic of whether 
we should be using inline editing for the KMenu, I think a more important 
issue must be addressed first: that of inconsistency between the contents of 
the ~/.kde/share/applink folder's contents and what appears when you open 
KMenuEdit (notwithstanding any differences from the global 'applink').

Disclaimer: this may look like a rant if you get it wrong. It isn't. Consider 
it as points to keep in mind, since you're thinking of reimplementing this 
bit.

I spent about 2 hours trying to convince KDE that there were no 'System', 
'Utilities' and 'Settingsmenu' folders in the top level, but they were all in 
a 'System Settings' submenu.

Behaviour was varying (at some stage even kdeinit became a zombie and I had to 
ssh to the machine to issue a reboot) but in the end I never got around to do 
what I wanted.

Things that didn't work:
* moving/creating folders manually
* copying files from another user's directory and changing 
ownership/permissions
* adding a folder (say) ABCD and then when I went into KMenu, it didn't see 
it. When I tried to add the same folder there however (via 'New Submenu...'), 
it refused because "the folder already exists".
* after moving eg. the 'system' folder inside ABCD, the files were moved 
physically but the menu editor showed 2-3 entries of the form 
'System/Something' as their name. Going back to check the contents of the 
directories, it wasn't rare that they were erased.
* The Remove button doesn't actually physically remove a folder/entry. It 
hides it. This was probably conceived as a useful abstraction for the newbie, 
but then the power user cannot go in there and clean up the mess. This 
becomes apparent only after you enable the 'settings --> show hidden items' 
option. A remove should be a remove. A hide should be a hide.
* endless combinations of the above

End result: it got so mangled I resorted to ' rm -rf ~/.kde* ' , logout, and 
back in to reconfigure KDE from scratch.

I hate to say, but this is something even M$ got right. Simple things.
If you want to try this, I highly recommend making a backup of your ~/.kde/ 
first.

Again, sorry if this seems a rant. It is *not* intended to be one. I just 
share my experiences today, hoping they can provide any useful pointers.

regards,

Trian

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]