Bug 108510 - "Documents" in 'kdeglobals does not work with non-KDE apps
Summary: "Documents" in 'kdeglobals does not work with non-KDE apps
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: klauncher (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-03 23:02 UTC by James Richard Tyrer
Modified: 2012-10-05 10:05 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Untested patch for kde4, please test (655 bytes, patch)
2008-05-09 19:27 UTC, David Faure
Details
Slightly modified patch (758 bytes, patch)
2008-05-23 20:54 UTC, James Richard Tyrer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Richard Tyrer 2005-07-03 23:02:13 UTC
Version:            (using KDE KDE 3.4.1)
Installed from:    Compiled From Sources
Compiler:          GCC-3.4.4 
OS:                Linux

The "Documents=" paramater in the 'kdeglobals' file is set in the Control Center:

        System Administration -> Paths: Documents path

KDE applications use this as their default working directory if started by KLauncher.  However, non-KDE applications do not.

If started by KLauncher (i.e. from the K-Menu or an icon somewhere) the default working directory for all apps -- both KDE and non-KDE -- should be set to the directory specified in the "Documents=" paramater in the 'kdeglobals' file.

Note that this default working directory must be overridden if the 'desktop' file contains: "path=<work_path>".
Comment 1 Waldo Bastian 2005-07-04 11:03:45 UTC
KLauncher starts both KDE and non-KDE applications with $HOME as their default working directory, unless specified otherwise with Path=.
Comment 2 James Richard Tyrer 2005-07-04 21:59:13 UTC
Not if you have:

System Administration -> Paths: Documents path

set to something other than $HOME.
Comment 3 James Richard Tyrer 2005-07-21 20:55:27 UTC
Further research: Summary changed

The "Documents" directory always works with KDE apps even if started in a DE or WM other than KDE.  However, when opening a non-KDE application in KDE, the default directory to open/save files is not the "Documents" directory.

This *is* a bug and needs to be fixed.

The "Documents" directory should be the default "Work path" for all applications when opened in KDE (with KLauncher).
Comment 4 David Faure 2008-05-09 19:27:37 UTC
Created attachment 24684 [details]
Untested patch for kde4, please test
Comment 5 James Richard Tyrer 2008-05-23 20:54:56 UTC
Created attachment 24918 [details]
Slightly modified patch

I have tested this patch with KDE4 TRUNK and several non-kde applications.  I
find that not all applications correctly respond to the current directory when
started from a Konsole.  So, it made no change with those.  It did work
correctly with gEdit and The GIMP.  The only application that I had an issue
with was Xfig which does save to the current directory when opened from a
Konsole but did not save to the Documents directory when opened from the menu.

So, I have concluded that it works and the attached diff should be committed
and this bug closed.
Comment 6 David Faure 2008-06-09 19:49:42 UTC
SVN commit 818803 by dfaure:

chdir to the user's "Documents" path before launching an application; this makes non-kde apps honour the kde document directory, (e.g. gEdit, gimp, openoffice...)
BUG: 108510


 M  +6 -0      kinit.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=818803
Comment 7 Lawrence 2010-03-22 18:06:56 UTC
If the intent of this patch was to make all applications started with klauncher or krunner have a default initial working directory of ~/Documents, not $HOME, and it appears it is, then it's in conflict with the expectations of those wanting to migrate effortlessly from KDE3, and of the reporters of the following subsequently-reported KDE bugs: 183534, 201072, 203495, 230310.

Default working or Save directories of applications are surely best-decided by the application, using xdg-user-dir-lookup() code, and not badly-decided by the desktop manager.
Comment 8 Michael Schuster 2010-08-17 16:06:18 UTC
The design underlying this "fix" seems utterly broken, please revert it.

What happening now (and I don't know whether that was planned) is that *every* application (eg xterm ...) launched by KDE starts with ~/Documents as its working directory; this is - as Lawrence says - counter to everything we've learned to expect from Unix systems in the last 30 years. 
The workaround to create launchers that have $HOME as their starting directory doesn't work (for me anyway) for those that KDE restarts automatically at start-up time.
Comment 9 Yichao Zhou 2012-09-25 14:45:42 UTC
Please revert it.  This is a very serious bug.
Bug 302903 
Bug 183534
is cause by this "FIX"
Comment 10 David Faure 2012-10-05 09:55:23 UTC
Yes this was the intent. But indeed, while it makes sense for most GUI apps, it doesn't make sense for terminals. If we can't do this right for all cases, let's not do it at all. I'll revert.
Comment 11 David Faure 2012-10-05 10:05:54 UTC
Git commit f659ebf30dde67798926e9ab0a7671a96602174b by David Faure.
Committed on 05/10/2012 at 12:00.
Pushed by dfaure into branch 'KDE/4.9'.

By popular demand, revert the call to chdir(documentPath).

This was an attempt to make the KDE document path work in non-KDE
gui apps (such as openoffice) (#108510). But it makes terminals
start in ~/Documents, which users don't expect.
Related: bug 183534, bug 302903

M  +1    -9    kinit/kinit.cpp
M  +1    -6    kio/kio/krun.cpp

http://commits.kde.org/kdelibs/f659ebf30dde67798926e9ab0a7671a96602174b