Bug 472334

Are you aware of the existing split view feature? Some users spread the KDevelop window with split views over multiple monitors (see e.g. Bug 377742).

> add a way of tracking the currently active/focused tab container/window so we know which one to address when a new tab is requested for instance.
KDevelop already tracks the currently active/focused split view, but unfortunately it's not very reliable (Bug 468703).

(In reply to Igor Kushnir from comment #1)
> Are you aware of the existing split view feature? Some users spread the
> KDevelop window with split views over multiple monitors (see e.g. Bug
> 377742).

Hello Igor! Yes, of course I'm aware of that feature, I couldn't live without it! :) But while it is a fantastic feature to have, I wouldn't call it a solution for multi-monitor use for several reasons:

* It does not work for asymmetric monitor layouts. And it obviously only works when monitors are adjacent.
* It prevents the window manager from simply maximizing a window on each screen. Having to manually drag it out is quite annoying, and can be even worse for people with tiling wm's.
* Manually dragging out the window to span multiple monitors, will cause certain things, such as menu's and toolbar buttons and what not to cross the monitor bevel's making them really hard to read.

What I'm suggesting is not getting rid of split screen in favor of this, but rather implementing proper multi-window support, where each window can have it's own tabs and split screen views. 

I don't even mind taking a stab at the implementation if, and only if, it's a feature that's likely to be accepted upstream.

(In reply to John Sennesael from comment #2)
> I don't even mind taking a stab at the implementation if, and only if, it's
> a feature that's likely to be accepted upstream.
I am not thrilled with a prospect of being a lone reviewer of such a large new feature. You can propose the multi-window feature on the KDevelop development mailing list: https://mail.kde.org/mailman/listinfo/kdevelop-devel. Perhaps some KDevelop developer would become interested and agrees to review and eventually merge the feature implementation.

(In reply to Igor Kushnir from comment #3)
> I am not thrilled with a prospect of being a lone reviewer of such a large
> new feature. You can propose the multi-window feature on the KDevelop
> development mailing list

Thanks Igor. I've sent a message to the list.

(In reply to John Sennesael from comment #4)
> Thanks Igor. I've sent a message to the list.
Thank you. If you are not subscribed to the list, the moderation screen can delay the email delivery for days or even weeks :(

(In reply to Igor Kushnir from comment #5)
> (In reply to John Sennesael from comment #4)
> > Thanks Igor. I've sent a message to the list.
> Thank you. If you are not subscribed to the list, the moderation screen can
> delay the email delivery for days or even weeks :(

It made it through. ->  https://mail.kde.org/pipermail/kdevelop-devel/2023-July/063774.html

Created attachment 175658 [details]
Screenshot of a disabled feature MainWindowPrivate::newWindow()

I stumbled upon a never-called function MainWindowPrivate::newWindow() in https://commits.kde.org/kdevelop?path=kdevplatform/shell/mainwindow_actions.cpp . Its only use was commented out in https://commits.kde.org/kdevelop/c4e3e763e9ca779eae0605e3f4e203cd9d51b1be and removed in https://commits.kde.org/kdevelop/0b5aab35b7d1e8904442399a08270b81e066777e . Just tested and it works (see the attached screenshot). I am sure the feature has bugs, but bug fixes should be much easier to implement and review compared to a new feature, because they can be gradual.

I am currently fixing KDevelop MainWindow save/load bugs. Was going to remove this unused function along with the UiController::NewWindow mode needed only by this function. But then decided to test it (by inserting `newWindow();return;` at the beginning of MainWindowPrivate::reloadAll()) and remembered this bug report. I'll keep this disabled feature in case you decide to try out and possibly enable/fix/improve it.

Hello Igor,

> I'll keep this disabled feature in case you decide to try out and possibly enable/fix/improve it.

Thanks for that, good to know about this function! I will take a stab at leveraging it for an implementation of this feature then, although it might be a while before I get to it.

Thanks for keeping this in mind. ( I commend you on your memory! ;) )

(In reply to John Sennesael from comment #8)
> Thanks for that, good to know about this function! I will take a stab at
> leveraging it for an implementation of this feature then, although it might
> be a while before I get to it.
When you get to it, make the feature at least somewhat usable for yourself and fix not-too-hard critical bugs first. Then we can enable the feature in master and do further fixes and improvements in separate merge requests.

I hope the design issues referred to by https://commits.kde.org/kdevelop/c4e3e763e9ca779eae0605e3f4e203cd9d51b1 do not require thorough redesign to support multi-monitor setup.

One bug is already visible on the screenshot: the KTextEditor status bar is present in only one (primary) main window and displays info ("CMake") for the last activated document, that is for the CMakeLists.txt file opened in the secondary main window.