Re: Alternative approach for editor windows

[Daniel J 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