KerstinMontasoya@xxxxxxxxxxx wrote:
>What about XDG_DATA_HOME and XDG_CONFIG_HOME?
>I think they should point to $HOME/sometheing (where you can write to).
>what does it print when you run this?
> set | grep KDE # That will list all KDE environment variables.
>
>http://wiki.kde.org/tiki-index.php?page=Environment+Variables
> XDG_DATA_HOME (KDE 3.2)
> Defines the base directory relative to which user specific data
> files should be stored. If $XDG_DATA_HOME is either not set or
> empty, a default equal to $HOME/.local/share is used. (see
> specificationexternal link)
> XDG_CONFIG_HOME (KDE 3.2)
> Defines the base directory relative to which user specific
> configuration files should be stored. If $XDG_CONFIG_HOME is
> either not set or empty, a default equal to $HOME/.config is
> used. (see specificationexternal link)
>
>If you're a little more hard core...
>I was trying to figure out what it does, so I ran kmenuedit,
>attached to it with strace, and looked for 'access' and 'open' calls.
> kmenuedit # this exits, so you can't strace it directly
> ps -e | grep kmenuedit
> 20860 pts/4 00:00:00 kmenuedit
> strace -p 20860 2>&1 | grep -e open -e access
>and then I added a dummy menu item (xterm), and did File:Save ... and at that point I see it doing
>
>access("/root/.local/share/applications/xterm.desktop", W_OK) = 0
>open("/root/.local/share/applications/xterm.desktop.lockjvqPUb.tmp", O_RDWR|O_CREAT|O_EXCL, 0600) = 9
>access("/root/.local/share/applications/xterm.desktop", W_OK) = 0
>open("/root/.local/share/applications/xterm.desktopIUU7tc.new", O_RDWR|O_CREAT|O_EXCL, 0600) = 9
>(Ok, I did it as root, not a regular user, but it should be the same)
>
>I would guess you will see it trying to check 'access' to or 'open' a directory or file that you don't have write access to.
>Probably because the XDG_DATA_HOME or XDG_CONFIG_HOME is set there?
>And it's a bug if it tried to save, but failed and didn't report it!
>
>Or then again it could just be kiosk mode?
>http://webcvs.kde.org/kdelibs/kdecore/README.kiosk?rev=1.57&view=markup
> The kiosk-framework provides an easy way to disable certain features within
> KDE to create a more controlled environment.
>(I didn't understand all that)
>
>
>
>
>>>s s wrote:
>>>
>>>
>>>>I have the exact same problem: I can't change the
>>>>kMenu, no matter how hard I try. I'm hoping that
>>>>
>>>>
>>>the
>>>
>>>
>>>>next version of KDE fixes that. hmm... when it
>>>>
>>>>
>>>comes
>>>
>>>
>>>>out, I may try deleting then reinstalling KDE, and
>>>>recreating ~/.kde ...I'd like to avoid that if
>>>>possible.
>>>>
>>>>
>>>Recreating ~/.kde will not help you. Kmenuedit
>>>stores local menu changes
>>>in ~/.local
>>>Try exporting XDG_CONFIG_DIRS=/path/to/KDE/etc/xdg -
>>>on my system that's
>>>/opt/kde/etc/xdg.
>>>
>>>You can do that by placing a .sh file in ~/.kde/env
>>>
>>>
>>I typed `echo $XDG_CONFIG_DIRS` and I got:
>>
>>$ echo $XDG_CONFIG_DIRS
>>/opt/kde/etc/xdg
>>
>>so... it looks like the variable is already set
>>correctly... now what?
>>
>>
>>
>>
>>
>>
>>__________________________________________________________
>>Find your next car at http://autos.yahoo.ca
>>___________________________________________________
>>.
>>Account management: https://mail.kde.org/mailman/listinfo/kde.
>>Archives: http://lists.kde.org/.
>>More info: http://www.kde.org/faq.html.
>>
>>
>___________________________________________________
>.
>Account management: https://mail.kde.org/mailman/listinfo/kde.
>Archives: http://lists.kde.org/.
>More info: http://www.kde.org/faq.html.
>
>
Found my problem. Permissions for ~/.local and ~/.local/share were
correct. Permissions on the directories below that were set to root.
When I changed them back to my ID, things started working.
Thanks,
Rick Knight
___________________________________________________
.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
