This is a feature request to make editor windows detachable such that they can moved onto a different monitor head. This new editor window can have it's own tabs as well. So it would be like having a second main window, but without the toolbar, menu, etc,... This could be implemented by dragging tabs outside of the main window, and/or having a context menu on right-clicking the tab with a 'move to new window' option, along with a corresponding entry in the Window menu. I took a look at the code to see how much work this would be, and unfortunately, due to the way things are set up, with the Sublime Mainwindow owning a lot of the state and event handling around tabs, it would not be very trivial. In order to implement this, we'd need to abstract all of the tab-specific code into a type of TabContainer Widget or Window base class and 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. Moreover, all the tab related event/signal handling functions would also have to be moved, as the sublime MainWindow currently has stuff like TabDoucleClicked() etc,..
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.
A possibly relevant merge request was started @ https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/715
Git commit 02fd1702143b7674442d5fb68dce0504f98b03ad by Igor Kushnir. Committed on 10/02/2025 at 14:30. Pushed by igorkushnir into branch 'master'. Update comments in UiController::switchToArea() The FIXME comment removed in this commit was added in 1131f341418bee1c6331ab09a2ab429724deb0d4 and is long obsolete now, because UiController::switchToArea() usually switches to the specified area in the active main window. Only KDevelop::MainWindowPrivate::newWindow() passes SwitchMode::NewWindow to switchToArea(), but this newWindow() function itself is never called since c4e3e763e9ca779eae0605e3f4e203cd9d51b1be. The added TODO comments explain what needs to be done if/when the multi-window feature is restored. The multi-window feature has been discussed in comments under the linked bug report in recent years. M +7 -2 kdevplatform/shell/uicontroller.cpp https://invent.kde.org/kdevelop/kdevelop/-/commit/02fd1702143b7674442d5fb68dce0504f98b03ad
Small update: I tested newWindow() and it pretty much behaved as I figured it would - it spawns a new /main/ window. It creates a new MainWindow instance, which is basically the same as running 2 kdevelop processes (but within the same process space). That makes sense, given what I saw when I looked at this the first time around, as mentioned in the initial bug report. Currently a 'window' is basically holding the entire application state, and that all would have to be moved into a proper application class, with a fairly minimal window/editor class holding only the state needed for editing whatever tabs are open in it.
(In reply to John Sennesael from comment #12) > Currently a 'window' is basically holding the entire application state, and > that all would have to be moved into a proper application class, with a > fairly minimal window/editor class holding only the state needed for editing > whatever tabs are open in it. I don' think this is the case. There are many controller classes, which are shared among all main windows. I believe each main window should have (as it does already) its own view containers, document views and tool view widgets. I'm going to create a merge request that shares tool view widgets between areas (code/debug/review) soon. But since ToolDocument instances are owned by the UiController, a QHash<const QMainWindow*, ToolViewWidgetData> would have to be stored in ToolDocumentPrivate to give each main window separate tool view widgets and even distinct sets of tool views.
(In reply to Igor Kushnir from comment #13) > I'm going to create a merge request that shares tool view widgets between > areas (code/debug/review) soon. But since ToolDocument instances are owned > by the UiController, a QHash<const QMainWindow*, ToolViewWidgetData> would > have to be stored in ToolDocumentPrivate to give each main window separate > tool view widgets and even distinct sets of tool views. Now that I thought about this some more, I plan to store the tool view widget cache in IdealController instead of ToolDocument. Each main window has its own IdealController, which is correct, because this controller manages the per-main-window tool view UI. > So it would be like having a second main window, but without the toolbar, menu, etc,... I think we should keep the existing full-featured multi-window concept. You would still be able to achieve your preference of minimal UI. The configuration of each main window will be stored in a separate config group. Toolbars and tool views can already be removed. Preferences for hiding the main menu and the status bar can be implemented.
*** Bug 423798 has been marked as a duplicate of this bug. ***