Alternative approach for editor windows

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Alternative approach for editor windows

Torsten-3
Hi everyone,

I have uploaded a patch for bug #53712
(https://savannah.gnu.org/bugs/index.php?53712), which replaces the tab
widget of the editor by an mdi area with freely arrangeable editor
subwindows. If this approach is promising I would push the patch and
start working on still missing features.

Torsten

Reply | Threaded
Open this post in threaded view
|

Re: Alternative approach for editor windows

Daniel Sebald
On 07/01/2018 09:59 AM, Torsten wrote:
> Hi everyone,
>
> I have uploaded a patch for bug #53712
> (https://savannah.gnu.org/bugs/index.php?53712), which replaces the tab
> widget of the editor by an mdi area with freely arrangeable editor
> subwindows. If this approach is promising I would push the patch and
> start working on still missing features.
>
> Torsten

It took me a little while to figure out that the MDI tiling is activated
by selecting one of the options of the Editor:View:Windows drop-down
menu to take the MDI out of "Tabbed View".  The instant tiling is nice.
The "Cascade Windows" does what is expected; however, given this big
wide space for the main MDI window, it creates very tiny subwindows.  It
could make the subwindows much bigger, say 3/4 of the MDI window size.

In the discussion of bug #53712 you raise the issue of (not) floating
the individual sub-panels.  This is a discussion we've had with the
Variable Editor, which currently allows floating the QDockWidgets
without associated icons--the Qt construct.  Whether I like that or not
is up for my own debate, but I think for now we have three sorts of
paradigms which I think is OK and maybe good for the time being because
it should garner feedback on what exactly is the best design in terms of
work flow.  There is

1) Figure (independent):  That is, each figure is floated and has its
own menu in the window manager's task bar.  Can generate a lot of icons,
but some window managers will group those icons under a single icon.

2) Variable Editor (Qt QMainWindow):  There is one icon in the task bar
for "Variable Editor", but the Variable Editor's subpanels can be
floated without a representative task bar icon.  Can get a bit confusing
with the disappearance of floated windows when the V.E. goes out of focus.

3) Text Editor (Qt MDI): There is one icon in the task bar for "Editor",
while the subpanels cannot be floated.  Remains to be seen what the pros
and cons are.

Personal comments I would make are:

Although the design of 1 seems convenient, i.e., the grouping of icons,
I can't get used to KDE and that icon grouping.  It really disrupts my
work flow because I have to put too much conscious thought into
positioning the mouse over the grouped icon, looking at the list in the
group and then selecting the right file/window/figure.  Plus, the layout
on the screen, or the temporal order in which the windows were created
in terms of the associated list order doesn't make sense to me.  When I
have an engaging idea or thought, I want to get to the editor file or
figure or whatever as quickly as possible and not interrupt that
thought.  Whereas, a big list of small, scrunched icons in the task bar
doesn't seem to impede my train of thought.  I seem to remember the
order of icons more than actually reading the text in the task bar.

I do sort of prefer having individual floated windows/entities for which
I can have, say, a fraction of the editing file visible or a fraction of
the command line window visible.  A lot of times it is only a single
script line in a broader context that I want to see when running some
command, or vice versa when editing code based on the single line output
of a command.  That is, overlaying two windows and switching back and
forth is nice.  But, honestly, this is why I'm still preferential to
non-GUI Octave... so that alternative always exists.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Alternative approach for editor windows

Torsten-3
On 01.07.2018 20:22, Daniel J Sebald wrote:

