SUMMARY Kate manages this but not KWrite apparently: when the option **"Open each document in its own window"** is unticked (hinted by _"If enabled, each document will be opened in its own window. If not enabled, each document will be opened in a new tab in the current window."_), opening a new document (either from terminal or file explorer) should go in a new tab instead of a new window. STEPS TO REPRODUCE 1. Open KWrite (empty document or exsiting document) 2. From terminal `kwrite <other-document>` or file explorer (Dolphin in my case) -> open the other document. OBSERVED RESULT Each new document opened creates a new window. EXPECTED RESULT Each new document opened should instead be a new tab in the existing window. Just like when opening from the existing KWrite windows -> "Open" SOFTWARE/OS VERSIONS Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.2 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Kernel Version: 6.15.5-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i7-1195G7 @ 2.90GHz Memory: 16 GiB of RAM (15.3 GiB usable) Graphics Processor: Intel® Iris® Xe Graphics ADDITIONAL INFORMATION ! Not to be confused with Bug ID [498972](https://bugs.kde.org/show_bug.cgi?id=498972)
This is working as expected. If you want the single instance re-using features, use Kate. > **"Open each document in its own window"** is unticked (hinted by _"If enabled, each document will be opened in its own window. If not enabled, each document will be opened in a new tab in the current window."_), This means that if you open a document from within Kwrite it will go in a tab or new window depending upon the settings.
(In reply to Waqar Ahmed from comment #1) > This is working as expected. If you want the single instance re-using > features, use Kate. > > > **"Open each document in its own window"** is unticked (hinted by _"If enabled, each document will be opened in its own window. If not enabled, each document will be opened in a new tab in the current window."_), > > This means that if you open a document from within Kwrite it will go in a > tab or new window depending upon the settings. Thank you for your reply Ahmed :) I appreciate! I know that Kate has such a feature, but I am most of the time overwholemed by Kate's interface and when I want to edit simple text documents, this is indeed KWrite I want to use. I would be gratefull if a feature to automatically open a new tab instead of window was available in KWrite as well 🙏.
(In reply to maxanthem from comment #2) > (In reply to Waqar Ahmed from comment #1) > > This is working as expected. If you want the single instance re-using > > features, use Kate. > > > > > **"Open each document in its own window"** is unticked (hinted by _"If enabled, each document will be opened in its own window. If not enabled, each document will be opened in a new tab in the current window."_), > > > > This means that if you open a document from within Kwrite it will go in a > > tab or new window depending upon the settings. > > Thank you for your reply Ahmed :) I appreciate! > I know that Kate has such a feature, but I am most of the time overwholemed > by Kate's interface and when I want to edit simple text documents, this is > indeed KWrite I want to use. > I would be gratefull if a feature to automatically open a new tab instead of > window was available in KWrite as well 🙏. Sorry, that is out of scope, if you want that, use Kate.
(In reply to Christoph Cullmann from comment #3) > Sorry, that is out of scope, if you want that, use Kate. Dear Christoph, thank you for your reply. Then could you indicate me where I could contact the devs of KWrite? Or should I understand that KWrite is now offically dead? I really intend to use KWrite for my .txt documents. I already use Kate for my coding projects: I don't want to mix them. I hope to find some support, or maybe a revived fork of KWrite, instead of receiving a systematic answer "use Kate". I really respect your work, but I would have hoped for a bit more understanding.
(In reply to maxanthem from comment #4) > (In reply to Christoph Cullmann from comment #3) > > Sorry, that is out of scope, if you want that, use Kate. > > Dear Christoph, thank you for your reply. Then could you indicate me where I > could contact the devs of KWrite? Or should I understand that KWrite is now > offically dead? I really intend to use KWrite for my .txt documents. I > already use Kate for my coding projects: I don't want to mix them. I hope to > find some support, or maybe a revived fork of KWrite, instead of receiving a > systematic answer "use Kate". I really respect your work, but I would have > hoped for a bit more understanding. Ok I looked around and asked for help and finally get a better understanding: what I need is a simplified Kate and I will try to achieve that by tweaking the settings and disabling pluggins. Honestly, this is the kind of answer I was hoping to receiving. Despite the fact that I perceived a lack of patience and pedagogy, I still really respect your work and dedication Waqar Ahmed and Christoph Cullmann 🙏😊
*** Bug 509250 has been marked as a duplicate of this bug. ***
+1 For this feature. Would be pretty ergonomic if implemented, imo. I get that current behavior is intentional, but couldn't really understand the intentions with which this behavior is enforced. Would absolutely love to know more about it. Nevertheless, a great piece of software. Thanks a ton for maintaining KWrite!
Waqar, could we reconsider this? Or at least make the option's UI text clearer regarding what exactly it controls?
Improving the option's text should definitely be done I guess since its confusing people. As for reconsidering, I am not sure. Christoph what do you think? The reason we have not enabled this for Kwrite is to keep KWrite simple, and it because it annoyed a lot of people the last time we changed KWrite's behaviour. If we do this, the next bug is going to be "Please add an option to disable reusing an already open instance of KWrite".
(In reply to Waqar Ahmed from comment #9) > Improving the option's text should definitely be done I guess since its > confusing people. > > As for reconsidering, I am not sure. Christoph what do you think? > > The reason we have not enabled this for Kwrite is to keep KWrite simple, and > it because it annoyed a lot of people the last time we changed KWrite's > behaviour. If we do this, the next bug is going to be "Please add an option > to disable reusing an already open instance of KWrite". Thanks for the explanation. I believe a better approach may be to 'enable' the 'Open each document in its own window' by default and allow the behavior to open the documents in same session if that option is unchecked by the user. Or, it may also be preferable to have separate options for the users to have: 1. Open 'New File' created in KWrite to open in the same session but open a document in different session (current behavior with unchecked) 2. Open 'New File' in different session and open a document in different session (current behavior with checked) 3. Open 'New File' in same session and open a document in same session (the behavior that is being discussed in this request) Any of the above 3 may be the default behavior based on 'the user behavior understanding' of the developers. Just my 2 cents.
(In reply to Waqar Ahmed from comment #9) > Improving the option's text should definitely be done I guess since its > confusing people. > > As for reconsidering, I am not sure. Christoph what do you think? > > The reason we have not enabled this for Kwrite is to keep KWrite simple, and > it because it annoyed a lot of people the last time we changed KWrite's > behaviour. If we do this, the next bug is going to be "Please add an option > to disable reusing an already open instance of KWrite". Yeah, fixing the text is OK, but adding the feature is no good idea, if one wants it, please use Kate.
It would be certainly nice to have a clearer text for that option. Honestly, I find myself unable to quite see how it's objectively more suitable to not provide an option to users while keeping the current behavior exactly the same. It may change the option from a `checkbox` to a `select-dropdown`, which seems within the KWrite's complexity threshold (or so do I hope). But yeah, I guess that's just me. You guys know better.
Personally I think in a tab-based app, it makes sense to open external files in new tabs rather than new windows — especially if the tab feature is optional. When tabs are turned on, isn't that a pretty good indication that the user wants to organize their files using tabs rather than windows?
(In reply to Nate Graham from comment #13) > Personally I think in a tab-based app, it makes sense to open external files > in new tabs rather than new windows — especially if the tab feature is > optional. When tabs are turned on, isn't that a pretty good indication that > the user wants to organize their files using tabs rather than windows? That requires all the complexity of DBus and Co. we have in Kate. I don't see that, if we just start to add more and more to KWrite we can essentially just remove it. The only diff then would be that the plugin stuff is off.
A few points that in my opinion may be relevant here: 1. I think I may have kind of understood the reason behind differences in KWrite's users' opinion and the dev team's opinion on this matter (correct me if I'm wrong though). For the dev team, whether or not to implement a feature also involves a decision with regards to 'code complexity' (which seems substantial in this case). Whereas from user standpoint, its usually a matter of 'usage complexity'. As an example, for users, asking for support of a programming language, or multiple cursor support, would amount to complexity. 2. AFAIK, the extent to which 'code complexity' is taken into consideration when deciding upon whether to implement a feature (or in this case, to fix a bug) that balances 'usage complexity' is a matter of organization's internal policies. So yeah, I guess its up to the KDE Org policies and the devs to deliberate and decide. 3. One of the main reasons that users come here asking for help, and reporting bugs is likely because KWrite is distributed in reputed distributions like Fedora. If this is in fact an unmaintained application, I think such distribution's communities should be made aware of this fact in good faith (or public database be updated as may be the case as per KDE policies). This will allow them to move on to other applications for basic text editing that support basic features (like the feature/bugfix being discusses here). FeatherPad comes to mind as an alternative to KWrite.
I fail to see how one jumps from 'we will not add feature x' to 'it is unmaintained'. KWrite is maintained, but that doesn't mean it will get all features Kate has, as they have distinct goals.
(In reply to Christoph Cullmann from comment #16) > I fail to see how one jumps from 'we will not add feature x' to 'it is > unmaintained'. Here are my thoughts on this: When a user sees KWrite, they see a text editor. When they request for a bugfix for KWrite, they do so for their favorite text editor. They probably (rather very likely) don't have a clue of the underlying code and its similarities with the code of Kate. They ask for such a bugfix that has very little to do with doing development or coding, and they are told that this fix won't be there but instead to use Kate. The user sees Kate as code editor and KWrite as a text editor. So for a bugfix that relates to behavior of the application and not development, when they are advised to use Kate, we might sort of see where they might be getting that idea about KWrite and be contributing to their confusion/misunderstanding of KWrite's purpose. I hope that kind of makes sense.
I don't have a comment on the implementation, but to me, in terms of UX, being tab-based means externally-opened documents should be opened in new tabs. If this is technically problematic, it may make sense to change the implementation to share more code between KWrite and Kate, or remove the feature from KWrite and let Kate be the tab-based app.
(In reply to Nate Graham from comment #18) > I don't have a comment on the implementation, but to me, in terms of UX, > being tab-based means externally-opened documents should be opened in new > tabs. > > If this is technically problematic, it may make sense to change the > implementation to share more code between KWrite and Kate, or remove the > feature from KWrite and let Kate be the tab-based app. Sorry, but that makes no sense for me, we had exactly the other request in the past to have there tabs, just like they are now. That we don't share instances doesn't break the tab feature. And if one really wants all that, one can use Kate. Sharing instances will make all other use of KWrite harder, like for using it as git commit editor. Shall it block? Shall it not? We have all that in Kate and I don't see we need that there.