Re: Support moving editor windows to a new monitor.

--000000000000d1d3d80601255e79
Content-Type: text/plain; charset="UTF-8"

I can review it, I do lack the time to work on it tought.

On Sun, 23 Jul 2023 at 12:05 John Sennesael <[email protected]> wrote:

> Hello all,
>
> I recently posted a feature request for allowing source editors to be
> opened in a new window (which can have it's own splits and tabs) on
> bugs.kde.org, and it was suggested I contact the mailing list
> instead. - ( https://bugs.kde.org/show_bug.cgi?id=472334 ) - So I'll
> repeat it below:
>
> 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,..
>
> As I had mentioned in the original issue on the bug tracker, I don't
> mind taking a stab at the implementation of this myself, but Igor was
> concerned about being the only reviewer on this feature. As such,
> would others be interested in reviewing or help developing this?
>
> Thanks,
>
> -jns
>
>
>
>

--000000000000d1d3d80601255e79
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I can review it, I do lack the time to work on it tought.=
</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Sun, 23 Jul 2023 at 12:05 John Sennesael &lt;<a href=3D"mailto:john=
@adminking.com">[email protected]</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"=
>Hello all,<br>
<br>
I recently posted a feature request for allowing source editors to be<br>
opened in a new window (which can have it&#39;s own splits and tabs) on<br>
<a href=3D"http://bugs.kde.org" rel=3D"noreferrer" target=3D"_blank">bugs.k=
de.org</a>, and it was suggested I contact the mailing list<br>
instead. - ( <a href=3D"https://bugs.kde.org/show_bug.cgi?id=3D472334" rel=
=3D"noreferrer" target=3D"_blank">https://bugs.kde.org/show_bug.cgi?id=3D47=
2334</a> ) - So I&#39;ll<br>
repeat it below:<br>
<br>
This is a feature request to make editor windows detachable such that<br>
they can moved onto a different monitor head. This new editor window<br>
can have it&#39;s own tabs as well. So it would be like having a second<br>
main window, but without the toolbar, menu, etc,...<br>
<br>
This could be implemented by dragging tabs outside of the main<br>
window, and/or having a context menu on right-clicking the tab with a<br>
&#39;move to new window&#39; option, along with a corresponding entry in th=
e<br>
Window menu.<br>
<br>
I took a look at the code to see how much work this would be, and<br>
unfortunately, due to the way things are set up, with the Sublime<br>
MainWindow owning a lot of the state and event handling around tabs,<br>
it would not be very trivial.<br>
<br>
In order to implement this, we&#39;d need to abstract all of the<br>
tab-specific code into a type of TabContainer Widget or Window base<br>
class and add a way of tracking the currently active/focused tab<br>
container/window so we know which one to address when a new tab is<br>
requested for instance. Moreover, all the tab related event/signal<br>
handling functions would also have to be moved, as the sublime<br>
MainWindow currently has stuff like TabDoucleClicked() etc,..<br>
<br>
As I had mentioned in the original issue on the bug tracker, I don&#39;t<br=
>
mind taking a stab at the implementation of this myself, but Igor was<br>
concerned about being the only reviewer on this feature. As such,<br>
would others be interested in reviewing or help developing this?<br>
<br>
Thanks,<br>
<br>
-jns<br>
<br>
<br>
<br>
</blockquote></div></div>

--000000000000d1d3d80601255e79--