Something strange here is that it's happening only with gedit.
If you're opening with leafpad or another text editor (using %U) in the command line it does not happen, for example Kate is also using %U for passing the url in the desktop file & only one tab is open.
Even switching to a %f as argument ( or removing it at all ) to provide only one argument to gedit it is still opening 2 tabs...
So i really don't understand why this behaviour is different than others text editor even others gtk's one.

ping because this bug had no activity since nearly 4 months ago, but still has the status NEW

@ John
Please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead.

CC: (none) => marja11

@Marja
Could you add ovitters in cc, he's the maintainer of gedit & he might have an idea.
So far as said i stricly don't understand why it's working for all editor except gedit.

CC: (none) => balcaen.john

(In reply to comment #3)
> @Marja
> Could you add ovitters in cc, he's the maintainer of gedit & he might have an
> idea.
> So far as said i stricly don't understand why it's working for all editor
> except gedit.

@ Olav

can you look into this, please?

CC: (none) => olav

As an addendum, this also happens when gedit is added to the KDE panel and invoked from there by clicking the icon.  I just checked the icon properties, and it shows the associated command as "gedit-2", but when I try to execute gedit-2 from the command line, it can't find it.

So is gedit-2 some KDE-supplied intermediary which KDE finds by itself ?  If so, perhaps the error lies in how gedit-2 invokes gedit.

(In reply to comment #5)
> As an addendum, this also happens when gedit is added to the KDE panel and
> invoked from there by clicking the icon.  I just checked the icon properties,
> and it shows the associated command as "gedit-2", but when I try to execute
> gedit-2 from the command line, it can't find it.
How did you add it on the panel ?
Because when i'm adding it on the panel here i can reproduce the « gedit-2 ».

Navigate the application menu to the gedit entry, right-click, and select "add to panel".

Is that a typo, or did you mean that you actually *can* reproduce it ?

I mean that i navigate the application menu to the gedit entry & then right click & i select add to the panel.
The icon added on the panel is named gedit & not gedit-2.
So here i can't reproduce the « gedit-2 » bug :)

It's weird.  I removed the icon and re-added it, and it still says "gedit-2".  And when you click on the icon, it launches gedit successfully.

you don't have eventually a previous icon ?

(In reply to comment #10)
> you don't have eventually a previous icon ?

?  Sorry, I don't understand.

I was wondering if you don't have already on your panel a previous gedit icon/launcher which could eventually explain that the « next » installed icon/launcher get renamed to -2. (Of course i'm not able to demonstrate it locally since when i'm adding several gedit icon/launcher on my panel, they still have the « gedit » name)

Ah, my error.  I was looking at the General tab, and mistook the icon name for the execution string.

I've tested a bit more with this, replacing the gedit executable with one of my own to print the arguments, but while it runs fine from the command line, it segfaults when launched by KDE.  However, I was able to verify via strace that gedit is indeed being execve'd with no arguments other than the "gedit" name as argv[0].  So the value of %U in the KDE invocation is correct.

If I launch gedit from the command line, it comes up with "Unsaved File 1" opened as a tab but not marked as changed, and it stays that way.  If I launch it via KDE, the same thing happens, but then the asterisk appears on the tab indicating that the file has been modified.

So, it appears that KDE is sending gedit a window event after launching it, and that this is what causes gedit to mark the file as changed.

To test this, I checked "run in terminal" in the icon settings, and the error did not occur.

Is there a way to trace window events for a KDE application ?

Still happening in current cauldron.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

Still happening in current cauldron.

This seems to be a bug in gedit itself, which still exist in the 3.6 release.

I can reproduce this behaviour with the latest gedit release in KDE. But the gedit fork pluma from the MATE-Project just works as expected.

CC: (none) => harmathy

Why do you think it's a gedit bug ?  If I launch gedit from a command line in KDE, it behaves as expected.

It's only when KDE itself launches it that you have the extra file.

And I don't think it has anything to do with my panel button, since I can cause the error by right-clicking on a .txt file in Dolphin and selecting Open With -> gedit.

As I said: pluma works perfectly fine, even if started from dolphin. And pluma is a gedit fork. Therefore either this problem was introduced in gedit after the fork or it was then resolved in pluma.

I'm afraid that's not a lock.  I suspect that the difference between command-line invocation and KDE invocation is that KDE uses gedit.desktop, which uses "Exec=gedit %U".  I suspect that the problem is that whatever KDE is supplying as %U is something incorrect that gedit doesn't handle.  It's possible that gedit *should* handle it, and that it just doesn't, but it's also possible that it's not something that gedit ought to have to handle.

As for pluma, it's possible that their developers found the problem and put in a workaround, but that doesn't mean that it wasn't a KDE problem to begin with.

Still happening in current cauldron.

I got here via google as I have been seeing this annoyance of extra tab for opening a file and unjustified "changed" flag for the untouched Unsaved Document 1, requiring further action when closing gedit.

Here I'm using Rosa 2012.1 and gedit-3.6.2-1-rosa2012.1.x86_64 from gedit-3.6.2-1.src.rpm

Checking "Run in terminal" for the icon settings results in a "clean" start of gedit, no changed flag, here, also.

The output in that terminal is as follows:

(gedit:15472): Gtk-WARNING **: Theme parsing error: menu.css:88:11: '' is not a valid color name

(gedit:15472): Gtk-WARNING **: Theme parsing error: menu.css:93:11: '' is not a valid color name
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.

** (gedit:15472): WARNING **: Could not load Peas repository: Typelib file for namespace 'Peas', version '1.0' not found

** (gedit:15472): WARNING **: Could not load PeasGtk repository: Typelib file for namespace 'PeasGtk', version '1.0' not found

** (gedit:15472): WARNING **: Could not load theme icon user-bookmarks-symbolic: Icon 'user-bookmarks-symbolic' not present in theme

** (gedit:15472): WARNING **: Could not load theme icon user-home-symbolic: Icon 'user-home-symbolic' not present in theme

** (gedit:15472): WARNING **: Could not load theme icon drive-harddisk-symbolic: Icon 'drive-harddisk-symbolic' not present in theme

CC: (none) => rolfpedersen

This finally appears to be fixed in current cauldron.

Status: NEW => RESOLVED
Resolution: (none) => FIXED