Bug 458621

I thought we had a way to disable tabs but I can't find it either.

There is a "show tabs" item in the Settings menu you can uncheck, but that just hides the tab bar, rather than actually no longer making the window tab-based.

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

While we wait for a fix, is there a simple hack I can patch kwrite with to fix this?

Also noticed a side effect: Ctrl-W now closes the window rather than leaving it with an empty/new document.

> Also noticed a side effect: Ctrl-W now closes the window rather than leaving it with an empty/new document.

That can be fixed if you set in configure -> session the 'close the application....' to false.

But no, atm there is no way to turn tabs off.

I associate file types to Kate or Kwrite according to whether I tend to want those in a tabbed or single-window interface. This change completely broke my workflow as Kwrite will now use a single, multi-tabbed instance. :'(

KWrite remains a multi-instance app that can open each file in its own window.

(In reply to Nate Graham from comment #6)
> KWrite remains a multi-instance app that can open each file in its own
> window.

My bad. When opening via default association (e.g., clicking on Dolphin), it does create a new Kwrite instance for every file associated with it, while files associated with Kate open in a new tab in the running Kate instance, which is exactly the desired behaviour.

It's when using File → New / File → Open, etc., that it goes to new tab, exactly as the reporter describes.

(In reply to kdekdokdy from comment #7)
> (In reply to Nate Graham from comment #6)
> > KWrite remains a multi-instance app that can open each file in its own
> > window.
…
> It's when using File → New / File → Open, etc., that it goes to new tab,
> exactly as the reporter describes.

Ok, I see what I was doing: I have a habit of, once I have a Kwrite instance open, drag files into it to open another instance. Now those go into a new tab in the same instance, which is not very useful as it just duplicates Kate's behaviour.

FWIW, it looks like the last real KWrite (22.04.3) still builds fine with newer KDE at the moment.

I also was hit by this, now that 22.08.3 was marked as stable on Gentoo.

The current behavior is that opening some file using KWrite externally (e.g. via Dolphin) still triggers multiple KWrite instances to be created, like before. But the problem is (and it also broke my workflow …) that there seems to be no way of getting this behavior back when opening files from within KWrite. When doing so, new files are always added as tabs, and one can't turn off tabbing.

I would have expected that at least the "Limit number of tabs" option would make this feasible, when setting the limit to 1. But what happens then is a bit odd: When opening more than one file, the last one is added as a tab, and one can't see the other ones. when closing that tab, the next one appears and so on. I think this is at least unexpected behavior, but that may be worth another bug; anyway, I would expect not to get "hidden" files, but one instance of KWrite with the maximum number of tabs set there.

However, this is a regression, or at least missing functionality. Please bring the old behavior back (for my part as an option if you want) and fix my favorite not-at-all integrated development environment ;-)

Big thanks in advance!

(In reply to Nate Graham from comment #1)
> I thought we had a way to disable tabs but I can't find it either.
> 
> There is a "show tabs" item in the Settings menu you can uncheck, but that
> just hides the tab bar, rather than actually no longer making the window
> tab-based.

This 'feature' actually lost me data and took me hours to figure out. Just type some notes, hit CTRL-N - that's how I've used kwrite for years. If you have the tab bar disabled, your original 'file' is 'lost'. You will not be able to get it back until you figure out what the heck is going on - I can't image a worse UI disaster, tbh. I even logged out and logged in, thinking something had gone horribly wrong. Of course, this resulted in the notes being lost unrecoverably as kwrite doesn't save data rescue data of a file that hasn't been first named (I know, it's a feature request, a big one if I may say so, why not just restore all windows and data when I log in again?).

Anyhow, just a 'me too' here, we have Kate for tabs and I'm a happy user. I need kwrite to satisfy my urge to quickly write down some notes in a separate window I can put on another monitor, and then click the taskbar on kwrite to see all my notes with the expose effect. Super handy - and now I regularly accidentally hit CTRL-N to "open a new window" and then spend  hours frantically searching for the notes of that meeting I SWORE I wrote down but it's invisible now... Hidden in ONE of my many kwrite windows as an invisible tab. Horror ;-)

Please, devs, bring kwrite back, we already have Kate and one is great, but also - enough.

May I add that I appreciate new features coming to KWrite - really. Even if I wouldn't use them myself, it's generally good. My main gripe is with re-purposing an existing shortcut (CTRL-N) and changing its behavior completely, while a very common and well-establishjed shortcut for this new behavior exists: CTRL-T. Please, re-map CTRL-N to open a new window, and CTRL-T for a new tab, if you want to use a default shortcut... Having to learn to expect different behavior of KWrite from other apps is just not nice.

Dear contributor who changed kwrite. Thank you for adding stuff to kwrite. But please never forget one of the most significant reasons why people love KDE: It can be customized and rarely enforces confusing conflicting things on you.

It's probably well meant. But please at least make such a feature optional. And add me to the list of people who are happily using kate for more complex ui and kwrite as a simple one-window editor.

I'll downgrade kwrite for now but I would love to be able to avoid dragging a downgraded kwrite around forever on all my machines. It's my primary all-in-one notepad and now basically useless due to enforcing tabs, and that feature appears highly flawed.

Otherwise, if you want to highly expand kwrite and turn it into another kate, might forking it under a new name be an option? This way you could integrate all the intended changes without changing the very nature of kwrite as a simple one-window-editor. Might be a win-win-situation for everyone.

Best regards,
Martin

https://invent.kde.org/utilities/kate/-/merge_requests/1038

Please test 

https://invent.kde.org/utilities/kate/-/merge_requests/1038

One just needs an entry in the config dialog and people wanting more SDI like behavior can opt into that.

https://invent.kde.org/utilities/kate/-/merge_requests/1038

should now allow to have some more SDI like behavior again.

After a remarkable long build time on my Ryzen 3600 with 32 GB RAM, I just tested the branch … but checking "Prefer to open documents in own top level windows" (this is the option you added, no?!) does not change anything here: Open two files, get two tabs.

… and why the heck is the configuration now suddendly in a tab, and not in a dialog?! But this is another thing …

(In reply to Tobias Leupold from comment #17)
> After a remarkable long build time on my Ryzen 3600 with 32 GB RAM, I just
> tested the branch … but checking "Prefer to open documents in own top level
> windows" (this is the option you added, no?!) does not change anything here:
> Open two files, get two tabs.
> 
> … and why the heck is the configuration now suddendly in a tab, and not in a
> dialog?! But this is another thing …

Hi, how did you open the two files.
e.g. using the File->Open... I get two windows after this option is set.

For e.g. 

kwrite *.txt

I get X windows after setting this option, too.

I used the "Open" button. Opening more than one file via the menu interestingly actually yields multiple windows. But not when I use the "Open" button.

(In reply to Tobias Leupold from comment #20)
> I used the "Open" button. Opening more than one file via the menu
> interestingly actually yields multiple windows. But not when I use the
> "Open" button.

Hmm, you mean the open button in the toolbar? That yields a new window for me, too, given that is the same code as for the menu that seems strange.

No, re-testing, it actually depends on whether or not a file is already open (or the document is empty), not on the way how I open a file.

Start KWrite (empty) → open two files → get two tabs

Start KWrite (empty) → open a file → open two additional files → get two new windows

Start KWrite (empty) → type something → open two additional files → get two new windows

(In reply to Tobias Leupold from comment #22)
> No, re-testing, it actually depends on whether or not a file is already open
> (or the document is empty), not on the way how I open a file.
> 
> Start KWrite (empty) → open two files → get two tabs
> 
> Start KWrite (empty) → open a file → open two additional files → get two new
> windows
> 
> Start KWrite (empty) → type something → open two additional files → get two
> new windows

Ok, thanks, can reproduce that way, pushed a fix.

Seems to work now :-) PLEASE merge this, this option is so important to not break people's workflow (including mine)!

However, the newly opened windows don't have the same size as the original one. Here's a screencast to demonstrate this:
https://imgur.com/a/eyacawq

(In reply to Tobias Leupold from comment #24)
> Seems to work now :-) PLEASE merge this, this option is so important to not
> break people's workflow (including mine)!

I will wait for more feedback, but already thanks for testing.

> 
> However, the newly opened windows don't have the same size as the original
> one. Here's a screencast to demonstrate this:
> https://imgur.com/a/eyacawq

That is a different issue, perhaps we should use the current active window size for new ones.

(In reply to Christoph Cullmann from comment #25)
> > However, the newly opened windows don't have the same size as the original
> > one. Here's a screencast to demonstrate this:
> > https://imgur.com/a/eyacawq
> 
> That is a different issue, perhaps we should use the current active window
> size for new ones.

Sure, that's a different issue, but if we want to have the (good) old KWrite behavior back, this should also be fixed (whilst bringing back the also good old no-tabs functionality). With KWrite 22.04.3, new windows inherit the size of the one that opens the file. I'm not completely sure if this was always the case (IIRC, it also was the size of the last one closed or such, but I can also be wrong about this), but this would be okay behavior.

However thanks a lot for fixing this. You're really about to save me from turning my back on that "new" KWrite and searching for another minimalistic editor!

(In reply to Tobias Leupold from comment #26)
> (In reply to Christoph Cullmann from comment #25)
> > > However, the newly opened windows don't have the same size as the original
> > > one. Here's a screencast to demonstrate this:
> > > https://imgur.com/a/eyacawq
> > 
> > That is a different issue, perhaps we should use the current active window
> > size for new ones.
> 
> Sure, that's a different issue, but if we want to have the (good) old KWrite
> behavior back, this should also be fixed (whilst bringing back the also good
> old no-tabs functionality). With KWrite 22.04.3, new windows inherit the
> size of the one that opens the file. I'm not completely sure if this was
> always the case (IIRC, it also was the size of the last one closed or such,
> but I can also be wrong about this), but this would be okay behavior.
> 
> However thanks a lot for fixing this. You're really about to save me from
> turning my back on that "new" KWrite and searching for another minimalistic
> editor!

Hi, pushed fix for the size stuff, too.

I can confirm it works. Thanks a lot :-)

I don't know if this would be too much to ask for … but if there was the simple "Save/Discard/Cancel" dialog again if only one file was opened (instead of the in this case pointless list/tree/whatever view) when closing KWrite, we almost had goole ole KWrite back ;-)

Luckily, one can get rid off that "Welcome view" by default …

I've just created bug 463194 which I think cuts the Gordian knot on this mess that are all these recent changes to KWrite.

(In reply to kdekdokdy from comment #30)
> I've just created bug 463194 which I think cuts the Gordian knot on this
> mess that are all these recent changes to KWrite.

Sorry, that will not happen and you really erode my interest to fix issues like I did in this bug.

(In reply to Christoph Cullmann from comment #31)
> (In reply to kdekdokdy from comment #30)
> > I've just created bug 463194 which I think cuts the Gordian knot on this
> > mess that are all these recent changes to KWrite.
> 
> Sorry, that will not happen and you really erode my interest to fix issues
> like I did in this bug.

What is the problem? You don't agree that these changes add next to no value and are causing way more trouble than they're worth?

Unless I'm missing context, the cleanest way to fix these in one fell swoop is by admitting that sometimes we're all off to a false start and going back to a known good state.

(In reply to kdekdokdy from comment #32)
> (In reply to Christoph Cullmann from comment #31)
> > (In reply to kdekdokdy from comment #30)
> > > I've just created bug 463194 which I think cuts the Gordian knot on this
> > > mess that are all these recent changes to KWrite.
> > 
> > Sorry, that will not happen and you really erode my interest to fix issues
> > like I did in this bug.
> 
> What is the problem? You don't agree that these changes add next to no value
> and are causing way more trouble than they're worth?
> 
> Unless I'm missing context, the cleanest way to fix these in one fell swoop
> is by admitting that sometimes we're all off to a false start and going back
> to a known good state.

I don't agree with that these changes add next to no value and are causing way more trouble than they're worth.

Beside that your comments are more than rude, for all this changes you can find proper merge requests.

Like https://invent.kde.org/utilities/kate/-/merge_requests/692

Yeah, we obviously missed some issues and as you see we work in them.

Please keep this polite and constructive. Nobody wants to be threated with hostility for the work he did with the best intentions. And ranting about devs never encouraged anybody to fulfil the user's demands. I'm a KDE dev myself (only a small one, but still). I know this. At least a little.

Don't get me wrong, I also think that KWrite was perfect until this update. But as said: We have to keep this polite and constructive, otherwise, nobody will benefit from it.

I think Kate's/KWrite's devs DID realize that the recent changes caused a lot of hard feelings in their userbase. But we're on a good way to fix this. The tabbing thing is already fixed and just has to be merged. The (un)welcome dialog can be hidden, you only have to see it one time (it also annoys me, I also think this shouldn't be there – but I can hide it. So what?).

It IS almost the "old" KWrite again by now, because the devs DO listen to what we (the users) say. And they fix this stuff really fast, esp. if you take into account that it's christmas in a week. And I'm convinced there will be a good trade-off/solution to keep us all happy.

Problem is that with such matters of the heart which are perceived and discussed this emotionally, a bug report always becomes a chat, and people always get angry and inpolite …

(In reply to Tobias Leupold from comment #34)
> Please keep this polite and constructive. Nobody wants to be threated with
> hostility for the work he did with the best intentions. And ranting about
> devs never encouraged anybody to fulfil the user's demands. I'm a KDE dev
> myself (only a small one, but still). I know this. At least a little.
> 
> Don't get me wrong, I also think that KWrite was perfect until this update.
> But as said: We have to keep this polite and constructive, otherwise, nobody
> will benefit from it.
> 
> I think Kate's/KWrite's devs DID realize that the recent changes caused a
> lot of hard feelings in their userbase. But we're on a good way to fix this.
> The tabbing thing is already fixed and just has to be merged. The
> (un)welcome dialog can be hidden, you only have to see it one time (it also
> annoys me, I also think this shouldn't be there – but I can hide it. So
> what?).
> 
> It IS almost the "old" KWrite again by now, because the devs DO listen to
> what we (the users) say. And they fix this stuff really fast, esp. if you
> take into account that it's christmas in a week. And I'm convinced there
> will be a good trade-off/solution to keep us all happy.
> 
> Problem is that with such matters of the heart which are perceived and
> discussed this emotionally, a bug report always becomes a chat, and people
> always get angry and inpolite …

Thanks.

I think we are on a good way to allow people to get back their old workflow and only have not that large changes that stay still there that should not be of any negative effect.

https://invent.kde.org/utilities/kate/-/merge_requests/1038

fixed now

Thanks a lot :-)

(In reply to Tobias Leupold from comment #29)
> I don't know if this would be too much to ask for … but if there was the
> simple "Save/Discard/Cancel" dialog again if only one file was opened
> (instead of the in this case pointless list/tree/whatever view) when closing
> KWrite, we almost had goole ole KWrite back ;-)
> 
> Luckily, one can get rid off that "Welcome view" by default …

I just filed a MR implementing this very change: https://invent.kde.org/utilities/kate/-/merge_requests/1047

> Beside that your comments are more than rude

I take exception to this accusation. Kindly point out what is it that you perceive as "rude".