[Octave-bug-tracker] [bug #53005] Variable editor: slow performance with large arrays

[Dan Sebald]

Follow-up Comment #20, bug #53005 (project octave):

I'm testing your recent changes.  I'm not quite clear on the intended behavior
so I'll just give general observations.

It sounds from what you wrote that no longer is automatic Autofit used (or
"continuous" autofit).  So am I understanding correctly that the "Autofit"
checkbox and "By column" selector in preferences no longer control anything? 
I.e., that they should be removed and just leave "Default column width"?  I
guess I'm just wondering if with this change and those to come it really
matters if there is a autofit selection in the preferences.  If the autofit is
now fast, why not just always run autofit when opening the variable in the
V.E. tab.

"But it would be nice to have a button to force resizing to happen. It can
matter because if the data switches from 1.23456 to 1.2345e+22, something
usually ends up cut off."

Several of us mentioned buttons on the header or right-mouse-click to activate
the search feature.  None of that has been done and that needs to be added. 
Should we add Torsten to the list since he's generally the one who oversees
GUI mods?

Now, as to the autofit behavior, the one thing we have right now is the
double-click to autofit feature that Philip mentioned.  I use that, and the
autofit doesn't seem quite right.  As an example, do

x = zeros(50);
openvar x;

There is a great deal of whitespace to the left of the zero when there could
be more columns autofit in the view.  Also, if I shrink the width of column 1,
say, down to nearly nothing and double-click the line between column 1 and 2,
the autofit occurs and goes back to that large-pre-whitespace width.  If I
expand the first column so there is a large amount of white space after the
zero and double-click the line the the column goes back to the original
autofit size.  So it seems that there is more pre-whitespace than necessary or
some type of minimum limit on the column width.  Is this happening because the
code attempts to align the numbers, i.e., its format is 10 character width
numbers so that is somehow the minimum allowable size?

"It would be nice if more than one tab could be visible at once. That way you
could easily watch multiple variables while debugging. Super killer feature!
Is that possible with the Qt tab widget?"

Certainly, one could derive an object and hand-roll such a thing, but it might
already exist.  There could be multiple docking, which is sort of like having
multiple V.E.s (i.e., each table gets its own toolbar with
copy-paste-print-etc.) but I don't know if that's desired because it would
clutter the space too much with all kinds of windows.

However, there looks to be something very close to having multiple tables
contained in a single window and just one toolbar in the window.  Go to the
main window and open something in the editor and there will be tabs at the
bottom "Command Line", "Editor", and possible some other tabs.  In addition to
switching between tabs, one can grab/drag the sub window and it becomes
undocked and floats until situating it somewhere within the main window.  In
other words, what was tabs to switch between now becomes two subwindows
viewable at one.  I would think such a thing could be done with the V.E.,
i.e., the tabulated view could be changed to having multiple tables visible at
the same time.

Keep in mind there would only be one variable editor toolbar, so there needs
to be some way of indicating what table the toolbar actions will act on.  I'd
think that making the "active" table have a white background and grey out all
the other tables would be good.  If one clicks in an inactive table, that
table's background would become white, etc.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53005>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/