Bug 276103 - Dolphin opens gedit-associated files with 2 gedit tabs
Summary: Dolphin opens gedit-associated files with 2 gedit tabs
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.7
Platform: Archlinux Linux
: NOR normal with 2 votes (vote)
Target Milestone: ---
Assignee: kdelibs bugs
: 307624 325389 (view as bug list)
Depends on:
Reported: 2011-06-20 05:30 UTC by Alex
Modified: 2014-04-21 17:38 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2011-06-20 05:30:05 UTC
Version:           1.6.1 (using KDE 4.6.3) 
OS:                Linux

I have text files associated with gedit in dolphin and the version of gedit is 3.0.5. When I click on text file, gedit is opened with 2 tabs - one of them is the actual text file and the other one is just new blank gedit document marked with "*" which means it was changed and will be provided with save-confirmation dialog on exit whereas for example when I open text files with xfe file manager, gedit is opened with only 1 tab which is the actual document I open. So every time I open text file in dolphin to read it, I should click "do not save" on exit (for the second tab).

Reproducible: Always

Steps to Reproduce:
Associate text files with gedit 3.0.5 in dolphin and open some txt file dolphin by single or double click.

Actual Results:  
Gedit will be open with two tabs instead of one.

Expected Results:  
Gedit should be open with one tab which should be the actual file.
Comment 1 Jekyll Wu 2011-10-26 23:47:37 UTC
I can reproduce this with dolphin-1.7 and gedit-3.2.1. This problem is actually quite easy to reproduce.
Comment 2 Jekyll Wu 2011-12-19 19:30:21 UTC
"kioclient exec sample.txt" gets the same result, so the real problem is not in dolphin.
Comment 3 Jekyll Wu 2012-04-11 14:49:32 UTC
There is some discussion here: https://bbs.archlinux.org/viewtopic.php?id=120283

Looks like related with gedit's feature of acepting data from pipe.
Comment 4 Jekyll Wu 2012-04-20 08:47:43 UTC
FYI, I can't reproduce this problem any more using kdelibs built from master branch
Comment 5 Frank Reininghaus 2012-09-30 18:05:00 UTC
*** Bug 307624 has been marked as a duplicate of this bug. ***
Comment 6 Glen Mazza 2012-09-30 19:22:32 UTC
This solution solved it for me on Dolphin:
Comment 7 Glen Mazza 2012-10-01 12:35:13 UTC
Actually, the above fixed it with me in Dolphin and gedit, also gedit will open fine if activated from a terminal window, but the above change will then open three tabs up for me named $, <, and null if I try to open the file from Nautilus.  I was using Dolphin in GNOME to avoid some shortcomings in Nautilus but I guess it's difficult to find a solution for all three in GNOME.

One possibility for me (I'll have to look into it), is keep the gedit configuration as-is so it will work w/command-line & Nautilus but have dolphin open another application that does the $1 < dev/null change, as discussed here:  http://newton.freehostia.com/comp/ubstuff.html
Comment 8 Glen Mazza 2012-10-01 12:52:42 UTC
OK, I got it to work, I use gedit as normal for Nautilus and when activating from the command-line.  For Dolphin, I created a wrapper (I called it "kdegedit" but it can be called anything that doesn't conflict with another app name) of gedit in /usr/loca/bin and configured dolphin to use that wrapper instead of gedit as described here: http://forums.linuxmint.com/viewtopic.php?f=190&t=96040&p=560682#p550417 , except instead of configuring Dolphin to use gedit $1 < dev/null I configured it as kdegedit %u.  Then in Dolphin make sure gedit is removed as the default viewing app for any type of file, replaced with kdegedit instead.

gmazza@gmazza-work:/usr/local/bin$ ls -la
total 12
drwxr-xr-x  2 root root 4096 Oct  1 08:27 .
drwxr-xr-x 10 root root 4096 Apr 25 12:04 ..
-rwxrwxrwx  1 root root   36 Oct  1 08:27 kdegedit

(make sure you have the permissions like above so non-root can use it)

gmazza@gmazza-work:/usr/local/bin$ more kdegedit
gedit "$1" < /dev/null
Comment 9 e80f00 2012-10-27 21:11:32 UTC
Workaround working for me with Dolphin, Nautilus, and Konqueror in KDE:

1. Open file .local/share/applications/gedit.desktop or /usr/share/applications/gedit.desktop
2. Search  the line beginning with "Exec=", and replace it with:
  Exec=bash -c 'gedit "$@" < /dev/null' - %U

I think Nautilus interprets the command "gedit $1 < dev/null" as stated in http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables . It doesn't executes the command in a shell environment (like dolphin does), but runs it by "itself".
The new command creates the needed shell environment for Nautilus, so that it can be used for all three file managers.
Comment 10 Jekyll Wu 2013-09-29 02:19:02 UTC
*** Bug 325389 has been marked as a duplicate of this bug. ***
Comment 11 Wolfgang Bauer 2014-03-10 07:24:15 UTC
I just stumbled over this bug report and decided to add a comment because I have seen the same problem in the past. (I never bothered much about it because I don't use gedit anyway. I prefer KWrite/Kate by far... ;-) )

I cannot reproduce this problem any more here on openSUSE 13.1 with KDE 4.12.3 and gedit 3.10.3, if I right-click on a text file and select Open with->gedit, only the text file is opened, there is no second empty tab in gedit. And the same is also true when I left-click on a file associated with gedit.

I tried on a fresh openSUSE 12.3 installation (KDE 4.10.0 and gedit 3.6.2) and there the problem occurs as described in this bug report: gedit also opens a second empty tab (named "Unsaved Document 1"), and asks if the changes in that second tab should be saved when I quit it.
But: After upgrading gedit to 3.8.3, the problem disappeared! (with the same KDE version)

Since I haven't ever seen a similar problem with any other application, I tend to believe this was actually a bug in gedit that apparently got fixed in its 3.8 incantation.

Based on my observations, I would say that this bug report can/should be closed.
Comment 12 Christoph Feck 2014-04-21 17:38:41 UTC
Thanks Wolfgang for the analysis. Let's close this then.