Qt docking as a replacement for NestedSplitter "Easteregg" menu.

[Terry Brown]

https://github.com/leo-editor/snippets/blob/master/examples/layout/qtdock.py

is a Py 2.7 / Qt 4 demo of Qt docking as it might apply to Leo, with comments

in the doc. string.  I think it's definitely worth switching to this, so now it's

simply a matter of finding time :-)

Cheers -Terry

[rengel]

+1
It is worth the while to take a look at Qt Designer. This program is an excellent example for using dock windows.

Reinhard

 

[Edward K. Ream]

​The demo is impressive.  A lot of results with not much code.  I'll look forward to future progress.

EKR

[Offray Vladimir Luna Cárdenas]

Thanks for your continuous work Edward. I think that for this kind of explorations in the GUI front, a small screenshot would complete the argumentation.

Cheers,

Offray

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Fri, Sep 30, 2016 at 10:45 AM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

Thanks for your continuous work Edward. I think that for this kind of explorations in the GUI front, a small screenshot would complete the argumentation.

​Here it is.

EKR

[Offray Vladimir Luna Cárdenas]

Yes, it looks a lot better :-).

Cheers,

Offray

[Terry Brown]

I should push it to my personal Leo fork, but I have a hacked up
version which opens the three main widgets in docks, with free_layout
disabled. Need to work out exactly what to do with the Minibuffer,
currently it's the central widget (a major promotion :-) but that
introduces an unnecessary splitter handle.

Anyway, Edward, the question is, try doing this as an alternate
interface that can be selected via settings, or just tear out a lot of
the old interface code and use docks...

Never mind, it hadn't really occurred to me, until just now, to just let
both code bases sit side by side with some global switch, despite the
number of times you've demonstrated that approach - I'll do that :-)

Cheers -Terry

[Edward K. Ream]

On Sat, Oct 1, 2016 at 12:07 PM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

Never mind, it hadn't really occurred to me, until just now, to just let
both code bases sit side by side with some global switch, despite the
number of times you've demonstrated that approach - I'll do that :-)

​Yes, and I'm doing that with mod_http as we speak.

EKR

[Terry Brown]

I've been working on this, still not clear quite how big a task it will be, but I think quite significant. I actually have a version which works, opening all the tabs (Log, Find, etc.) in a tabbed dock etc., but I'm sure it would break a bunch of unit tests etc., and plugins.  Things like Ctrl-F in body selecting the Find widget work quite easily.

But I'm not sure if I want to proceed from that version, which inherits a confounding between the log widget and the tab pane, or try and clean up the UI start up a bit.  For very reasonable hysterical raisins(*) the separation between the *log* widget, where logging output goes, and the tabbed pane that holds the log, find, spell, nav etc. is unclear.  .createTab() is a method of the log class, and I keep running into the circularity of wanting to create a tab to put the log and other tools in, but until you've created the log you can't create a tab... obviously the current system works, with finishCreate() style methods, but I'm not sure if I want to add to the many levels present, or try something else.

I also need to research more how QMainWindow .save/restoreState() works. It creates an opaque type, and the naive approach of calling save, moving a splitter, then calling restore with the output from the save call does not work.  Presumably something needs to be done with the restoreDockWidget method.

Although I'll persist for now with the `if g.qtdock:` approach to develop new code alongside old, if this project is successful I think a lot of old code will be able to be stripped out - cross that bridge if / when we get to it.

(*) historical reasons, but hysterical raisins is much funnier :-)

Cheers -Terry

---

From: Edward K. Ream <edre...@gmail.com>
To: leo-editor <leo-e...@googlegroups.com>
Sent: Friday, September 30, 2016 6:15 AM
Subject: Re: Qt docking as a replacement for NestedSplitter "Easteregg" menu.

[Edward K. Ream]

On Tue, Oct 11, 2016 at 9:21 AM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

I've been working on this, still not clear quite how big a task it will be, but I think quite significant. I actually have a version which works, opening all the tabs (Log, Find, etc.) in a tabbed dock etc., but I'm sure it would break a bunch of unit tests etc., and plugins.

​There should be nothing to worry about as long as all the work can be enabled/disabled by a single switch.  If the work spans several files, you should put the switch in leoGlobals.py.

Once that is done, failing unit tests can give helpful information.

Any, I trust your judgement about this.  Fire away ;-)

Edward