> On 07/01/2018 09:59 AM, Torsten wrote:
>> Hi everyone,
>>
>> I have uploaded a patch for bug #53712
>> (https://savannah.gnu.org/bugs/index.php?53712), which replaces the tab
>> widget of the editor by an mdi area with freely arrangeable editor
>> subwindows. If this approach is promising I would push the patch and
>> start working on still missing features.
>>
>> Torsten
>
> It took me a little while to figure out that the MDI tiling is activated
> by selecting one of the options of the Editor:View:Windows drop-down
> menu to take the MDI out of "Tabbed View".  The instant tiling is nice.
> The "Cascade Windows" does what is expected; however, given this big
> wide space for the main MDI window, it creates very tiny subwindows.  It
> could make the subwindows much bigger, say 3/4 of the MDI window size.
>
> In the discussion of bug #53712 you raise the issue of (not) floating
> the individual sub-panels.  This is a discussion we've had with the
> Variable Editor, which currently allows floating the QDockWidgets
> without associated icons--the Qt construct.  Whether I like that or not
> is up for my own debate, but I think for now we have three sorts of
> paradigms which I think is OK and maybe good for the time being because
> it should garner feedback on what exactly is the best design in terms of
> work flow.  There is
>
> 1) Figure (independent):  That is, each figure is floated and has its
> own menu in the window manager's task bar.  Can generate a lot of icons,
> but some window managers will group those icons under a single icon.
>
> 2) Variable Editor (Qt QMainWindow):  There is one icon in the task bar
> for "Variable Editor", but the Variable Editor's subpanels can be
> floated without a representative task bar icon.  Can get a bit confusing
> with the disappearance of floated windows when the V.E. goes out of focus.
>
> 3) Text Editor (Qt MDI): There is one icon in the task bar for "Editor",
> while the subpanels cannot be floated.  Remains to be seen what the pros
> and cons are.
>
> Personal comments I would make are:
>
> Although the design of 1 seems convenient, i.e., the grouping of icons,
> I can't get used to KDE and that icon grouping.  It really disrupts my
> work flow because I have to put too much conscious thought into
> positioning the mouse over the grouped icon, looking at the list in the
> group and then selecting the right file/window/figure.  Plus, the layout
> on the screen, or the temporal order in which the windows were created
> in terms of the associated list order doesn't make sense to me.  When I
> have an engaging idea or thought, I want to get to the editor file or
> figure or whatever as quickly as possible and not interrupt that
> thought.  Whereas, a big list of small, scrunched icons in the task bar
> doesn't seem to impede my train of thought.  I seem to remember the
> order of icons more than actually reading the text in the task bar.
>
> I do sort of prefer having individual floated windows/entities for which
> I can have, say, a fraction of the editing file visible or a fraction of
> the command line window visible.  A lot of times it is only a single
> script line in a broader context that I want to see when running some
> command, or vice versa when editing code based on the single line output
> of a command.  That is, overlaying two windows and switching back and
> forth is nice.  But, honestly, this is why I'm still preferential to
> non-GUI Octave... so that alternative always exists.
>
> Dan

Dan, thanks for the feedback.

Since the main dock widgets can be made full screen, I honestly do not
see the advantage in floating wigdets within these main widgets (like in
the VE). The internal widgets can be arranged within this full screen
main widget as if they were floating. Having several (parallel) levels
of floating widgets within the same application might be quite confusing.

If the mdi approach for the editor will find its way into the dev
branch, I intend to add shortcuts for a comfortable way to switch
between the subwindows, like, e.g. switching between the VE's internal
widgets.

Torsten



Reply | Threaded
Open this post in threaded view
|

Re: Alternative approach for editor windows

Daniel Sebald
On 07/01/2018 02:16 PM, Torsten wrote:
> On 01.07.2018 20:22, Daniel J Sebald wrote:
>> On 07/01/2018 09:59 AM, Torsten wrote:

> If the mdi approach for the editor will find its way into the dev
> branch, I intend to add shortcuts for a comfortable way to switch
> between the subwindows, like, e.g. switching between the VE's internal
> widgets.

There's more room for layout icons too.  Either way, tiling in one key
or mouse action will be welcome.  The problem with icons is that
accidentally clicking one of them is liable to rearrange the layout in
an undesired way--could have a "Tile verticall? (yes/no)" dialog box
after pressing the icon.

Dan