Bug 381602

Summary:	support for multi/standalone windows
Product:	[Frameworks and Libraries] frameworks-ktexteditor	Reporter:	RJVB <rjvbertin>
Component:	general	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	wishlist	CC:	kare.sars
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	All
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description RJVB 2017-06-24 10:10:44 UTC

There's a feature that I've been missing in text editors based on KTextEditor (and in KDevelop in particular): a possibility to open multiple documents in individual windows that can be sized and moved independently to optimise the use of available screen space.

This is something I've been used to as a long-term Mac user having worked with multi-head set-ups since the early 90s, but I think that the same observation can be made for the kind of large, (ultra) high-resolution displays that are becoming accessible nowadays. A MDI interface just doesn't allow to make optimum use of all that screen space, and the possibility to split a window horizontally or vertically just doesn't give the same kind of flexibility.

For those who have known it, Xcode 3.2.6 remains a reference for me in this aspect (though it never stored individual window sizes).

Supposing that KTextEditor would indeed be the logical place to implement support for something like this, how much of an overhaul would it require to be done right and in such a way that the feature becomes available automatically in Kate, KDevelop and the rest of the bunch? I'm thinking of an option in the tab or document context menu to detach the document, but exposure via the API allowing documents to be open directly in their own window would be nice too.

FWIW, Qt Creator approaches this with multiple MDI windows that can each hold their own tabbed set of documents. It doesn't behave exactly as I expect (and am comfortable with), but I suppose it's better than nothing.

Comment 1 Kåre Särs 2017-06-24 15:26:21 UTC

Thanks for the report.

I think we already have what you are asking for with at least Kate. You can use View -> New Window, but then you get the same session, just two windows.

If you open a file with kate with the parameter "-n" you get a new instance of Kate that does not share session with the already running one. I have personally changed the command that Dolphin uses to start Kate to always open in a new instance.

If you use the documents view you can also right-click a document in the tree and select to open it with an external application (KWrite, ...).

Is this enough for you needs?

Regards,
  Kåre

Comment 2 RJVB 2017-06-24 15:43:10 UTC

> View -> New Window, but then you get the same session, just two windows.

That's comparable to what Creator does, though there you don't get an exact clone of the entire session window, complete with side-views and all. The only use case I could think of where I would find this useful myself is if one of the cloned copies didn't change when I was editing the other, as a quick and dirty way to keep a copy of an original version at hand. 

What I'm thinking of is a possibility of opening just an editor window as if by reparenting a document tab, in a window that doesn't duplicate any unnecessary widgets but that does belong to the same process. Ideally you'd be able to detach an existing tab but also open a document in its own window from the document or file tree view; that choice could even be recorded in the session data and possibly be made the default behaviour.

And I'm really also thinking of a feature that's implemented at the level of the framework or kpart, so that it becomes available automatically in any application that uses them, without need for any action.

Comment 3 Kåre Särs 2017-06-24 15:59:30 UTC

The KTextEditor part is only responsible of opening and editing a document. So far the applications take care of keeping track of what files are open and stuff like that. I don't think it is the "renderer's" task to add this kind of feature, but that's just me ;)

It is possible to add a "detach" feature if wanted quite easily, but somebody would have to do it and maintain it...

Comment 4 RJVB 2017-06-24 17:07:55 UTC

I don't disagree with you, not entirely at least :) Let's put it this way: the less applications have to do to deploy a new feature, the more likely it is to become available quickly and smoothly. Esp. if application developers might think it's something that should be implemented at this or that level, or if they're not convinced about a feature.

I wouldn't mind at all working on this (seems like a fun hopefully little problem to tackle), but don't think I know the code well enough to start playing around with it on my own. As to maintaining it ... isn't that mostly a matter of trying not to break anything when you introduce changes?

Comment 5 Christoph Cullmann 2019-05-19 15:03:26 UTC

Dear user, this wish list item is now closed, as it wasn't touched in the last year and no contributor stepped up to implement it.

The Kate/KTextEditor team is small and we can just try to keep up with fixing bugs.

Therefore wishes that show no activity for a years or more will be closed from now on to keep at least a bit overview about 'current' wishs of the users.
If you want your feature to be implemented, please step up to provide some patch for it.

If you think it is really needed, you can reopen your request, but keep in mind,
if no new good arguments are made and no people get attracted to help out to implement it,
it will expire in a year again.

We have a nice website https://kate-editor.org that provides all the information needed to contribute, please make use of it.

Patches can be handed in via https://phabricator.kde.org/differential/

Greetings
Christoph Cullmann