Is multi-window ever planned?

[René J.V. Bertin]

On Tuesday November 25 2014 14:08:36 Milian Wolff wrote:

> I plan to copy what QtCreator does - i.e. giving users the ability to cut out 

As long as that doesn't get rid of the tabbed view (Qt Creator is the worst IDE I know for working with multiple open documents in that aspect ...) ;)

> the editor pane into a separate window. Individual toolviews can already float 
> in their own window (useful for documentation e.g.).

Yeah, except that floating above all other windows isn't that practical, esp. if you're not on a multi-head system. It's also not very practical if you want to peruse multiple documentation sources at the same time (say, Assistant & Kdevelop's doc window) and the window gets unmapped when you switch to another application.

It shouldn't be very hard to turn floating "utility windows" into full standalone windows, or is it?

> Having two "full" KDevelop windows is pretty complex code-wise and doesn't 

Who said it should be two? In this context, /methings it's either one or [m]any :)

> really pay off that much, in my opinion. That said, if anyone wants to work on 
> multi-window support, he's more than invited to do so.

Having used Xcode 3.2 for a long time, I still think the best approach (for me) is one where you have dedicated project, build/code analysis, search and editor windows. That allows you to make optimal use of your existing screen estate and the project you're working on. Especially if the IDE also remembers individual window sizes (which Xcode *doesn't*) ;)

> Putting the splittable editor into a separate window is pretty easy compared 
> to that.

That's what I was hoping. But if you go down that route (and ditto for the toolviews), it should also not be hard to get something that I consider ideal (see above):

- Make it a configurable option to use separate windows for editors and/or toolviews.
- If editor windows are set to be independent from the main window (and possibly if the toolviews are, too), do not preallocate space for said views in the mainwindow, allowing it to be(come) more compact.
- And that could lead to an additional toolview (which IMHO is just fine in the project window): one which shows the files belonging to the folder or target selected in the project tree view. A bit like the traditional view used in many email clients; folders in a column on the left, then folder contents in a pane top-right and optionally the contents of what's selected in there in the pane bottom-right.

Regrettably the discontinuation of (K)Ubuntu's Project Neon5 makes it even harder for me to help out with KF5 development ...

R.