I very much second this! 

And in a potential SDI mode, I think there should be no
tabs visible at all IMHO.

2 reasons, really:
 
 a) I want it to spawn a new window each time, so e.g.
    I can easily compare READMEs side by side. I am
    aware that tabs can be torn off, but I would love
    to have a more "direct" solution.
 
 b) Reduces visual clutter, especially when used as
    above.
 
To me having a gconf key to turn on a behaviour like
this would be more than enough. 

Basically what I want is gedit acting like epiphany:
Having the potential of using tabs, but not showing
it, if the user does not like it. It makes even more
sense with gedit, as it starts practically immediately.

/ralph -- I miss my TeachText/SimpleText

Personally I do even think that sdi should be the default.

The HIG says: "MDI has several inherent usability problems, so its use
is not encouraged in new GNOME applications."

I can see some argument for why a text-editor might allow the use of
tabs, and it's basically the same as for terminals or web-browsers:
that it's not uncommon for some users of these applications to open
many different documents at once. For those people (so one might argue
at least) the availability of tabs greatly increases the usefulness of
the application.

However, as for the terminal, I fail to see how this is true for gedit
for the vast majority of users, i.e. those users that only
occasionally open a single text document for inspection or editing. As
gedit aims to be the default text-editor for GNOME I think such users
need to be a priority.

I strongly second this - gedit should behave like epiphany in regard to tabs.
Also if I open a file that is already opened in gedit, it should switch to that
tab instead of opening a new tab with a second copy of the document.

didn't gedit allow for SDI before GTK2?  

I always figured there must still be an option for this somewhere (or was it
ripped out completely?) even though it might be buried in a config file (or
gconf) somewhere.  

*** Bug 158806 has been marked as a duplicate of this bug. ***

I prefer the Kate (yes it's a KDE app) way of doing things. I like having the
list of filenames on the left of the window, so I can just click on a filename
to switch to that buffer. I find it much easier to work with when there are
multiple files.

*** Bug 305683 has been marked as a duplicate of this bug. ***

*** Bug 306416 has been marked as a duplicate of this bug. ***

I'm gonna vouch for this. SDI is the way forward.

I am removing this from the blocker list of bug #131953.


I am leaving this open since it has been for so long... though I don't think
this is gonna change anytime soon. gedit is a tabbed text editor, like many
others text editors that are widely used in other platforms (UltraEdit,
EditPlus, TextMate to name a few).

This is just my view of this, but "gedit is a tabbed text editor" has not been the fact all the way to 2.10 or something, this change was rather abrupt and surprising. As far as the actual usability, generally, if I am going to do some serious work, I will open an appropriate tool, but if I just want to look at the content of a text file I will click on it in nautilus and expect a gedit window to popup. Instead, if I already have a gedit window in another workspace visually nothing will happen after a click. I believe that this behaviour is confusing.

gedit has had tabs since version 0.X, 7 years ago or something like that.


> Instead, if I already have a gedit window in another workspace
> visually nothing will happen after a click. I believe that this behaviour is
> confusing.

This is a bug. Actually it *was* a bug. It was present just in one version of gedit and it has been fixed for a long time. If a gedit window is already present *in the current workspace*, then a tab is added there and the window is brought to the front, otherwise a new window is opened.

OK, so you prefer gedit to behave inconsistently (opening either a new tab or a new window without any guide to the user as to why either behavior is chosen) rather then give user an option to control this. BTW, will it raise gedit window to the front and raise the new tab to the front when "new tab" behavior is used?

> without any guide to the user as to why either behavior is chosen

how so? if there is a gedit window open, it is used otherwise a new one is created. Hardly unpredicatble.

The new tab is raised to the top

MDI is f***ing horrible.

I tell you what's unpredictable. Open three text files, "one", "two" and "three". Minimize the window. What do you see on your Window List? "three (~) - gedit".

This needs to be changed. I totally 100% disagree with this whole "tab" phenomenon, it's a sign that the Window Manager is failing to do its job properly. Windows XP's window grouping is terrible, and wnck's even worse.

Created attachment 63182 [details]
messed up widths now :(

Er, somehow that posted to the wrong bug. GG WP Bugzilla!

I've implemented SDI mixed with MDI (when appropriate) in a separate CVS branch (sdi_mdi). You can check it out if you like. No promises are made that this will get into HEAD, but still it's a start.

has this been definitely dropped?

I absolutely agree MDIs (TDIs) are horrible in usability.  Switching tabs is modal, as it requires different UI gestures than switching between windows.  This leads to mode errors and user mental effort.  When another application opens a new document in Gedit, the user wonders where the old Gedit window went.  The open documents are not visible in the task bar.  The tab bar wastes wcreen space, as the windows would be compactly displayed in the panel task bar.  You can't put documents side by side to compare them visually before you put them in separate windows.  All wastes user's time and efort, and all this is the job of the window manager which every window manager does well. Even the HIG recommends against MDI.

Why do you insist on keeping Gedit's MDI?  Why can't you at least provide a gconf key to disable it by default?  You are not thinking rationally about Gedit's usability and are disregarding the work in the HIG.

Created attachment 108261 [details] [review]
Patch for optional SDI

Somebody might find this useful. With this patch the user can choose to either
1) Open all docs in new tabs (MDI, like now)
2) Open all docs in new windows (SDI)
3) Open docs in new windows only if opened from outside gedit

Option 3 is inconsistent, but I find it's the behaviour that works best for me.

nice patch, works perfectly

Any chance of seeing this in a released version?

The patch I once did is hopelessly outdated. However, we are restructuring the internals with regard to document/view management for gedit 3.0 (which should be released in about a year), and it would be nice to see if we can incorporate SDI behavior if we are restructuring anyway.

We went through another design iteration in 3.12 and tabs are still there (though when using a single document they are hidden and with ctrl+N you can easily get a new window).

No point keeping this 10 years old bug open

Disappointing. AFAIK, KDE has tabbing as part of its window manager, which is clearly a better design.

Does keeping open a 10 year old bug with no activity in the last 5 make it any less disappointing? If you think it belongs to the WM convince gnome-shell people.

Closing valid feature requests just because they are old doesn't score any points. In fact, it's disrespectful to those who have made the effort to contribute to them in the past, in terms of comments, patches, or even just consideration. I'm sure you have been on the receiving end of this phenomenon, Paolo!

I'm certain that, had this bug not already existed since 5 years ago, many more people would have reported it since. Don't mistake a lack of 'me too' comments for a lack of support for this "feature"!