Bug 372208

Summary:	kwrite File -> New directory fails to follow current, defaults to $HOME
Product:	[Applications] kate	Reporter:	David Rankin <drankinatty>
Component:	kwrite	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	nate, toralf.foerster
Priority:	NOR
Version:	16.08
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description David Rankin 2016-11-08 10:20:21 UTC

In kwrite (not kate - new follows current there) choosing File -> New does not preserve (or follow) the current document directory causing you to have to navigate back though the filesystem to save a new document in the current document location. Instead, kwrite defaults to $HOME for all new document saves. This is incorrect behavior.

The correct behavior on File -> New is to preserve the current document directory information so saving, by default, will be to the current document directory. Instead, the default save is to $HOME.

To reproduce, start kwrite, navigate to /tmp, save the current document as 'foo.txt'. Press File -> New. Attempt to save the new document. The default save is to $HOME, not /tmp as it should be.

Inconsistently (and thankfully) this behavior is not observed in kate. Using kate (in the example above) will allow saving bar.txt in /tmp as it should.

Comment 1 David Rankin 2016-11-26 07:11:26 UTC

This occurs with both kate and kwrite. When you open a new session in kate (or a file in kwrite) and save a source file at $HOME/prg/src-c/tmp/debug. If you then create a new document (ctrl+n) and attempt to save the second file. Instead of offering to save the document in the directory where the first file was just saved, kate/kwrite defaults to asking to save in $HOME, instead of in $HOME/prg/src-c/tmp/debug. This requires that you again navigate to the directory of interest. That is unexpected behavior.

Similarly, if you use dolphin or konqueror to navigate and open a file in kwrite (or kate, depending on you file association order set in file properties), then 'save-as' in a new directory, kwrite or kate will always default to saving all new documents created with (ctrl+n) to the directory where the first file was opened, completely ignoring the directory where the most recent file was saved. This seems to be the same failure to update the directory information based on the last save.

For more than a decade I've used kate/kwrite and I have never had a problem with them not remembering and following the last saved directory. This should be common to the file save dialog in KDE, not just kate/kwrite, but it is very much a problem when dealing with multiple source files in a highly nested directory structure. This is occurring with:

Kate/Kwrite Versions 16.08.3
Kate Part version 5.28

KDE Frameworks 5.28.0
Qt 5.7.0 (built against 5.7.0)
The xcb windowing system

Let me know if you need any additional information, I'm happy to provide anything needed to help get this fixed. This, along with the other handful of bugs I've filed recently, are the top annoyances I find in trying to use Plasma/FW5, moving from KDE3. These very simple things, that have always just worked correctly in KDE, are what made KDE so wonderfully efficient and a joy to use. It is very notable when these things don't work. I'm committed to helping make Plasma/FW5 as efficient and enjoyable to use as KDE3, but the simple things that make KDE KDE, really need to work. There is no reason anyone should ever have to repeatedly click down a 10 component directory path just to save a file in the same location.

Comment 2 Toralf Förster 2017-01-08 13:02:06 UTC

The issue appeared here for me too after upgrading from kde-plasma 5.8.4 to 5.8.5 at a stable hardened Gentoo Linux (qt 5.7.1, kf, 5.29, ka 16.12.0) and is still present.

Comment 3 René 2017-11-30 11:40:23 UTC

likely a duplicate of bug 374913

Comment 4 Nate Graham 2017-12-06 21:04:02 UTC


*** This bug has been marked as a duplicate of bug 374913 ***