Last call before deprecating the nested_splitter plugin

[Edward K. Ream]

Imo, PR #3911 is ready to be merged into devel.

Please let me know if you disagree.

Edward

[Thomas Passin]

I think one thing is missing.  I'd like to have a command to place the log frame into its own panel next to the body editor's.  This layout has the tree pane vertically on the left, the body in the middle, and the log frame on the right.  I'm sure I could come up with a script to do this, but I think there should be a Leo command for it.  The reason is that there are times when you want to see many lines in the log frame.  It could be a stack trace, the output of key bindings, or an app like my bookmark app or RPCalc, that opens in the log frame.  And when VR/VR3 gets opened sharing the log frame panel the height crunch gets even worse.

So there should be three built-in layouts instead of two, and there should be a command or commands similar to toggle-split-direction to activate any of them.

I also don't like the name "secondary_splitter".  I have no way to know which is "primary" and which is "secondary", and I don't see why I should have to or what the distinction is.  Better splitter names would be a good thing (sorry I don't have any suggestions yet, but I don't understand the distinction so I can't offer any!).

[Edward K. Ream]

On Wed, May 22, 2024 at 5:50 PM Thomas Passin <tbp1...@gmail.com> wrote:

I'd like to have a command to place the log frame into its own panel next to the body editor's.

...

So there should be three built-in layouts instead of two, and there should be a command or commands similar to toggle-split-direction to activate any of them.

Such enhancements would be a separate issue. They might affect VR and VR3, but we can deal with that later.

I also don't like the name "secondary_splitter".

The main splitter contains the secondary splitter. See the code for details. I don't think any other name will be much better.

Qt object names are for debugging and as targets for qt_gui.find_widget_by_name. Changing the names would be yet another breaking change. I don't want to go there.

Edward

[Thomas Passin]

Is it correct that the "main" splitter is the one whose splitter bar runs all the way either from top to bottom or from side to side, depending on orientation?

[Edward K. Ream]

On Thu, May 23, 2024 at 7:00 AM Thomas Passin <tbp1...@gmail.com> wrote:

Is it correct that the "main" splitter is the one whose splitter bar runs all the way either from top to bottom or from side to side, depending on orientation?

Yes, kinda. But you shouldn't take my word for it. Consult the code!

Search for 'main_splitter'. Find dw.createMainLayout.

The answer to your question are these lines:

main_splitter = QtWidgets.QSplitter(parent)
main_splitter.setOrientation(Orientation.Vertical)
secondary_splitter = QtWidgets.QSplitter(main_splitter)

What's the parent?  cff createMainLayout. The caller is dw.createMainWindow. The parent is dw.centralwidget.

main_splitter, secondary_splitter = self.createMainLayout(self.centralwidget)

Consult the rest of dw.createMainWindow for further details.

Thomas, you will learn a lot by answering your own questions. You can do it!

Edward

[Thomas Passin]

Speaking of which, the free layout controller still has this method:

def get_top_splitter(self) -> Optional[Wrapper]:
    """Return the top splitter of c.frame.top."""
    f = self.c.frame
    if hasattr(f, 'top') and f.top:
        child = f.top.findChild(NestedSplitter)  <================
        return child and child.top()
    return None

This method is used by the richtext plugin as well as the flc itself.

qt_gui also has a method by this name but it has been updated to return the 'main_splitter'.

[Edward K. Ream]

On Thu, May 23, 2024 at 10:39 AM Thomas Passin <tbp1...@gmail.com> wrote:

[The free_layout.get_top_splitter] method is used by the richtext plugin as well as the flc itself.

Good catch. I'll convert the richtext plugin.

Edward

[Edward K. Ream]

On Thursday, May 23, 2024 at 2:16:00 PM UTC-5 Edward K. Ream wrote:

On Thu, May 23, 2024 at 10:39 AM Thomas wrote:

[The free_layout.get_top_splitter] method is used by the richtext plugin as well as the flc itself.

Good catch. I'll convert the richtext plugin.

Where is this plugin? An external search for *text.py finds three files, none of which looks like richtext.py.

Edward

[jkn]

jkn@tower:~/leo-editor$ find . -iname "*rich*"
./leo/plugins/richtext.py

on my system...

[Edward K. Ream]

On Fri, May 24, 2024 at 5:59 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

jkn@tower:~/leo-editor$ find . -iname "*rich*"
./leo/plugins/richtext.py

How strange.  Please send me the file.

Edward

[jkn]

sent via email

[Edward K. Ream]

On Friday, May 24, 2024 at 6:29:43 AM UTC-5 Edward K. Ream wrote:

On Fri, May 24, 2024 at 5:59 AM jkn wrote:

jkn@tower:~/leo-editor$ find . -iname "*rich*"
./leo/plugins/richtext.py

How strange.  Please send me the file.

Mystery partly solved.

gitk reports that I deleted that file at rev cf89a85 on March 23 of this year.

I probably deleted the file because it won't work with Qt6. The plugin uses QtWebKit.

On March 25 the GitHub version of Leo started requiring PyQt6, so nobody has used this plugin with the GitHub version of Leo.

#3930 suggests reinstating and porting the plugin so it works on Qt6.

I shall reinstate plugin, but I am not willing to fix it. Does anyone want to volunteer?

Edward

[Edward K. Ream]

On Friday, May 24, 2024 at 10:49:59 AM UTC-5 Edward K. Ream wrote:

> I shall reinstate plugin, but I am not willing to fix it.

Rev 0d2a7c4 in devel reinstates the plugin itself.

#3931 will help create an @file node for it in leoPyRef.leo.

Edward

[Thomas Passin]

I looked at this a bit.  It swaps in an instance of the CKEditor for the Leo body editor.  CKEditor is a commercial product whose most basic level is under the GPL2 license, and so can be used at no charge.  It's written in javascript and runs in a browser.  It's a WYSIWYG )(rich text) editor.  The plugin loads the Qt browser QWidget, loads the CKEditor code, and you can edit your node in full WYSIWYG glory.

The plugin should be pretty easy to get working again, and it does not use the nested splitter. One thing to know.  It depends on an HTML template file to load the CKEditor and the body content into the Qt widget.  That template file exists in Leo's plugins directory but it's not in LeoPyRef.leo.  It's named cke_template.html.

Using the CK Editor, if you edit a node with it, when you save the node will become a rich text HTML file (depending on how you save it).  It won't be an ordinary text node any more.  You would have to view it using the CK Editor mode - or I *think* that VR3 would render it but this is not tested.

No, I'm not volunteering to get this thing working either.  But it wouldn't take much, I think.

[Edward K. Ream]

On Fri, May 24, 2024 at 5:03 PM Thomas Passin <tbp1...@gmail.com> wrote:

The plugin should be pretty easy to get working again, and it does not use the nested splitter. One thing to know.  It depends on an HTML template file to load the CKEditor and the body content into the Qt widget.  That template file exists in Leo's plugins directory but it's not in LeoPyRef.leo.  It's named cke_template.html.

Good to know. I'll try to remember not to delete it, hehe.

No, I'm not volunteering to get this thing working either.  But it wouldn't take much, I think.

Thanks for your investigations. Long term, #3931 justifies all the recent confusion. I'm working on it.

Edward