Re: Status report re PR #3911

[Thomas Passin]

For commands that I think I might use often enough, I add them to my 
"Local" menu, which I define in myLeoSettings.leo.  It's a handy way to 
deal with those things that don't rate a button or keyboard shortcut but 
that I want to remember.

On Sunday, May 26, 2024 at 1:48:17 PM UTC-4 Edward K. Ream wrote:

> On Sun, May 26, 2024 at 8:06 AM HaveF HaveF  wrote:
>
>> Thanks Edward and Thomas.
>>
>> Btw, do we need to put Leo's Qt Widget hierarchy Code 
>>  to 
>> the doc? I believe it is very useful.
>>
>
> The 6.8.0 docs will mention the show-qt-widgets command. That should 
> suffice.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/73d0db0d-33d8-4401-9988-37f3e523cfbfn%40googlegroups.com.

Re: ENB: Ahas re finding definitions

[Thomas Passin]

D'accord.

On Sunday, May 26, 2024 at 1:51:56 PM UTC-4 Edward K. Ream wrote:

> On Sunday, May 26, 2024 at 12:42:11 PM UTC-5 Edward K. Ream wrote:
>
> > I don't like returning the results as cloned nodes...The Nav tab is 
> better.
>
> I'm going to do the following:
>
> - Use the Nav tab If the quicksearch plugin is active.
> - Otherwise use clones.
>
> That should make most people happy without the need for more settings or 
> commands.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/201f71e4-47c2-4c8e-8f50-f7ab5d0bf00bn%40googlegroups.com.

Re: ENB: Ahas re finding definitions

[Thomas Passin]

I don't like returning the results as cloned nodes.  That changes the 
outline, and a search should not do that.  The search will change the focus 
to the new cloned results, which is distracting and unexpected. And later 
the user has to remember to find and delete those clones without 
accidentally deleting something that should remain.

The format used by the Nav tab is ideal (and highly readable, better than 
cloning nodes) and that's what I would greatly prefer.  No need for a new 
setting and setting-toggle command, no need to step from one instance to 
the next or back, no need to insert any new nodes.   Perfect.

On Sunday, May 26, 2024 at 7:10:16 AM UTC-4 Edward K. Ream wrote:

> On Sunday, May 26, 2024 at 6:02:37 AM UTC-5 Edward K. Ream wrote:
>
> > *Aha 3*: Let the top-level results node (of either type) tell the user 
> about the new setting and the command to change it.
>
> On second thought, delivering multiple results as cloned nodes (as in the 
> the clone-find command) should suffice. The find-all command delivers 
> results in a less permanent and less pleasant format.
>
> Using a single results format eliminates the need for new settings or 
> commands. If somebody thinks differently, they can always create a PR :-)
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/f0048914-7c83-4776-a8a0-a831fafe9024n%40googlegroups.com.

Re: Status report re PR #3911

[Thomas Passin]

That seems fine.  It can be done a little easier with the new method  
find_widget_by_name():

from leo.core.leoQt import QtWidgets
QSplitter, QTextEdit = QtWidgets.QSplitter, QtWidgets.QTextEdit

gui = g.app.gui
w = gui.find_widget_by_name(c, '*main_splitte*r')
something_log = w.findChild(QTextEdit, "something_log")
if something_log == None:
something_log = QtWidgets.QTextEdit()
something_log.setObjectName('something_log')
w.addWidget(something_log)

If you ever want to delete your added widget, remember to call 
deleteLater() on it as the last thing.  This will cause Qt to delete the 
underlying C++ widget.  Otherwise only the Python widget wrapper will get 
deleted.
On Sunday, May 26, 2024 at 5:17:22 AM UTC-4 iamap...@gmail.com wrote:

> I haven't kept up with the latest progress. In my previous code, I created 
> a textedit panel to output something.
>
> ```python
>  w = c.frame.body.widget
>  while not isinstance(w, NestedSplitter):
>  w = w.parent()
>  something_log = w.find_child(QtWidgets.QTextEdit, "something_log")
>  if something_log == None:
>  self.something_log = QtWidgets.QTextEdit()
>  self.something_log.setObjectName('something_log')
>  w.insert(-1, self.something_log)
> ```
> Regarding the recent changes, I try to fix it.
>
> ```python
> w = c.frame.body.widget
> while not isinstance(w, QSplitter):
> w = w.parent()
> something_log = w.findChild(QtWidgets.QTextEdit, "something_log")
> if something_log == None:
> self.something_log = QtWidgets.QTextEdit()
> self.something_log.setObjectName('something_log')
> w.addWidget(self.something_log)
> ```
>
> It works. But I'm not sure, is there anything else I need to pay attention 
> to? The original code maybe copy from Thomas, I don't remember :D I don’t 
> have the guts to study layout yet
>
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/adb1a981-427b-4af1-814d-4358e6a86f8dn%40googlegroups.com.

Re: Modified headline query

[Thomas Passin]

I think you need to mark the node as dirty - p.setDirty() - and also 
c.setChanged().  I'm not sure why the first doesn't also set the second, 
but it doesn't.

You might also want to save undo data.  Here's an example where I write 
text into the body and make it undoable.  The outline asks if I want to 
save before closing.  

p, u, = c.p, c.undoer
bunch = u.beforeChangeBody(p)

title = p.h
title += '\n' + '-'*(len(title) + 1)
time_string = ':created: ' + c.getTime(body=True) + '\n'

zettel_str = f'{title}\n\n:id: {p.gnx}\n{time_string}\n'

w = c.frame.body.wrapper
w.setInsertPoint(0)

p.b = zettel_str + p.b
u.afterChangeBody(p, 'zettel-convert-card', bunch)

For undoing a headline change, you could use u.beforeChangeHeadline() / 
u.afterChangeHeadline() instead. I haven't tried this to change a headline 
but I presume the node and outline would also show as changed.
On Friday, May 24, 2024 at 7:37:42 PM UTC-4 lewis wrote:

> I wrote a script to add a datestamp to the top node of a file. It modifies 
> the headline and the headline icon changes to show it has changed.
> However when I close the leo file there is no prompt to save the file and 
> the update is lost.
>
> I'm obviously missing some important detail and look forward to a helpful 
> explanation of why the file is not recognised as changed.
> Here is the script:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *@language pythonfrom datetime import datetimenow = 
> datetime.now()TIME_STAMP = (f"{now.day}/{now.month}/{now.year} 
> {now.hour}:{now.minute}:{now.second}")def datestamp_node():# POSITION  
>   c.selectPosition(c.rootPosition())  # select root node position and move 
> to it# MOVES TO FIRST NODEp = c.p# NODE headlinep.h 
> = "datestamp Leo" + " " + TIME_STAMP  # timestamp "datestamp Leo" node
> c.setHeadString(p, p.h)  # write the new headline.g.es_print(f"   
> new headline is: ", p.h)c.redraw(p)datestamp_node()*
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/08221d9f-6dd7-4d00-8e19-8ddcb43a76adn%40googlegroups.com.

Re: Last call before deprecating the nested_splitter plugin

[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.

On Friday, May 24, 2024 at 12:00:49 PM UTC-4 Edward K. Ream wrote:

> 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
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c0912f49-a381-4a70-a6e0-700c94331d55n%40googlegroups.com.

Re: Last call before deprecating the nested_splitter plugin

[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'.
On Thursday, May 23, 2024 at 10:52:37 AM UTC-4 Edward K. Ream wrote:

> On Thu, May 23, 2024 at 7:00 AM Thomas Passin  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
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c5ecfcf9-37ad-48c2-8aa4-ca25dbf5aa14n%40googlegroups.com.

Re: Last call before deprecating the nested_splitter plugin

[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?

On Thursday, May 23, 2024 at 5:10:32 AM UTC-4 Edward K. Ream wrote:

> On Wed, May 22, 2024 at 5:50 PM Thomas Passin  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
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a1298cd5-4eba-4ad9-a568-505092b04cden%40googlegroups.com.

Re: The nested-splitter project has collapsed in complexity

[Thomas Passin]

On Tuesday, May 21, 2024 at 3:36:03 PM UTC-4 Thomas Passin wrote:

VR3 is working with  *ekr-3910-no-fl-ns-plugins*, possible quirks aside.  
Will check soon on Linux.  Freewin is working. RPCalc is still working.


OK on linux so far. 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6b60ab6c-8009-42c8-9f8e-2cd2454469b0n%40googlegroups.com.

Re: Last call before deprecating the nested_splitter plugin

[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!).

On Wednesday, May 22, 2024 at 5:04:20 PM UTC-4 Edward K. Ream wrote:

> Imo, PR #3911  is 
> ready to be merged into devel.
>
> Please let me know if you disagree.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/49e4a351-a293-448a-993c-c2a843a1a025n%40googlegroups.com.

Re: The improved restart-leo command

[Thomas Passin]

What directory are you running the tests from? Unless you set the right one 
using PYTHONPATH, you have to be in the *leo-editor*   directory to be able 
to find *leo.core.xxx*, etc.

On Wednesday, May 22, 2024 at 1:52:35 PM UTC-4 Edward K. Ream wrote:

> PR #3922  significantly 
>> improves Leo's restart-leo command. The command now uses the command-line 
>> arguments in effect when Leo started.
>>
>> I have tested the latest version of Leo's devel branch in a dedicated 
>> Debian & Fedora VM.
>>
>> The command is working fine in both !
>>
>
> Thanks for your testing.
>
> However & FYI: When I run Leo's unit tests in both VMs I receive 43 
>> identical / similar errors:
>>
> [snip] 
>
>>   File 
>> "/home/user/PyVE/GitHub/Leo/leo-editor/leo/external/npyscreen/wgwidget.py", 
>> line 21, in 
>> from leo.core import leoGlobals as g
>> ModuleNotFoundError: No module named 'leo'
>>
>
> This looks like an installation problem.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0e620cce-8dba-4ad2-9b48-a2397bdb0490n%40googlegroups.com.

Re: The nested-splitter project has collapsed in complexity

[Thomas Passin]

On Tuesday, May 21, 2024 at 3:36:03 PM UTC-4 Thomas Passin wrote:

VR3 is working with  *ekr-3910-no-fl-ns-plugins*, possible quirks aside.  
Will check soon on Linux.  Freewin is working. RPCalc is still working.


The new layout *in-body* does put VR3 in a new panel next to the body 
editor.  But that whole frame is squashed all the way over to the right so 
it's not visible.  You have to notice the splitter separator and drag it to 
pull the body.VR3 frame into visibility.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3767a2fb-cfc9-415a-bef0-38ef75e3ecd5n%40googlegroups.com.

Re: The next version of Leo will be 6.8.0

[Thomas Passin]

On Tuesday, May 21, 2024 at 3:20:34 PM UTC-4 Edward K. Ream wrote:

The new version number indicates (per the semantic versioning 
 convention) that the next version of Leo will contain 
*breaking 
changes* that might significantly impact existing scripts and plugins.

Three issues could break existing code:

- #3910 : Deprecate 
free_layout and nested_splitter plugins. This issue is potentially a 
wide-ranging change.

- #3915 : Use slots 
for most of Leo's classes. This issue affects only scripts that inject 
ivars into Leo's classes. The workarounds are straightforward.

As long as we continue to have commander-specific and global user 
dictionaries, it shouldn't be much of a problem. I have sometimes added 
functions directly to c or g so certain variables or functions would 
persist past invocation.  With stable user dictionaries I could use them 
just as well.  

-- #3925 : Make 
reload-settings/stylesheets be synonyms for restart-leo. This issue should 
have minimal practical impact.

Actually, I don't agree with this one about reload-settings, at least for 
outline-local settings.  I have often changed a setting in one outline and 
reloaded settings to see the effect.  Restarting Leo each time would be a 
nuisance and would slow the development of the changes.  Globally, changing 
menus and then resetting doesn't work anyway, at least not for 
currently-open outlines, and reloading the stylesheets has been a little 
weird so I wouldn't miss that command, I think.

*Summary*

None of these issues is complete, but I expect all three to be part of Leo 
6.8.0.

All of your questions and comments are welcome. Expect 6.8.0 sometime this 
summer.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2e6a936b-ad8c-43b4-b60e-c83d2d9ef97fn%40googlegroups.com.

Re: The nested-splitter project has collapsed in complexity

[Thomas Passin]

VR3 is working with  *ekr-3910-no-fl-ns-plugins*, possible quirks aside.  
Will check soon on Linux.  Freewin is working. RPCalc is still working.

Did you by any chance bind the *vr3* command to a key shortcut? W11 might 
be using that shortcut itself by default.

On Tuesday, May 21, 2024 at 3:02:21 PM UTC-4 Edward K. Ream wrote:

On Tue, May 21, 2024 at 1:04 PM Thomas Passin wrote:

>> Thomas, please test the ekr-3910-no-fl-ns-plugins branch and report if 
you notice anything unusual with the `vr3` command.  Thanks.

> I'm about to do that very thing.  I don't have Windows 11, only Windows 
10, and I will be resisting W11 as long as possible.  So I may not be able 
to work on that particular quirk. 

Excellent. Every bit of testing helps.

Again, feel free to change my new code in any way you like.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5292ce0d-21e4-4208-8ab5-e70ce0f79e94n%40googlegroups.com.

Re: The nested-splitter project has collapsed in complexity

[Thomas Passin]

On Tuesday, May 21, 2024 at 1:10:16 PM UTC-4 Edward K. Ream wrote:


If you mean merging my private branch (PR #3924) with  your 
*ekr-3910-no-fl-ns-plugins* branch, please go ahead right away.  

Done.

Before and after the merge,  the `vr3` command works as I expect, but it 
also causes a weird interaction with Windows 11. I get a message saying 
"Press Alt-Z to use GeForce experience"!! I have no idea what is going on.

Thomas, please test the ekr-3910-no-fl-ns-plugins branch and report if you 
notice anything unusual with the `vr3` command.  Thanks.


I'm about to do that very thing.  I don't have Windows 11, only Windows 10, 
and I will be resisting W11 as long as possible.  So I may not be able to 
work on that particular quirk. 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/18600d07-c4d4-46ff-8a34-6ef6ab319103n%40googlegroups.com.

Re: The nested-splitter project has collapsed in complexity

[Thomas Passin]

On Tuesday, May 21, 2024 at 7:46:15 AM UTC-4 Edward K. Ream wrote:

On Mon, May 20, 2024 at 10:13 PM Thomas Passin  wrote:

Is your experimental version of VR3 using the free_layout command?


Not any more.
 

Are you good with me merging the PR today?


If you mean merging my private branch (PR #3924) with  your 
*ekr-3910-no-fl-ns-plugins* branch, please go ahead right away.  The reason 
is that it contains code to display images with relative URLs correctly 
when the rendering is exported. I developed that code in a branch that is 
based off of *devel* - before the new layout code. My new PR includes both 
that work and my recent work using the new free-layout free code. If you 
merge your branch into *devel* before merging my PR, I will have to do all 
that work over again, and it was not easy.

If you mean merging with *devel*,  I'm less sure. Without my changes, I 
don't think VR3 will be very useful and I believe that there are a few 
day-to-day users out there.

How about if we take a little survey in this group and ask who is using 
which GUI plugins?  That might give us some guidance before the change to 
the new way.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/fdff4a42-51a5-4a75-bd04-bad6b62b09b8n%40googlegroups.com.

Re: The nested-splitter project has collapsed in complexity

[Thomas Passin]

On Monday, May 20, 2024 at 5:31:52 PM UTC-4 Edward K. Ream wrote:

On Mon, May 20, 2024 at 10:20 AM Thomas Passin  wrote:

Imo, there is *no way* to have the free_layout and nested_splitter plugins 
coexist with the PR. I am considering moving those two plugins to the attic.


I wouldn't go that far.  My script tries to use the free_layout method to 
find the right widget to insert VR3 into, and that raises an exception it 
uses the new method instead.  One could easily move the script into the 
plugin itself as a command. So I think they could coexist - with some 
rewriting, of course.


I'm willing to leave the two plugins where they are, untouched.

However, I don't think you (or anyone else) will be able to use them 
reliably. In the PR, *dw.createMainLayout* creates the main and secondary 
splitters as QSplitters, not NestedSplitters. This change is essential. 
Otherwise the free_layout plugin is *privileged*, that is, baked into Leo.


To the contrary, in my private branch based on the 
*ekr-3910-no-fl-ns-plugins* branch, I have got VR3 so it can:

1. For a vr3-open or vr3-toggle command, it opens below the log frame, 
which is the new behavior you set up;
2. I can toggle it on and off in its own tab in the log frame;
3. My script to put into the body editor's stacked widget and toggle 
between the body pane and VR3 works.  The script could be added to the VR3 
code although I haven't done that yet.

What I don't know yet, with the new layout scheme, is how to open a third 
pane and put VR3 into that the way it did originally - or moving the log 
frame (with VR3 in its own tab there) to a third panel.  Having it share 
vertical height with the log pane is not ideal because you can't see enough 
of the rendered view.  Having it in a tab in the log frame is better, but 
the display switches away from VR3 to the log tab whenever there is output 
to the log.  That's not ideal either, though it's not as bad.

I have been learning that toggling between the body editor and the VR3 
rendered view is usually the most useful way to use it.

There is probably a lot of cleanup to be done with all the changes - 
especially for a different layout.  I don't know how to set a different 
layout yet so I haven't tested that.

The RPCalc plugin toggles on and off in the log frame with no changes.

Anyway, I'm optimistic about VR3 and similar plugins continuing to work 
with minimal changes in the new layout regime.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c08dafbe-6873-42f4-8698-ea81dcf77762n%40googlegroups.com.

Re: The nested-splitter project has collapsed in complexity

[Thomas Passin]

On Monday, May 20, 2024 at 10:39:14 AM UTC-4 Edward K. Ream wrote:

Imo, there is *no way* to have the free_layout and nested_splitter plugins 
coexist with the PR. I am considering moving those two plugins to the attic.


I wouldn't go that far.  My script tries to use the free_layout method to 
find the right widget to insert VR3 into, and that raises an exception it 
uses the new method instead.  One could easily move the script into the 
plugin itself as a command. So I think they could coexist - with some 
rewriting, of course.

This works when the plugin is not enabled in the settings.  So it never 
uses the "provider" mechanism and never gets registered with the nested 
splitter machinery (which doesn't exist in the new approach, of course). 

The question is, then, what will count as a plugin without the provider 
infrastructure?  We certainly want people to be able to write code and have 
it work with Leo, and some existing plugins aren't GUI-related and don't 
use the nested splitter code anyway.  It seems we have to rethink the idea 
of a GUI plugin and how it should work.

We shouldn't send the plugins to the attic, because people are using them.  
Let's find another way.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/cd4358d8-81d0-4662-8901-f2cd64d5c8bdn%40googlegroups.com.

Re: The nested-splitter project has collapsed in complexity

[Thomas Passin]

This is all looking good.  The command *gui.find_widget_by_name *is 
especially valuable.  Without it one has to spend a lot of annoying time 
fishing around through parent and child widgets to find the one you want.  
You also need a way to find the name of the widget you want, which could be 
hard to find. The new *show-qt-widgets*  helps a lot here. I think there 
may be room for another way to show the names, but for now this command 
does the job.

I already have my script to toggle VR3 over the body editor working with 
both the new and old layouts.

On Monday, May 20, 2024 at 7:53:39 AM UTC-4 Edward K. Ream wrote:

> PR #3911  eliminates 
> the free_layout and nested splitter plugins. This work has reached a 
> milestone.
>
> A single method, *LeoQtGui.find_widget_by_name*, replaces both plugins!
>
> The node *g.command('vr')* shows the *new world order*. See the PR. This 
> node adds the VR pane to either the body pane or the secondary splitter, 
> depending on the setting *@string initial-split-orientation*.
>
> Yes, this new code is longer and more complex. Faux helpers typically make 
> the code *look* simpler. But the new code is *much* better. The new code:
>
> - can do anything that Qt can do.
> - does not use the cache.
> - is platform-independent.
> - is a model for @button nodes and plugins.
> - is more specific and explicit.
>
> The old code obscured a design choice. Should the VR pane *always* share 
> the body pane? I think not. When using the horizontal orientation, the VR 
> pane should appear on the left side of the screen. In other words, the 
> secondary splitter should contain the VR pane.
>
> Similar code could insert any Qt widget anywhere, say a QStackedLayout 
> widget. There is nothing special about QSplitters!
>
> *Conversion and documentation*
>
> How did I know where the body frame was? Leo's new *show-qt-widgets* command 
> showed me the hierarchy of widgets.
>
> I also studied the way-too-complex code in *ns.add_adjacent*. I *don't* 
> expect 
> others to redo my study. Documenting the new world order is essential. A 
> new info item will contain tips and examples.
>
> The VR3 plugin can follow this general pattern. A new setting, say *@string 
> vr3-initial-layout*, could contain two (*or more!*) strings that tell 
> *g.command('vr3')* which layout to use. Nothing could be more 
> straightforward. Notice: VR3 never executes a user script. The setting 
> just selects one of several *static* alternatives.
>
> *Summary*
>
> One new method, *LeoQtGui.find_widget_by_name*, can replace the 
> free_layout and nested_splitter plugins! These plugins are faux helpers. 
> They *limit *what users can do. 
>
> The PR demonstrates how the VR3 plugin could support arbitrarily many 
> layouts. Just add a new setting. Each outline can choose whatever layout it 
> wants!
>
> Documenting the new world order is essential. A new info item will contain 
> tips and examples.
>
> More work is coming. Stay tuned.
>
> All your comments and questions are welcome.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/eb07d269-4f16-4ec4-8b01-9d3bca6cc023n%40googlegroups.com.

Re: A Script To Display The Viewrendered3 Pane in the Same Place s The Body

[Thomas Passin]

Here is a revised version of my script to show the viewrendered3 plugin in 
the same pane as the body editor.  The command toggles between the VR3 
rendered view and the body editor view.  I have it connected to a button on 
the button bar.  You can use it without even enabling the plugin in your 
settings file.

@language python
"""Toggles the body frame between the body editor and
a Viewrendered3 rendered view.
"""
from leo.core.leoQt import QtWidgets
import leo.plugins.viewrendered3 as v3

def toggle_vr3_in_body(c):
flc = c.free_layout  # free layout controller
top = flc.get_top_splitter()
if top:
bfw = top.find_child(QtWidgets.QWidget, "bodyFrame")
kids = bfw.children()

qf0 = kids[0]
stacked_layout = qf0.children()[0]
h = c.hash()
if stacked_layout.count() == 1:
v3.controllers[h] = vr3 = v3.ViewRenderedController3(c)
stacked_layout.addWidget(vr3)

if stacked_layout.currentIndex() == 0:
# vr3 = v3.controllers[h]
# stacked_layout.setCurrentWidget(vr3)
vr3 = stacked_layout.widget(1)
stacked_layout.setCurrentIndex(1)
vr3.set_unfreeze()
else:
vr3 = stacked_layout.widget(1)
vr3.set_freeze()
stacked_layout.setCurrentIndex(0)

toggle_vr3_in_body(c)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5b8886b9-bd10-405c-8ef6-d22af41d648en%40googlegroups.com.

Re: glitches installing and starting Leo

[Thomas Passin]

On Thursday, May 16, 2024 at 11:04:15 PM UTC-4 andyjim wrote:

one more question and I'll try to leave you alone:
I use Bike, an outlining editor. The file extension is .bike
Can I represent an external Bike file in a Leo outline and from that Leo 
outline can I open the external file in the Bike application? 

 
I don't know anything about a Bile file.  In general, if you can run Bike 
and get it to pen a file from the command line, we can easily issue that 
command from within Leo.  I see that a Bike outline is an html file. I 
don't know where they keep their images, etc, but it's not hard to display 
an html file in Leo.  Editing it is something else, though. I see that Bike 
also has an OPML format too.  OPML is a XML file but has a bad design for 
interchanging anything complicated.  In theory, an XSLT transformation 
could be written to convert it into a Leo file.  It's been so long since I 
worked on XSLT transformations (about 20 years) that I'm awfully rusty. 
There's also said to be a text format for Bike but I don't know anything 
about that.

So the answer might be that it can probably be done, but you might not be 
able to do the kind of editing of rich text that you can apparently do in 
Bike.  OTOH, Leo could be made to use a rich text editor instead of the 
plain text-based one it normally uses.  There's at least one plugin that 
does that, though I don't know if it still works.

Anyway, the answer to the question of representing an external Bike file in 
Leo is "probably yes, depending on what you want to do with it in Leo".

Reading a little more (Bike: An Elegant Outliner For Mac-Focused Workflows 
),
 
it looks like it's an elegant riff off of Dave Winer's MORE outliner.  
Surprise, so is Leo!  Dave strikes again.  And OPML is a data format from 
... Dave.  Or it could be more reminiscent of Radio Userland 
, another Dave Winer 
project.  Anyone else remember Radio Userland?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2c2d9547-e6c4-4627-81e1-b8045af83b3dn%40googlegroups.com.

Re: Status report re PR #3911

[Thomas Passin]

This will be complicated enough and have a potentially big impact on 
existing code and users that I'd like to see a concept of operations and 
some requirements.  For one thing, without something like them no one will 
be able to help you.  For another, no one will know how things should work 
nor how to write code for them.In addition, it's much easier to correct 
mistakes early, and if we can have some discussion about the goals and the 
design, the community could help.

Saying that you will "invert" Terry's code so the helpers are higher up or 
more visible is not very definite or specific.  I'd rather start with what 
Terry's code does that we like, and what about it we don't like.  For 
example, I found I can open VR3 on top of the body editor without using a  
nested splitter except to use it to find the stacked widget that contains 
the body editor.  I need free layout instance to get that splitter but not 
for anything else.  If I could directly get that stacked widget I would not 
have to talk to the free layout or a nested splitter at all.  So to me, it 
would be very desirable to have a method on c to return a container of a 
known object, and probably to enumerate those objects and containers, 
without having to know how to work my way through all the current layers of 
splitters and container widgets.  Notionally, something like this:

body_widget = c.getObject('bodyWrapper1')
container = body_widget.parent()
my_widget_index  = container.add(myWidget(c))
container.setIndex(my_widget_index)

The log frame works much like this.  Why can't all the container frames be 
more or less like the Log frame?

There are many Qt applications out there that have multiple panels and 
frames.  In some of them parts can be torn off and moved elsewhere.  New 
frames can be opened and populated. I don't suppose they all do it the same 
way, but there are probably some standard ways.  Pyzo is probably as good 
an exemplar as we could find.  Just how should the revised Leo interface 
work, from the point of view of users?  That would be a good place to start.

On Thursday, May 16, 2024 at 7:44:19 PM UTC-4 Edward K. Ream wrote:

> On Thursday, May 16, 2024 at 1:44:43 PM UTC-5 Edward K. Ream wrote:
>
> >> I hope that existing GUI plugins that use the 
> nested-splitter/free-layout will be able to continue working without 
> needing to be reworked
>
> > When True, the *g.allow_nested_splitter* switch enables both plugins to 
> work as before. As noted in the PR, this switch might be on "forever."
>
> Belay that. Leo's codebase should not contain toxic code switches. Such 
> switches are intolerable in the long run.
>
> I feel strongly enough about this that I am willing to convert legacy code 
> myself. This offer extends to you, Thomas, and anyone else.
>
> *Assuming the PR succeeds,* here is my present plan:
>
> - Terry's plugins (and the switch) will be part of Leo 6.7.9.
>
> - As part of 6.7.9, I'll convert all affected code in LeoPyRef.py.
>
> - The 6.7.9 release notes will warn of a breaking change in Leo 6.7.10 and 
> will offer to help with conversion.
>
> - I'll remove the switch and the two plugins as soon as 6.7.9 goes out the 
> door.
>
> *Summary*
>
> If PR #3911  succeeds, 
> Leo 6.7.9 will be the last release that supports the free_layout and 
> nested_splitter plugins.
>
> The 6.7.9 release notes will warn of the breaking change and will offer 
> to help convert any existing code.
>
> Leo's long history includes removing many overly complex features. 
> Removing all vestiges of these plugins will make Leo simpler and more 
> maintainable.
>
> Again, I welcome all comments.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6e0608b6-1b25-4142-84b8-105b58f9bc8bn%40googlegroups.com.

Re: Status report re PR #3911

[Thomas Passin]

I'm very enthusiastic about this work.  It will eventually be a real boon 
to users and developers, I'm sure.  I don't know if it will be possible, 
but I hope that existing GUI plugins that use the 
nested-splitter/free-layout will be able to continue working without 
needing to be reworked

On Thursday, May 16, 2024 at 10:39:55 AM UTC-4 Edward K. Ream wrote:

> PR #3911  contains 
> preliminary work on deprecating Terry's trailblazing free_layout and 
> nested_splitter plugins. This post is a progress report.
>
> *Goals*
>
> Scripts (@button nodes) and plugins should be able to do the following* 
> easily *and *intuitively:*
>
> - Detach Leo's screen components, thereby making them floating windows.
>
> - Move Leo's screen components to other locations.
>
> *Tools*
>
> Terry's plugins contain non-trivial low-level helpers that have served as 
> models for utilities in the PR. A higher-order *gui API* will support the 
> goals above.
>
> The gui API will use a *descriptor class* analogous to the caching code 
> in Terry's plugins. This class will output JSON descriptions of actions 
> that can persist between different runs of Leo.
>
> *Summary*
>
> This post discusses the PR's design. The PR:
>
> - turns Terry's innovative code inside out, exposing previously private 
> helpers.
>
> - creates a descriptive* gui API* that hides implementation details.
>
> All details are still in flux. All your questions and comments are welcome.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/60b68059-b5ff-40f4-8447-bf2e1e8b38ean%40googlegroups.com.

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

On Thursday, May 16, 2024 at 5:24:27 AM UTC-4 viktor@gmail.com wrote:

Hello Thomas,

tbp1...@gmail.com schrieb am Donnerstag, 16. Mai 2024 um 03:30:52 UTC+2:

The PR has been merged into the devel branch.  Update your clone repo and 
you should be good to go.

 
Thanks a lot, your PR has resolved the issue !

I double-checked WHY [pychant was present]- and - found out that it is part 
of Leo's required packages - See

* https://github.com/leo-editor/leo-editor/blob/devel/requirements.txt


Yes, that's right.  What I *think* I remember is that on some systems 
pyenchant wouldn't work when installed with pip.  In those cases, 
installing the system's package (e.g., python3-enchant) solved the problem.
 

Once again : Thanks a lot for resolving this issue !


: ) 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4787543a-a9a9-4816-a89e-c05ff0fa4fd6n%40googlegroups.com.

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

The PR has been merged into the devel branch.  Update your clone repo and 
you should be good to go.

There is a possibility that on some Linux systems you have to install  
*python3-enchant* using operating system installer.  Debian is one of them, 
I think.  So (untested) on debian-based distros:

sudo apt-get install python3-enchant

The reason is that on Windows the binary files needed are included in the 
PyPi install of pyenchant, but on Linux you have to install a system .so 
library and get it hooked up to the Python code.  The system's package does 
all that.  There's probably something similar for non-Debian-based distros.
On Wednesday, May 15, 2024 at 6:52:48 PM UTC-4 Thomas Passin wrote:

> I just created a PR to fix this bug.
>
> On Wednesday, May 15, 2024 at 6:33:36 PM UTC-4 Thomas Passin wrote:
>
>> I'm getting a better idea of what may be going on.  Leo's spell checker 
>> tries to load the pyenchant module (which contains a speller and some word 
>> dictionaries). If that is not available, then the code branches to the code 
>> with the bug.  On Linux, in this condition, Leo did open its GUI window but 
>> it was very small.  When I expanded it an empty outline was displayed, 
>> although it was called "workbook".
>>
>> When I fixed the bug by deleting the ".d", and made sure that enchant was 
>> not available, then Leo opened normally, although it did not have a 
>> spell-checking tab, which makes sense.
>>
>> Perhaps pyenchant is not available for the Mac Python distribution?  It 
>> can be checked for by by activating your venv and issuing the command
>>
>> python3 -m pip list |grep "pyenchant".
>>
>> If it's listed then open a Python interpreter session and try to import 
>> it:
>>
>> import enchant  # Not a typo - right name is "enchant", not "pyenchant"
>>
>> If it's not there, you can search on line to see if it can be obtained 
>> for the Mac.  In the meantime you can get Leo working right by finding the 
>> python file named in the error message, finding that line, and deleting the 
>> characters ".d".  Save the file.  Leo should then run correctly.
>>
>>
>> On Wednesday, May 15, 2024 at 5:34:11 PM UTC-4 Thomas Passin wrote:
>>
>>
>>
>> AttributeError: 'DefaultDict' object has no attribute 'd'
>>
>>
>> Funny, that looks like a bug in the devel branch that was fixed already. 
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/640af0a7-fcc5-42a7-8a96-99f4766fe958n%40googlegroups.com.

Re: glitches installing and starting Leo

[Thomas Passin]

It's something Qt on the Mac does automatically.  You have to go to some 
trouble to prevent it.

On Wednesday, May 15, 2024 at 7:55:42 PM UTC-4 andyjim wrote:

> OK, in Mac the menu bar is at top of screen, not in the Leo window. True 
> of all apps in Mac, I just wasn't expecting that in Leo and was looking for 
> it in the Leo window. So that little glitch is solved and I'll continue 
> getting acquainted.
>
> On Wednesday, May 15, 2024 at 11:23:14 AM UTC-4 andyjim wrote:
>
>> Thanks Edward and tbp1 (Thomas, is it?) 
>> I just rolled the dice and figured it shouldn't hurt to just install 
>> again.
>> I used:  python -m pip install Leo
>> It ran through install apparently without a hitch
>> I launched with: leo  (not ``leo``)
>> Leo launched, but no menu bar. Also got TypeError. Here is the whole 
>> output:
>>
>>- 
>>
>>setting leoID from os.getenv('USER'): 'andy'
>>
>>Leo 6.7.8
>>
>>Python 3.9.19, PyQt version 6.7.0
>>
>>darwin
>>
>>load_session Ignoring invalid session unl: 
>>'unl:gnx:///Users/andy/.leo/workbook.leo#andy.20240513222826.1'
>>
>>qt.qpa.fonts: Populating font family aliases took 355 ms. Replace 
>>uses of missing font family "DejaVu Sans Mono" with one that exists to 
>>avoid this cost. 
>>
>>unexpected error creating: None
>>
>>Traceback (most recent call last):
>>
>>
>>  File 
>>
>> "/opt/miniconda3/lib/python3.9/site-packages/leo/commands/spellCommands.py", 
>>line 65, in create
>>
>>f = open(fn, mode='wb')
>>
>>
>>- 
>>
>>
>>TypeError: expected str, bytes or os.PathLike object, not NoneType
>>
>>
>>
>>
>>
>>- 
>>
>>I'll go ahead and get acquainted with it and see how she rolls from 
>>here. It would be nice to have a menu bar though.
>>
>>Sorry I didn't figure out how to change the format/font back after 
>>the copy paste.
>>
>>
>>Andy
>>
>> On Wednesday, May 15, 2024 at 10:33:36 AM UTC-4 Edward K. Ream wrote:
>>
>>> On Wed, May 15, 2024 at 8:50 AM Thomas Passin  wrote:
>>>
>>>> It's a little hard to help with Mac-related problems because most of 
>>>> the developer-minded people (like Edward and myself) don't have Macs to 
>>>> try 
>>>> things out on.  
>>>
>>>
>>> I do have a Mac, but I have been lax about testing. I typically update 
>>> Leo using git.
>>>
>>> I've just made a note to myself about testing a clean MacOS install.
>>>
>>> Edward
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/29b5210c-d7b0-423d-9a9e-b0051f6dee30n%40googlegroups.com.

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

I just created a PR to fix this bug.

On Wednesday, May 15, 2024 at 6:33:36 PM UTC-4 Thomas Passin wrote:

> I'm getting a better idea of what may be going on.  Leo's spell checker 
> tries to load the pyenchant module (which contains a speller and some word 
> dictionaries). If that is not available, then the code branches to the code 
> with the bug.  On Linux, in this condition, Leo did open its GUI window but 
> it was very small.  When I expanded it an empty outline was displayed, 
> although it was called "workbook".
>
> When I fixed the bug by deleting the ".d", and made sure that enchant was 
> not available, then Leo opened normally, although it did not have a 
> spell-checking tab, which makes sense.
>
> Perhaps pyenchant is not available for the Mac Python distribution?  It 
> can be checked for by by activating your venv and issuing the command
>
> python3 -m pip list |grep "pyenchant".
>
> If it's listed then open a Python interpreter session and try to import it:
>
> import enchant  # Not a typo - right name is "enchant", not "pyenchant"
>
> If it's not there, you can search on line to see if it can be obtained for 
> the Mac.  In the meantime you can get Leo working right by finding the 
> python file named in the error message, finding that line, and deleting the 
> characters ".d".  Save the file.  Leo should then run correctly.
>
>
> On Wednesday, May 15, 2024 at 5:34:11 PM UTC-4 Thomas Passin wrote:
>
>
>
> AttributeError: 'DefaultDict' object has no attribute 'd'
>
>
> Funny, that looks like a bug in the devel branch that was fixed already. 
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8d6a26f3-af03-4904-8580-5127fcab2651n%40googlegroups.com.

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

I'm getting a better idea of what may be going on.  Leo's spell checker 
tries to load the pyenchant module (which contains a speller and some word 
dictionaries). If that is not available, then the code branches to the code 
with the bug.  On Linux, in this condition, Leo did open its GUI window but 
it was very small.  When I expanded it an empty outline was displayed, 
although it was called "workbook".

When I fixed the bug by deleting the ".d", and made sure that enchant was 
not available, then Leo opened normally, although it did not have a 
spell-checking tab, which makes sense.

Perhaps pyenchant is not available for the Mac Python distribution?  It can 
be checked for by by activating your venv and issuing the command

python3 -m pip list |grep "pyenchant".

If it's listed then open a Python interpreter session and try to import it:

import enchant  # Not a typo - right name is "enchant", not "pyenchant"

If it's not there, you can search on line to see if it can be obtained for 
the Mac.  In the meantime you can get Leo working right by finding the 
python file named in the error message, finding that line, and deleting the 
characters ".d".  Save the file.  Leo should then run correctly.

On Wednesday, May 15, 2024 at 5:34:11 PM UTC-4 Thomas Passin wrote:



AttributeError: 'DefaultDict' object has no attribute 'd'


Funny, that looks like a bug in the devel branch that was fixed already. 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/005de986-1be0-444b-a5e4-a62a2c602796n%40googlegroups.com.

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

On my system, this version has the same line, but the line isn't getting 
called at startup.  Looking at the code that creates a DefaultDict, I don't 
see that it should have an attribute "d".  I suspect that the line should be

g.app.spellDict = DefaultDict()  # 2024/04/09: bug fix.

I can't test that because it's not getting called on my system.  I'm 
surprised that this failure can keep Leo from operating...


On Wednesday, May 15, 2024 at 3:16:23 PM UTC-4 viktor@gmail.com wrote:

> Hello Thomas,
>
> tbp1...@gmail.com schrieb am Mittwoch, 15. Mai 2024 um 20:57:02 UTC+2:
>
> On Wednesday, May 15, 2024 at 2:33:08 PM UTC-4 viktor@gmail.com wrote:
>
> Hello Thomas,
> [snip]
>
>
>   File 
> "/home/user/PyVE/GitHub/Leo/leo-editor/leo/commands/spellCommands.py", line 
> 185, in __init__
> g.app.spellDict = DefaultDict().d  # 2024/04/09: bug fix.
>   ^^^
>
> AttributeError: 'DefaultDict' object has no attribute 'd'
>
>
> Funny, that looks like a bug in the devel branch that was fixed already. 
>
> Strange, but the version of the devel branch you are running is not the 
> current one, and I can't even find yours on Github.  The current commit 
> is eef303a2d0fc1e41634376058fa5ace2ac9fad95.  Try updating your clone, or 
> downloading a zip of the current version of the devel branch and using that 
> one.
>
>
> I did what you said - but - no change : -( - See log !
>
> I'll call it a day for now - and - will restart tomorrow morning ...
>
> With kind regards,
>
> Viktor
>
> ### New Log
>
>  user@debian-leo-study-vm:~$ cd PyVE/GitHub/Leo/
> user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ 
> user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ source bin/activate
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ 
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ cd leo-editor/
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ 
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ git branch
> * devel
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ 
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ git pull
> remote: Enumerating objects: 88, done.
> remote: Counting objects: 100% (76/76), done.
> remote: Compressing objects: 100% (19/19), done.
> remote: Total 50 (delta 44), reused 37 (delta 31), pack-reused 0
> Unpacking objects: 100% (50/50), 5.44 KiB | 67.00 KiB/s, done.
> From https://github.com/leo-editor/leo-editor
>fb85027ea..eef303a2d  devel-> origin/devel
>18f9164ec..01d9dda87  ekr-3871-search-settings -> 
> origin/ekr-3871-search-settings
>  * [new branch]  ekr-3910-no-fl-ns-plugins -> 
> origin/ekr-3910-no-fl-ns-plugins
>  * [new branch]  ekr-3912-MacOs-crash -> 
> origin/ekr-3912-MacOs-crash
>fb85027ea..eef303a2d  gh-pages -> origin/gh-pages
> Updating fb85027ea..eef303a2d
> Fast-forward
>  leo/config/leoSettings.leo |   2 +-
>  leo/core/leoCache.py   |  28 +-
>  leo/core/leoFileCommands.py|   4 -
>  leo/core/leoFrame.py   |   4 +-
>  leo/core/leoTokens.py  |  11 +-
>  leo/doc/leoAttic.txt   | 115 ++
>  leo/plugins/free_layout.py |  33 +-
>  leo/plugins/nested_splitter.py |   8 +-
>  leo/plugins/qt_frame.py|   2 +-
>  leo/plugins/viewrendered.py| 837 
> +++--
>  10 files changed, 550 insertions(+), 494 deletions(-)
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ 
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ python3 
> -m leo.core.runLeo --version
> Leo 6.7.9-devel, devel branch, build eef303a2d0
> 2024-05-14 07:59:14 -0500
> Python 3.11.2
> linux
>
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ 
> (Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ python3 
> -m leo.core.runLeo
> setting leoID from os.getenv('USER'): 'user'
> Leo 6.7.9-devel, devel branch, build eef303a2d0
> 2024-05-14 07:59:14 -0500
>
> Python 3.11.2, PyQt version 6.7.0
> linux
> Can not load session
> Traceback (most recent call last):
>
>   File "/home/user/PyVE/GitHub/Leo/leo-editor/leo/core/leoApp.py", 
> line 2307, in doPostPluginsInit
> g.app.sessionManager.load_session(c1, aList)
>
>   File 
> "/home/user/PyVE/GitHub/Leo/leo-editor/leo/core/leoSessions.py", line 72, 
> in load_session
> g.openWithFileName(fn, gui=g.app.gui, old_c=c)
>
>   File "/home/user/PyVE/GitHub/Leo/leo-editor/leo/core/leoGlobals.py", 
> line 3238, in openWithFileName
> return g.app.loadManager.openWithFileName(fileName, gui, old_c)
>
>
>   File "/home/user/PyVE/GitHub/Leo/leo-editor/leo/core/leoApp.py", 
> line 3010, in openWithFileName
> return 

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

On Wednesday, May 15, 2024 at 2:33:08 PM UTC-4 viktor@gmail.com wrote:

Hello Thomas,
[snip]
  File 
"/home/user/PyVE/GitHub/Leo/leo-editor/leo/commands/spellCommands.py", line 
185, in __init__
g.app.spellDict = DefaultDict().d  # 2024/04/09: bug fix.
  ^^^

AttributeError: 'DefaultDict' object has no attribute 'd'


Funny, that looks like a bug in the devel branch that was fixed already. 

Strange, but the version of the devel branch you are running is not the 
current one, and I can't even find yours on Github.  The current commit 
is eef303a2d0fc1e41634376058fa5ace2ac9fad95.  Try updating your clone, or 
downloading a zip of the current version of the devel branch and using that 
one.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/7d40b36d-6f81-4146-aec3-dec62ee83660n%40googlegroups.com.

Re: glitches installing and starting Leo

[Thomas Passin]

The Type error message is from the spellchecker.  It wants to create a file 
to hold new words it doesn't know, but it was not passes an actual 
filename.  It shouldn't affect the rest of Leo's operation and may not even 
prevent the spell checker from working.

As to the menu, don't application main menus appear at the top of the 
screen for a Mac (possibly hidden until moused over)?  Qt by default does 
the same.  From Qt6 docs: "Qt detects menu bars and turns them into Mac 
native menu bars".

On Wednesday, May 15, 2024 at 11:23:14 AM UTC-4 andyjim wrote:

> Thanks Edward and tbp1 (Thomas, is it?) 
> I just rolled the dice and figured it shouldn't hurt to just install again.
> I used:  python -m pip install Leo
> It ran through install apparently without a hitch
> I launched with: leo  (not ``leo``)
> Leo launched, but no menu bar. Also got TypeError. Here is the whole 
> output:
>
>- 
>
>setting leoID from os.getenv('USER'): 'andy'
>
>Leo 6.7.8
>
>Python 3.9.19, PyQt version 6.7.0
>
>darwin
>
>load_session Ignoring invalid session unl: 
>'unl:gnx:///Users/andy/.leo/workbook.leo#andy.20240513222826.1'
>
>qt.qpa.fonts: Populating font family aliases took 355 ms. Replace uses 
>of missing font family "DejaVu Sans Mono" with one that exists to avoid 
>this cost. 
>
>unexpected error creating: None
>
>Traceback (most recent call last):
>
>
>  File 
>
> "/opt/miniconda3/lib/python3.9/site-packages/leo/commands/spellCommands.py", 
>line 65, in create
>
>f = open(fn, mode='wb')
>
>
>- 
>
>
>TypeError: expected str, bytes or os.PathLike object, not NoneType
>
>
>
>
>
>- 
>
>I'll go ahead and get acquainted with it and see how she rolls from 
>here. It would be nice to have a menu bar though.
>
>Sorry I didn't figure out how to change the format/font back after the 
>copy paste.
>
>
>Andy
>
> On Wednesday, May 15, 2024 at 10:33:36 AM UTC-4 Edward K. Ream wrote:
>
>> On Wed, May 15, 2024 at 8:50 AM Thomas Passin  wrote:
>>
>>> It's a little hard to help with Mac-related problems because most of the 
>>> developer-minded people (like Edward and myself) don't have Macs to try 
>>> things out on.  
>>
>>
>> I do have a Mac, but I have been lax about testing. I typically update 
>> Leo using git.
>>
>> I've just made a note to myself about testing a clean MacOS install.
>>
>> Edward
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2cb81ef9-33f7-4aac-b8b8-1110b8abdca6n%40googlegroups.com.

Re: glitches installing and starting Leo

[Thomas Passin]

It's a little hard to help with Mac-related problems because most of the 
developer-minded people (like Edward and myself) don't have Macs to try 
things out on.  Most of the people with Macs seem to be more like you - 
user-minded rather than developer-minded.

You could try searching through the threads on this group using the search 
box at upper right.  I tried "install mac" and got a number of hits, one of 
which is this one: 
https://groups.google.com/g/leo-editor/c/GgYQNRQed9o/m/LMTLC6sZAgAJ. I also 
found Using MacPorts to deploy Leo on macOS computers 
 using 
the search phrase "installing leo on Macs". Other people have wrestled with 
Mac installation problems and you may find something that applies directly 
to you.

I also tried an on-line search for "problems installing leo on Macs" and 
saw this: How to install Leo under M1 chip macOS 12 
. Note that this 
post is a little out of date: you need to use pyqt6 instead of pyqt5; the 
python version it uses is not the current one.  But it might help you if 
you remember to adjust those little version-related kinds of things.

HTH

On Wednesday, May 15, 2024 at 7:54:28 AM UTC-4 andyjim wrote:

> I spoke from frustration, sir. I should not complain so loudly on day one.
> No I don't have the complete message. Should I uninstall and start over? 
> If so, how do I uninstall?
> And is there a more likely install path than what I used:
> I tried miniconda first (seemed simplest), then brew. Sorry, I don't have 
> record of the breakdown of those two install attempts.
>
> On Wednesday, May 15, 2024 at 7:06:44 AM UTC-4 Edward K. Ream wrote:
>
>> On Tue, May 14, 2024 at 7:46 AM andyjim  wrote:
>>
>> > Leo seems like a tough road for a non-techie.
>>
>> My apologies. It shouldn't the *that* tough :-)
>>
>> > It was a challenge just installing it (on Mac 14.4.1), and Terminal 
>> gave me an error:
>>
>> > TypeError: expected str, bytes or os.PathLike object, not NoneType 
>>
>> In the future, it's good to record the entire console message. That will 
>> tell me where the problem lies.
>>
>> Do you have a copy of the console message?
>>
>> The other problems you report may have been the result of the TypeError.
>>
>> Edward
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/adefeafe-5398-44b7-8d94-f4b20a945837n%40googlegroups.com.

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

It's hard for me to know what you want to convey with these long 
transcripts.  It would be better if they were edited, or at least if you 
would point out results that you don't like or don't understand.  But I can 
see a few things, I think:

1. Installing Leo's dependencies using pip -r requirements.txt does not 
install Leo itself.  It does not create those scripts in the venv's bin 
directory.  It only installs the modules and packages that Leo needs.  You 
have to install Leo using pip for that (while the venv is active).  For 
example, in my "leo" venv, which has Leo's dependencies but into which I 
haven't installed leo using pip, there is no *leo* script:

(leo) tom@thomas-xubuntu-VirtualBox:~/venv$ ls leo/bin/ |grep "leo"
# there was no result

2. Using python3 -m leo.core.runLeo, when you have cd'ed to your github's 
leo-editor directory, finds Leo's files because Python starts looking for 
files starting at the current directory.  If you export the PYTHONPATH 
shell variable, then Python will start by looking there.  That's why I 
recommend using a script that sets the variable.  Then you don't have to 
remember to cd to the right directory first.

3. Even after you have activated your venv, the shell will not find its 
*leo* script because there isn't one. It won't be there unless you 
pip-install Leo while the venv is activated. The results from running 
*which* show that.  You could also use *whereis*, and get the same result.  
Even if you installed Leo in the venv and started Leo using the venv's *leo* 
script, 
Leo would be using the Leo code in the venv, not the code in your github 
repo.

4. Your transcript shows that Leo started when you had cd'ed to its repo 
directory.  But I can only see Leo's startup output to the console. That 
output looks normal.  But it doesn't tell me if the Leo window actually 
opened and worked.  Did it?

HTH


On Wednesday, May 15, 2024 at 6:22:34 AM UTC-4 viktor@gmail.com wrote:

Hello Thomas,

Thanks a lot for all the feedback & input you provided ! - I will read them 
one by one ...

tbp1...@gmail.com schrieb am Dienstag, 14. Mai 2024 um 20:05:10 UTC+2:

It can be hard to be sure what the Python search path is.  Here is what 
shows up for my system when I have activated my "Leo" VE.  This VE (on 
Windows) is contained in the directory  C:\Tom\venvs\leo. Note that on 
Windows you don't have to source the script.


Please bear with me a bit longer, as I'm sometimes stubborn ;-)

I'd like to understand, why the case of 'Leo from GitHub in a PyVE' is no 
longer working ?  - It has worked on Linux (Debian & Fedora) up until Leo 
version 6.7.7 (maybe evern 6.7.8) !

I'd like to do that, before creating an **additional personal** script, 
since I still believe it should be part of Leo's GitHub repository ...

I did use your advice to check  Python's search path, etc. - Here are the 
results for the three relevant cases in my Debian 12 VM:

* Check out Python's search path with Leo outside of any PyVE - See 
"Log-001".
* Check out search path in Leo's PyVE from PyPI - See "Log-002".
* Check out search path in Leo's PyVE from GitHub - See "Log-003".

Note 1: The first variation is necessary for me to address Leo-Integ issue 
# 299 .

Note 2: The answer to my question has to do with the fact that no 'leo' 
module is found in '/home/user/PyVE/GitHub/Leo/bin'  - See "Log-003" ...

With kind regards,

Viktor

### Log-001

user@debian-leo-study-vm:~$ 
user@debian-leo-study-vm:~$ python3 -c "import 
sys;print('\n'.join(sys.path))"

/usr/lib/python311.zip
/usr/lib/python3.11
/usr/lib/python3.11/lib-dynload
/home/user/.local/lib/python3.11/site-packages
/usr/lib/python3/dist-packages
/usr/lib/python3.11/dist-packages
user@debian-leo-study-vm:~$ 
user@debian-leo-study-vm:~$ 
user@debian-leo-study-vm:~$ python3 -m leo.core.runLeo --version
Leo 6.7.8
Python 3.11.2
linux

user@debian-leo-study-vm:~$ which leo
/home/user/.local/bin/leo
user@debian-leo-study-vm:~$ 
user@debian-leo-study-vm:~$ echo $PATH

/home/user/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
user@debian-leo-study-vm:~$ 

### Log-002

user@debian-leo-study-vm:~$ cd PyVE/PyPI/Leo/
user@debian-leo-study-vm:~/PyVE/PyPI/Leo$ source bin/activate
(Leo) user@debian-leo-study-vm:~/PyVE/PyPI/Leo$ python3 -c "import 
sys;print('\n'.join(sys.path))"

/usr/lib/python311.zip
/usr/lib/python3.11
/usr/lib/python3.11/lib-dynload
/home/user/PyVE/PyPI/Leo/lib/python3.11/site-packages
(Leo) user@debian-leo-study-vm:~/PyVE/PyPI/Leo$ 
(Leo) user@debian-leo-study-vm:~/PyVE/PyPI/Leo$ python3 -m 
leo.core.runLeo --version
Leo 6.7.8
Python 3.11.2
linux

(Leo) user@debian-leo-study-vm:~/PyVE/PyPI/Leo$ 
(Leo) user@debian-leo-study-vm:~/PyVE/PyPI/Leo$ which leo
/home/user/PyVE/PyPI/Leo/bin/leo
(Leo) 

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

I though it might be useful to pull together the steps to create on Linux a 
new virtual environment (venv) and install Leo's dependencies into it.  I 
created a new venv in the ~/venv*/leo* directory for this purpose:

tom@thomas-xubuntu-VirtualBox:~/venv$ mkdir leo
tom@thomas-xubuntu-VirtualBox:~/venv$ python3 -m venv leo
tom@thomas-xubuntu-VirtualBox:~/venv$ source ./leo/bin/activate
(leo) tom@thomas-xubuntu-VirtualBox:~/venv$ python3 -m pip install -r 
~/git/leo-editor/requirements.txt 
  tom@thomas-xubuntu-VirtualBox:~/venv$

On Tuesday, May 14, 2024 at 2:40:34 PM UTC-4 Thomas Passin wrote:

> In case I didn't make it clear, I think a script like the one I showed 
> above is an excellent way to launch the copy of Leo that is in your cloned 
> repo.  That's because it works from anywhere and you don't need to remember 
> any special locations or cd to them  If you are in an activated venv, it 
> works and will use the venv version of the dependencies.  If you are not in 
> a venv, it will use the system Leo installation and dependencies, if you've 
> installed them there (I have - in the user site-packages directory, of 
> course, not the system's).
>
> On Tuesday, May 14, 2024 at 2:09:14 PM UTC-4 Thomas Passin wrote:
>
> On Tuesday, May 14, 2024 at 2:05:10 PM UTC-4 Thomas Passin wrote:
>
> The script to launch Leo is in the *Scripts* directory.
>
>
> Of course, in Linux this will be the *bin* directory instead.
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/75b0ff52-099a-4de5-8c19-f2809a67c8a1n%40googlegroups.com.

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

In case I didn't make it clear, I think a script like the one I showed 
above is an excellent way to launch the copy of Leo that is in your cloned 
repo.  That's because it works from anywhere and you don't need to remember 
any special locations or cd to them  If you are in an activated venv, it 
works and will use the venv version of the dependencies.  If you are not in 
a venv, it will use the system Leo installation and dependencies, if you've 
installed them there (I have - in the user site-packages directory, of 
course, not the system's).

On Tuesday, May 14, 2024 at 2:09:14 PM UTC-4 Thomas Passin wrote:

On Tuesday, May 14, 2024 at 2:05:10 PM UTC-4 Thomas Passin wrote:

The script to launch Leo is in the *Scripts* directory.


Of course, in Linux this will be the *bin* directory instead.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/bc070f06-8be4-42ed-a756-a0ec0001a927n%40googlegroups.com.

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

On Tuesday, May 14, 2024 at 2:05:10 PM UTC-4 Thomas Passin wrote:

The script to launch Leo is in the *Scripts* directory.


Of course, in Linux this will be the *bin* directory instead.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6fc137a7-b258-4b5b-a6a2-d411998612f5n%40googlegroups.com.

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

It can be hard to be sure what the Python search path is.  Here is what 
shows up for my system when I have activated my "Leo" VE.  This VE (on 
Windows) is contained in the directory  C:\Tom\venvs\leo. Note that on 
Windows you don't have to source the script.

C:\Tom\venvs\leo>Scripts\activate

(leo) C:\Tom\venvs\leo>py -c "import sys;print('\n'.join(sys.path))

C:\Users\tom\AppData\Local\Programs\Python\Python312\python312.zip
C:\Users\tom\AppData\Local\Programs\Python\Python312\DLLs
C:\Users\tom\AppData\Local\Programs\Python\Python312\Lib
C:\Users\tom\AppData\Local\Programs\Python\Python312
C:\Tom\venvs\leo
C:\Tom\venvs\leo\Lib\site-packages
C:\Tom\venvs\leo\Lib\site-packages\win32
C:\Tom\venvs\leo\Lib\site-packages\win32\lib
C:\Tom\venvs\leo\Lib\site-packages\Pythonwin

This is for a pip-installed version of Leo, not one cloned from github.  
Notice how Python will search its original installation path first, then 
the venv paths.  Anything that was installed into the system's 
*Lib/sitepackages* location will be found first.  Especially on Linux it's 
unlikely that Leo was installed there.

The script to launch Leo is in the *Scripts* directory.

(leo) C:\Tom\venvs\leo>dir Scripts |find "leo"
 Directory of C:\Tom\venvs\leo\Scripts
02/28/2024  09:20 AM   108,401 leo-c.exe
02/28/2024  09:20 AM   108,401 leo-console.exe
02/28/2024  09:20 AM   108,385 leo-m.exe
02/28/2024  09:20 AM   108,385 leo-messages.exe
02/28/2024  09:20 AM   102,242 leo.exe

Otherwise, for this venv, when you issue the command python3 -m 
leo.core.runLeo,  Python will look for a *leo* directory from top to bottom 
in the list of directory on sys.path.  It will get to 
C:\Tom\venvs\leo\Lib\site-package, and will find it there.

Sometimes, and this applies to Debian IIRC, the first time Leo is installed 
on a computer you might see an error message when you try to run it. The error 
message will say that "libxcb-cursor0" is needed (that's "cursorZero", in 
case the font zero looks like the letter O). You can install that library 
with the system package installer (e.g., apt-get),  But that may or may not 
be the right name to use for the library.  If the install attempt doesn't 
work, you can check at http://pkgs.org/ to find a better package name.

For running Leo with a clone of the Leo repo, I use a little script that 
sets the PYTHONPATH to the location of the cloned repo.  Here's my Linux 
script (the git clone is in ~/git/leo-editor):

(qt6) tom@thomas-xubuntu-VirtualBox:~/venv/qt6$ whereis py-leo-git
py-leo-git: /home/tom/.local/bin/py-leo-git
(qt6) tom@thomas-xubuntu-VirtualBox:~/venv/qt6$ cat 
/home/tom/.local/bin/py-leo-git
#! /usr/bin/bash 
if [ "$PYTHONPATH" == "" ]; then 
export PYTHONPATH=~/git/leo-editor
echo "Using PYTHONPATH:" $PYTHONPATH
else
echo "PYTHONPATH already set to " $PYTHONPATH
fi

python3 -m leo.core.runLeo $*

Running this script from inside your activated venv will run Python using 
the copy of Leo that is located in the repo.

HTH

On Tuesday, May 14, 2024 at 1:15:19 PM UTC-4 viktor@gmail.com wrote:

Hello Thomas,

tbp1...@gmail.com schrieb am Dienstag, 14. Mai 2024 um 16:03:20 UTC+2:

I wonder whether you VE activation somehow got lost during this process.  I 
noticed this:

~$ which leo
/home/user/.local/bin/leo

This says that typing "leo" uses that script, which is not one in the VE.  
Try this, and let us know what happens -

First, activate your VE environment.  Then issue

python3 -m leo.core.runLeo --version

You should get something like this:

Leo 6.7.9-devel, ekr-3892-vr-pane branch, build 8ede3fc77e
2024-05-14 05:12:23 -0500
Python 3.11.6
linux


Thanks a lot for your feedback ! - This is what the command returns in the 
first place:

user@debian-leo-study-vm:~$ cd PyVE/GitHub/Leo/

user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ 
user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ source bin/activate
(Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ 
(Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ python3 -m 
leo.core.runLeo --version
/home/user/PyVE/GitHub/Leo/bin/python3: Error while finding module 
specification for 'leo.core.runLeo' (ModuleNotFoundError: No module named 
'leo')
(Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ 

Only if I move a directory 'down' the command works:

(Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ 
(Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ cd leo-editor/
(Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ 
(Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ python3 -m 
leo.core.runLeo --version
Leo 6.7.9-devel, devel branch, build fb85027eac
2024-05-13 16:10:23 -0500
Python 3.11.2
linux
(Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo/leo-editor$ 

I guess some more ' reading' on my side is needed ...

With kind regards,

Viktor

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop 

Re: Leo from GitHub in a PyVE on Debian ?

[Thomas Passin]

I wonder whether you VE activation somehow got lost during this process.  I 
noticed this:

~$ which leo
/home/user/.local/bin/leo

This says that typing "leo" uses that script, which is not one in the VE.  
Try this, and let us know what happens -

First, activate your VE environment.  Then issue

python3 -m leo.core.runLeo --version

You should get something like this:

Leo 6.7.9-devel, ekr-3892-vr-pane branch, build 8ede3fc77e
2024-05-14 05:12:23 -0500
Python 3.11.6
linux

I always run Leo that way, or with a script that uses the incantation.  You 
are guaranteed to run the version of Leo that goes along with that version 
of python3, and if you have activated the VE then Python's module search 
path will be within the VE.  Otherwise, you are at the mercy of the system, 
which may not have the same idea as you as to what to run.

I often create one desktop icon to run the ordinary release of Leo and 
another one to run from my git-clone directory.  I recommend that you do 
the same (or create two launch scripts and use them).

On Tuesday, May 14, 2024 at 8:54:38 AM UTC-4 viktor@gmail.com wrote:

Hello everyone,

Today I have started again to check out the status of Leo (devel branch) 
from GitHub within a Debian 12 VM.

I believe that I did follow the (new) recommended steps for Leo, i.e.:

* Created a new PyVE for Leo from GitHub - OK - See "Log-001".
* Installed Leo from GitHub from scratch - Not OK - See "Log-002".

Has anybody else tried such a setup - and / or - does anyone of you have an 
explanation what is going wrong / what I'm missing ?

If I try the same in a similar environment, with Leo using pip from PyPI, I 
get the following status, which I'd have expected in a similar fashion also 
for the setup from GitHub - See "Log-003".

Thanks a lot for any kind of feedback !

[snip] 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/082e4d9c-c09b-4557-86cc-f1fadf513371n%40googlegroups.com.

Re: leo-to-html HAS STOPPED WORKING

[Thomas Passin]

On Monday, May 13, 2024 at 8:18:56 PM UTC-4 chr...@gmail.com wrote:

OK, it *WORKS*.
...
*THANK YOU SO MUCH THOMAS!* I got the job done just as my nightly backups 
started, ruthlessly hogging the CPU of the laptop I was using.

 
Glad I could help!
 

By the way, several other plugins don't work anymore. I forgot which ones.


There are quite a few, actually.  Some never got updated for Qt, and some 
weren't updated for Qt6.  Their original authors haven't thought to see if 
they work (maybe they have moved on and don't use the plugin any more).  In 
some cases, the plugins may have been subjected to some enhancement, 
usually adding type hints, that ended up changing some variable or property 
such that the code no longer worked.  There are still (I'm pretty sure) old 
plugins that were written for Python2 and never updated.

No one is interested in working through all of them and getting them 
working.  Who wants to spend time figuring out how a plugin works that one 
doesn't want to use anyway, especially if using it is complex and hard to 
understand?  In the case of leo-to-html, I got curious to see if it did 
something I'd like, and when I looked at it, the code and operation seemed 
fairly simple, so I spent the time for you.
 

The "outside of the python directory" LEO-EDITOR-MASTER trick is a very 
good one. It makes updating both python and Leo sources much easier, 
without having to create environments etc. It seems to have disappeared 
from the "downloading Leo" webpage, though. There was a "downloading 
sources" section, and I always assumed that the other download methods were 
providing a kind of half "compiled' Leo, so I never used them. Is that the 
case? now the whole sources package can be downloaded from github, I guess.


Nowadays the equivalent would be the *leo-editor* directory, which is above 
the *leo* directory in the repository.  You get it if you clone the repo.
 

"Leo is a PIM" is not really true anymore.
Without the whole professional programmer's knowledge of all the 
intricacies of  process and online platforms such as github and all the 
extra software used to put together and install something like Leo, the guy 
like me for whom computers are first and foremost (addictive) tools to 
achieve other things, Leo's complexity has evolved so much that it is now 
only a great tool for programmers.

I'm planning to go back to OmniOutliner: I'll have my outlines (with 
pictures) on my Mac, on my PCs through Teamviewer, and on my iPad and 
iPhone without having to convert them to OPML with a script. I won't have 
to go through reams of scattershot documentations at every turn of the road.

It was an interesting adventure...

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e1cd50a5-25fb-4574-aad4-3c43954bcb3dn%40googlegroups.com.

Re: leo-to-html HAS STOPPED WORKING

[Thomas Passin]

On Monday, May 13, 2024 at 6:33:18 PM UTC-4 chr...@gmail.com wrote:

OK,  so that's why it wouldn't work: I copied it in 
C:\leo-editor-master\leo\plugins\
I don't even know the difference betweenl eo-editor-master and  the install 
that's in Python site-packages.


I assumed that you were trying to use it with the latest Leo release, the 
one you get by installing it with pip. If you have a copy or clone of the 
whole Leo repository you have to make sure that Python will use that one 
instead.  There are various ways to do that.  At any rate, the command I 
gave you earlier will tell you where the thing is actually living.
 

I'MM A SELF-TAUGHT GUY except for one semester of BASIC on Apple 2 around 
1982, fer chrissakes. But I did surf the wave all along, and among other 
things I even learned C in a week and wrote an online financial datafeed 
custom on-demand retrieval program for UBS in the early 90s, in another two 
weeks, dammit.
Only ever used Github to download useful stuff. I couldn't find how to 
download the plugin so I copied the text, and of course the first time it 
wasn't fully expanded.
Gonna try what you wrote now.

On Monday, May 13, 2024 at 10:06:08 PM UTC tbp1...@gmail.com wrote:

Yes, once you find the leo-to-html.py file, download it and then copy into 
your Python install's *site-packages/leo/plugins* directory.

To find that location, open a terminal or console and run

py -m pip show leo

NOTE - use the actual command that you use to run Python if it's not "py".  
The response will include a line that tells you where the right 
*site-packages* directory is.  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/09a7b44b-15e1-4640-b47d-708b35e894ean%40googlegroups.com.

Re: leo-to-html HAS STOPPED WORKING

[Thomas Passin]

Yes, once you find the leo-to-html.py file, download it and then copy into 
your Python install's *site-packages/leo/plugins* directory.

To find that location, open a terminal or console and run

py -m pip show leo

NOTE - use the actual command that you use to run Python if it's not "py".  
The response will include a line that tells you where the right 
*site-packages* directory is.  On my system it's

Location: C:\Users\tom\AppData\Roaming\Python\Python312\site-packages

Here's a step-by-step now that's in the main Leo-Editor repository.  First, 
navigate to the top of the repo . 
Select the *Code* tab if it's not selected. Then select the *devel* branch 
in the branch selector box, near the upper left.  Then navigate to 
*leo/plugins* page and scroll down until you find the link to our file, 
*leo-html.py*.  Click that link.
In  that page, the one for our file,  notice near the upper right that 
there is a box labeled "Raw".  There is a download icon next to it.  Click 
that to download our file.

Please post about any apparent bugs you find - I haven't given this fix 
much of a workout.  I hoped to get you running as quickly as possible since 
you sounded as if you depend a lot on the plugin.
On Monday, May 13, 2024 at 5:48:26 PM UTC-4 chr...@gmail.com wrote:

> On Monday, May 13, 2024 at 8:06:29 PM UTC tbp1...@gmail.com wrote:
>
> I have created a pull request, 3907 
> , that gets this 
> plugin working again.  At least, it works when outputting just the 
> headlines. 
>
> If anyone wants to try it out before the PR gets merged into the devel 
> branch, you can follow the link in the Github PR page to my repository and 
> get the file there.
>
>
> Thanks Thomas, I half understand "Github PR page to my repository"... is 
> the name of the file LEO-TO-HTML.? and do I replace the same file in my 
> installation?
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/989d1ab0-f46a-4925-8889-346e54d4a7abn%40googlegroups.com.

Re: leo-to-html HAS STOPPED WORKING

[Thomas Passin]

This PR has been merged into the *devel *branch, if you need it before the 
next general release of Leo.

On Monday, May 13, 2024 at 4:06:29 PM UTC-4 Thomas Passin wrote:

> I have created a pull request, 3907 
> <https://github.com/leo-editor/leo-editor/pull/3907>, that gets this 
> plugin working again.  At least, it works when outputting just the 
> headlines.  I haven't tested it including all the body text.  But I think 
> it should work as it did before.
>
> As for that *Properties* submenu in the Plugins menu, that's not going to 
> work until someone is able to put in a lot of work to make it function in 
> Qt (it's a holdover from the Tk  Gui days, apparently).  But you can still 
> set those properties by hand in the .ini file *leo-to-html.ini*, as before
> *.*
>
> If anyone wants to try it out before the PR gets merged into the devel 
> branch, you can follow the link in the Github PR page to my repository and 
> get the file there.
>
> On Monday, May 13, 2024 at 1:21:21 PM UTC-4 Thomas Passin wrote:
>
>> I don't know why it's not working, but I do know why the submenus aren't 
>> appearing.  It's because the plugin is trying to add its own menus under 
>> the *File/Export...* menu.  But that's been renamed and is now *File/Export 
>> Files*.  The plugin code will have to change to match that name.  Even 
>> better would be for the plugin to insert its own menu item with its 
>> submenus.  Then it won't fail the next time there's a menu name change.
>>
>> What is the latest release where you know it worked?
>>
>>
>> On Monday, May 13, 2024 at 12:35:09 PM UTC-4 chr...@gmail.com wrote:
>>
>> *...and it's a major-urgent-pain-in-the-neck for me!*
>>
>> - None of the plugin submenus appear in the File > Export Files... menu
>> - The plugin is correctly enabled in myLeoSettings.leo
>> - There is no "@bool leo_to_html_no_menus = True" anywhere
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6cc8cb81-30fb-4976-b03d-1e862d8fc7d2n%40googlegroups.com.

Re: leo-to-html HAS STOPPED WORKING

[Thomas Passin]

I have created a pull request, 3907 
<https://github.com/leo-editor/leo-editor/pull/3907>, that gets this plugin 
working again.  At least, it works when outputting just the headlines.  I 
haven't tested it including all the body text.  But I think it should work 
as it did before.

As for that *Properties* submenu in the Plugins menu, that's not going to 
work until someone is able to put in a lot of work to make it function in 
Qt (it's a holdover from the Tk  Gui days, apparently).  But you can still 
set those properties by hand in the .ini file *leo-to-html.ini*, as before
*.*

If anyone wants to try it out before the PR gets merged into the devel 
branch, you can follow the link in the Github PR page to my repository and 
get the file there.

On Monday, May 13, 2024 at 1:21:21 PM UTC-4 Thomas Passin wrote:

> I don't know why it's not working, but I do know why the submenus aren't 
> appearing.  It's because the plugin is trying to add its own menus under 
> the *File/Export...* menu.  But that's been renamed and is now *File/Export 
> Files*.  The plugin code will have to change to match that name.  Even 
> better would be for the plugin to insert its own menu item with its 
> submenus.  Then it won't fail the next time there's a menu name change.
>
> What is the latest release where you know it worked?
>
>
> On Monday, May 13, 2024 at 12:35:09 PM UTC-4 chr...@gmail.com wrote:
>
> *...and it's a major-urgent-pain-in-the-neck for me!*
>
> - None of the plugin submenus appear in the File > Export Files... menu
> - The plugin is correctly enabled in myLeoSettings.leo
> - There is no "@bool leo_to_html_no_menus = True" anywhere
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0c45591c-8180-4b54-97ac-d4c2e621c5bbn%40googlegroups.com.

Re: leo-to-html HAS STOPPED WORKING

[Thomas Passin]

I don't know why it's not working, but I do know why the submenus aren't 
appearing.  It's because the plugin is trying to add its own menus under 
the *File/Export...* menu.  But that's been renamed and is now *File/Export 
Files*.  The plugin code will have to change to match that name.  Even 
better would be for the plugin to insert its own menu item with its 
submenus.  Then it won't fail the next time there's a menu name change.

What is the latest release where you know it worked?

On Monday, May 13, 2024 at 12:35:09 PM UTC-4 chr...@gmail.com wrote:

*...and it's a major-urgent-pain-in-the-neck for me!*

- None of the plugin submenus appear in the File > Export Files... menu
- The plugin is correctly enabled in myLeoSettings.leo
- There is no "@bool leo_to_html_no_menus = True" anywhere

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/032ae6d1-d34b-4598-add7-77bf483b4f1cn%40googlegroups.com.

Re: A Script To Display The Viewrendered3 Pane in the Same Place s The Body

[Thomas Passin]

On Monday, May 13, 2024 at 10:00:58 AM UTC-4 Edward K. Ream wrote:

On Sunday, May 12, 2024 at 4:17:19 PM UTC-5 tbp1...@gmail.com wrote:

I have devised a script that can [swap the body and VR3 panes].  You can 
put it into a button for easy activation, or you could make it into a 
command in the Settings tree and bind it to a keystroke. 


Thomas, your private email on this topic was a Eureka moment for me. I 
realized that we Leo devs aren't aware of the hierarchy of Leo's Qt widgets.


That's a understatement! - at least for me...  It explains why I had so 
much trouble discovering when the body editor was created, by whom, and 
what frame it is put into.  Your printout is stunningly complex.
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5646e000-c731-4959-8a56-15f62e63be1an%40googlegroups.com.

Re: A Script To Display The Viewrendered3 Pane in the Same Place s The Body

[Thomas Passin]

Thank you, Lewis, much appreciated!

I'll be posting an improved version of the script later today. I've already 
added it as a vr3- command and button to my own MyLeoSettings.leo outline.

On Monday, May 13, 2024 at 3:31:23 AM UTC-4 lewis wrote:

> Thomas,
> Thanks for the script. I really appreciate the effort you have put into 
> improving the VR3 functionality.
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/266124b7-63d0-4bd6-8f9b-b0a44ed17bc2n%40googlegroups.com.

Re: A Script To Display The Viewrendered3 Pane in the Same Place s The Body

[Thomas Passin]

Attached is an example of rendering mixed text and graphics - in this case 
we are rendering a UML diagram using Asciidoc and PlantUML (PlantUML is 
basically a plugin for the external Asciidoctor).


On Sunday, May 12, 2024 at 5:17:19 PM UTC-4 Thomas Passin wrote:

Recently we have had discussions about how Trillum (and some other 
applications) can render graphics and text together.  Some of these 
applications have outlines and even clones similar to how Leo uses them.  A 
number of people have said that they wish that Leo could do the same.  
[...]
When this script has been used, the other ways of showing and hiding the 
VR3 pane don't work.  I will see if there is a way to work around this 
without needing to change VR3's code.  In the meantime, give the script 
below a try.  You can copy it to a new node in your Workbook and create a 
button for it.


It turns out that as long as you use one of the other ways to open VR3 
first, before using this new script, then the script doesn't interfere with 
them.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9a80c5ed-9f17-4fa6-9885-c51469300878n%40googlegroups.com.

A Script To Display The Viewrendered3 Pane in the Same Place s The Body

[Thomas Passin]

Recently we have had discussions about how Trillum (and some other 
applications) can render graphics and text together.  Some of these 
applications have outlines and even clones similar to how Leo uses them.  A 
number of people have said that they wish that Leo could do the same.  

Here are two of the discussion threads:
A Leo relative in the wild: Trilium Notes 

ENB: VR panes and the NestedSplitter plugin 


Typically one can edit in an editing view or display a fully rendered view 
that you don't edit directly.

In the discussion I pointed out that the Viewrendered3 plugin can take care 
of the mixed rendering tasks. You need to learn a bit of Markdown or 
RestructuredText (or Asciidoc) and then you can embed images, math 
formulas, and so on.  It would be possible to write scripts to simplify 
some of these details, but it's pretty easy as is.  With VR3 you have an 
additional pane for the VR3 display.  To make it more like Trillium, etc., 
and to save screen real estate, the VR3 display should display on top of 
the body pane.  You would swap it in or out depending on whether you want 
to edit or not.

I have devised a script that can do this swap.  You can put it into a 
button for easy activation, or you could make it into a command in the 
Settings tree and bind it to a keystroke.  With a tiny change to the script 
it will work for the Viewrendered plugin as well (but not in current *devel* 
versons).  
But VR has a more limited range for rendering that VR3.

When this script has been used, the other ways of showing and hiding the 
VR3 pane don't work.  I will see if there is a way to work around this 
without needing to change VR3's code.  In the meantime, give the script 
below a try.  You can copy it to a new node in your Workbook and create a 
button for it.

@language python
"""Toggles the body frame between the body editor and
a Viewrendered3 rendered view.
"""
from leo.core.leoQt import QtWidgets
import leo.plugins.viewrendered3 as v3

flc = c.free_layout  # free layout controller
top = flc.get_top_splitter()
if top:
bfw = top.find_child(QtWidgets.QWidget, "bodyFrame")
kids = bfw.children()

qf0 = kids[0]
stacked_layout = qf0.children()[0]

h = c.hash()
if stacked_layout.count() == 1:
v3.controllers[h] = vr3 = v3.ViewRenderedController3(c)
stacked_layout.addWidget(vr3)
vr3.show()
else:
vr3 = v3.controllers.get(h)

if stacked_layout.currentIndex() == 0:
stacked_layout.setCurrentWidget(vr3)
else:
stacked_layout.setCurrentIndex(0)


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e3f61ef9-7206-4420-8d43-b150cd557e91n%40googlegroups.com.

Big Ruff Speedup

[Thomas Passin]

The Ruff Python linter, written in Rust, has just gotten a big increase in 
speed.  They hand-wrote a new parser that's twice as fast as the old one:

The Ruff Anouncement 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/357915b1-9490-4fe8-b270-bfd213036770n%40googlegroups.com.

Re: ENB: VR panes and the NestedSplitter plugin

[Thomas Passin]

On Friday, May 10, 2024 at 1:13:54 PM UTC-4 Edward K. Ream wrote:

On Friday, May 10, 2024 at 8:47:46 AM UTC-5 Thomas wrote:

Going by last night's devel rev, VR was close to working as expected when I 
used the toggle command, at least with the particular layout I was using 
when I tried it.


That's good to know.


Turns out it was only for one particular layout.   When I tried other 
outlines that used different layouts VR didn't open right over the body 
pane.  I've set up a shortcut, ALT-F10, to toggle VR on and off so it's 
easy for me to try out.

I originally thought of replacing the body pane with a QStackedWidget or 
QTabbedWidget that would contain the body editor.  The VR/VR3 widget would 
go into one of the other slots.  That's how I do it with Freewin, and 
opening VR3 and my bookmark manager in tabs in the Log frame.  But I got a 
little lost, with all the nested frames, where to make that change and 
still make sure all the editor gets initialized correctly, the signals get 
hooked up right, hand have and the method signature and return types stay 
the same .  This splitter approach is probably better once we figure out 
the geometry.

 

The branch for this PR, though, was a mess so I'm looking forward to your 
new approach.


I'm not sure what you mean by a mess. PR #3906 
 cleans up a lot of 
cruft.


When I toggled VR's visibility, a new blank pane opened up outside Leo's 
main window, and the new pane never got populated.
 

In any case, there will still be work to do *after* the intermediate PR 
#3906  gets merged 
into devel and PR #3892 
. Let's take things 
one step at a time and test each step thoroughly.


The tricky part seems to be how to get the layout we want given that the 
starting layouts can be very different, even as to the number of panes as 
well as their arrangement.  The VR pane needs to move over the body and and 
adopt its size without changing the position of any of the existing 
splitter bars.
 

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9f4d5729-b858-435d-9c40-901cedfd7549n%40googlegroups.com.

Re: ENB: VR panes and the NestedSplitter plugin

[Thomas Passin]

Going by last night's devel rev, VR was close to working as expected when I 
used the toggle command, at least with the particular layout I was using 
when I tried it.  The branch for this PR, though, was a mess so I'm looking 
forward to your new approach.  Hopefully I will be able to adapt it to VR3 
too, since this part of the code started out the same.

On Friday, May 10, 2024 at 5:58:50 AM UTC-4 Edward K. Ream wrote:

> This Engineering Notebook post discusses issues with the nested_splitter 
> (NS) plugin uncovered two days ago while working on #3892 
> : Add VR commands 
> to cover/uncover the body pane. I've been considering what to do ever since.
>
> *tl;dr*: See the Summary.
>
> *Background*
>
> PR #3893  is a 
> thorough revision of the VR plugin. This PR leaves the VR3 plugin unchanged.
>
> Late-stage testing revealed that Leo's caches were not restoring the ratio 
> between the body and VR panes. A* lengthy *investigation showed that the 
> caching code was not to blame.  Instead, the culprit is the 
> *LeoQtFrame.ratio* property, aka *c.frame.ratio*. 
>
> The PR adds the VR pane in a way that breaks the c.frame.ratio property. 
> After several days of noodling, I suspect this property is not well-defined!
>
> *Remedies*
>
> First, I'll replace the ratio properties with explicit calls to two new 
> methods, say *c.frame.compute_ratio* and *c.frame.compute_secondary_ratio*. 
> There is no need to obscure where the computations happen! 
>
> Second, I'll attempt to fix the computations. This work will likely 
> involve changes to the nested_splitter plugin. For example, the primary and 
> secondary splitters should have well-defined names. Computing the ratios 
> should depend on the names of various splitters, not their containment 
> relationships. Why? Because the NS plugin can change those relationships!
>
> *What I won't do*
>
> I don't want to change the PR to accommodate the NS plugin. That would 
> have the tail wag the dog. Instead, 
> c.frame.compute_ratio and c.frame.compute_secondary_ratio should produce 
> correct results in all situations.
>
> *Summary*
>
> Leo's Qt gui defines two (hard-to-find!!) and buggy properties: 
> *c.frame.ratio* and *c.frame.secondary_ratio*. I suspect these properties 
> are not well-defined!
>
> For clarity, Leo's Qt code will use two new methods instead: 
> *c.frame.compute_ratio* and *c.frame.compute_secondary_ratio*. These 
> methods may use enhancements to the NestedSplitter class. All aspects of 
> this work are experimental.
>
> The existing properties must remain for compatibility. However, each 
> property will print a deprecation warning the first time scripts call them.
>
> All your questions and comments are welcome.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/00acaa74-c1f9-454a-a505-d893a2ad3848n%40googlegroups.com.

Re: TLA+: Format Verification Language And Toolkit

[Thomas Passin]

Darn, the title was supposed to say "*Formal* Verification ...".

On Thursday, May 9, 2024 at 10:17:01 AM UTC-4 Thomas Passin wrote:

> I always thought that formal verification (FV) of programs would be too 
> hard and error prone beyond simple programs.  Apparently I was wrong about 
> that, and one reason is that FV should be applied above the program level - 
> e.g., to algorithms.
>
> *"TLA+ is a language for modeling software above the code level and 
> hardware above the circuit level. It has an IDE (Integrated Development 
> Environment) for writing models and running tools to check them." * 
>
> Formal Verification With TLA+ 
> <https://lamport.azurewebsites.net/tla/high-level-view.html>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d18e09d1-8849-469a-a908-157c777b0095n%40googlegroups.com.

TLA+: Format Verification Language And Toolkit

[Thomas Passin]

I always thought that formal verification (FV) of programs would be too 
hard and error prone beyond simple programs.  Apparently I was wrong about 
that, and one reason is that FV should be applied above the program level - 
e.g., to algorithms.

*"TLA+ is a language for modeling software above the code level and 
hardware above the circuit level. It has an IDE (Integrated Development 
Environment) for writing models and running tools to check them." * 

Formal Verification With TLA+ 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9430e879-d3a3-4420-944d-e0c491faa147n%40googlegroups.com.

Re: How to Modify LeoJS From Within LeoJS?

[Thomas Passin]

On Friday, May 3, 2024 at 9:45:46 PM UTC-4 Félix wrote:

Thanks for this great question Thomas!

Lastly, *for modifying LeoJS itself *(instead of running scripts from 
custom @commands or @buttons, or building an extension and accessing the 
LeoJS global 'g' object) you would just need to clone the LeoJS repository. 
To then build and run it would be the same process as any of the VSCode 
sample extensions, such as this hello-world extension 
.
  
(That is to say, running the 'npm install' in the repository folder command 
to get all dependencies, and pressing F5 to start the 'run and debug' 
command in VSCode.)


This is where I lose track of what to do.  So far as I know up until now, 
an extension needs to packaged in a particular way with certain metadata.  
I only know how to install such packaged extensions from the marketplace.  
I suppose I need to know how to run an extension when one has not gone 
through all that packaging process and is not using the marketplace.  Of 
course, with Leo-Python you don't have to do anything special: the code is 
just there and you run it.

(BTW I have already cloned the repo).

Another aspect of running one's modified LeoJS code is how to *not* run the 
existing LeoJS (the marketplace extension) without de-installing it.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ac9e65e0-0047-42b0-ad7b-17d8a13470fan%40googlegroups.com.

Re: What The Ultimate Study On Happiness Reveals

[Thomas Passin]

I haven't watched it yet, but I am sure that many people labor under a 
mistaken notion.  Happiness isn't something that you achieve and then you 
just have it.  Happiness is a temporary condition, one that you get used to 
and it just recedes into the background, like a scent that you don't notice 
any more.  That can make a person think they aren't happy when they are 
just fine.

On Thursday, May 2, 2024 at 10:40:20 AM UTC-4 Edward K. Ream wrote:

> No matter how happy we are, it is good to know explicitly (and in detail) 
> what makes people happy.  And what doesn't.
>
> This video discusses the 
> science of happiness. It's worth watching twice, as I have just done.
>
> I highly recommend this video to everyone. Please pass it on.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a00e3893-ccd2-4458-b29a-241b42a56b7fn%40googlegroups.com.

How to Modify LeoJS From Within LeoJS?

[Thomas Passin]

Using Leo, we can edit LeoPyRef, save the edits, restart Leo, and test our 
changes.  With LeoJS, how can we do the equivalent: editing the code of 
LeoJS and testing it?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/22b921c0-a5f7-4817-a407-846e26f23eb4n%40googlegroups.com.

Re:  LeoJS Beta 0.2.13 Released

[Thomas Passin]

On Tuesday, April 30, 2024 at 10:46:00 AM UTC-4 Edward K. Ream wrote:

On Monday, April 29, 2024 at 9:41:57 AM UTC-5 Edward K. Ream wrote:

This release of LeoJS is a personal milestone. I shall work on the 
remaining *desktop* issues using LeoJS!


I can now recommend LeoJS without reservation! LeoJS supports all of Leo's 
essential features enhanced with vs-code's stupendous capabilities.


I can't go that far at this time because I depend on several GUI plugins 
I've written.  Maybe at some point I'll learn enough to port them to 
LeoJS...

Speaking of that, is there a plugin capability for LeoJS, or if not how 
would we do something equivalent? 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/7dc3e24c-59bf-40e4-8a39-63cf5602e96bn%40googlegroups.com.

Re:  LeoJS Beta 0.2.13 Released

[Thomas Passin]

On Tuesday, April 30, 2024 at 4:07:16 AM UTC-4 viktor@gmail.com wrote:

Hello Felix,

Félix schrieb am Dienstag, 30. April 2024 um 01:22:18 UTC+2:

Victor and Thomas (and other vscodium users)

As you can see from this link, https://open-vsx.org/extension/boltex/leojs 
the new version was successfully deployed on open-vsx, at around the same 
time I deployed it to Microsoft's marketplace.  

 
Yes, I was aware of that.
 

Not sure here, but I think the 'auto update' of vscodium's extensions might 
require a restart of vscodium. Even if you just opened it. (at startup it 
will detect a new version and download it but it will not 'restart' the 
extension with the new version.) The regular vscode also does that, but it 
does automatically update them. It's just that it needs to restart once it 
detects that a new version is available after boot up.


What was unexpected to me is that VSCodium did not notify me about the 
available update of the extension.


It was the same for me.  It has shown me updates for other extensions in 
the past, though.  I wonder if a recent update to vscodium broke that 
ability. 


What ( I think ) I did, is that I had to explicitly search for 'leo' in the 
extension view - and - only then it did show the notification & allowed me 
to install the update ...


I saw LeoJS in the extension  view but it didn't show an update was 
available.
 

And you are right that an explicit restart of VSCodium instance IS required 
- but - at least I did not have to re-install LeoJS as Thomas has reported.


I had restarted vscodium several times without any updates happening to 
LeoJS before I thought to un-install it first.
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8e2fc0f1-279b-4989-ace9-126d34c95162n%40googlegroups.com.

Re:  LeoJS Beta 0.2.13 Released

[Thomas Passin]

On Monday, April 29, 2024 at 7:22:18 PM UTC-4 Félix wrote:

Victor and Thomas (and other vscodium users)

As you can see from this link, https://open-vsx.org/extension/boltex/leojs 
the new version was successfully deployed on open-vsx, at around the same 
time I deployed it to Microsoft's marketplace.  


I have no idea how to use open-vsx...
 

Not sure here, but I think the 'auto update' of vscodium's extensions might 
require a restart of vscodium. Even if you just opened it. (at startup it 
will detect a new version and download it but it will not 'restart' the 
extension with the new version.) The regular vscode also does that, but it 
does automatically update them. It's just that it needs to restart once it 
detects that a new version is available after boot up.

... Or, maybe vscodium needs their extensions to be manually updated when a 
new version is published on their market. I'm not sure because I've never 
used  vscodium personally.


There's  a control to search for updates to the extensions at the top of 
the Explorer pane.  At the same place you can enable automatic refresh, 
which is enabled on my copy of vscodium.  Searching for updates says they 
are all up to date.  

I solved the problem by uninstalling LeoJS, then re-installing it.  I still 
had to "Restart Extensions" and then I had to restart vscodium. Finally, I 
now have 0.2.13 running in vscodium.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/41b9c99e-a2a5-4477-874e-18b11461e93en%40googlegroups.com.

Re:  LeoJS Beta 0.2.13 Released

[Thomas Passin]

Nice work and nice graphics!  VSCodium on my system doesn't know about this 
new version yet, I've still got 0.2.11.

I like the way that the new *Open Aside* works.  Trying it out, I noticed 
that it makes #104  more 
important.  That's because it's so easy to forget which node belongs to the 
Aside editor, and the new-style gnx-based identifiers don't help the user 
know which node it is.  Or if the path-based UNL is too long, at least show 
the node headline.

On Monday, April 29, 2024 at 6:13:42 AM UTC-4 Edward K. Ream wrote:

>
>
> On Sun, Apr 28, 2024 at 10:46 PM Félix  wrote:
>
> *Introducing LeoJS Beta 0.2.13* 
>
>
> Congratulations! I've been playing with LeoJS, and it looks great. I'll be 
> using LeoJS more now.
>
> LeoJS is already a viable alternative to desktop leo. 
>
> It will be valuable to compare the vs-code way with the Leo way as we 
> explore improving the VR pane.
>
> Love the graphics.  Candlelight on the console.  Hehe. Old old disk 
> format. Hilarious. I expected to see Chewbacca!
>
> Edward
>
> P.S. Some suggestions:
>
> Please fix #123  asap. 
>
> It's way too easy to miss the excellent demo movies! I suggest creating a 
> separate section in the readme just for the videos near the top so everyone 
> will be sure to see them.
>
> EKR
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2f43db4e-2048-46b9-ba8c-99d655c52b04n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

Once you have got this layout set up, you can save it, which makes it 
simple to apply it to any outline after that.

On Sunday, April 28, 2024 at 2:43:34 PM UTC-4 Thomas Passin wrote:

> It is possible to try out having VR/VR3 display in the same frame as the 
> body editor.  You can get them both into the Log frame.  It's not perfect 
> because anytime there is a message to the log, the view changes away from 
> the body or rendered view to the Log pane. Also you can't use the Find or 
> Nav panes and still see the body editor at the same time.  But it's kind of 
> a prototype.
>
> Here is how I set this up. There may be other ways. First, open the 
> splitter context menu by either right-clicking on one of the splitter bars 
> or from the *Window* menu.  Click on *Open Window* and select *Body*. A 
> new free-floating window will open with the body editor.  Close this new 
> window.  The body editor will reappear in the Tab pane.  Do the same thing 
> with VR or VR3, whichever you have enabled. - open a new window with it, 
> then close that window.  Or, if you are using VR3, issue the Minibuffer 
> command *vr3-toggle-tab *instead.
>
> If the log pane appears after this in the same frame as the tree, then use 
> the splitter context menu *Toggle Split Direction* to get it side-by-side 
> with the tree's frame.
>
> A screen shot illustrating this layout is attached
>
> On Sunday, April 28, 2024 at 7:48:28 AM UTC-4 Edward K. Ream wrote:
>
>> On Friday, April 26, 2024 at 2:50:16 PM UTC-5 Edward K. Ream wrote:
>>
>> > I'm convinced. Replacing the body pane is a preference worth 
>> considering.
>>
>> See #3892 <https://github.com/leo-editor/leo-editor/issues/3892>. The 
>> corresponding PR will make minimal changes to Leo's core and the VR and VR3 
>> plugins.
>>
>> Your comments, please.
>>
>> Edward
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/582519a2-5a4c-4e7c-a3e2-ce58f1329924n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

It is possible to try out having VR/VR3 display in the same frame as the 
body editor.  You can get them both into the Log frame.  It's not perfect 
because anytime there is a message to the log, the view changes away from 
the body or rendered view to the Log pane. Also you can't use the Find or 
Nav panes and still see the body editor at the same time.  But it's kind of 
a prototype.

Here is how I set this up. There may be other ways. First, open the 
splitter context menu by either right-clicking on one of the splitter bars 
or from the *Window* menu.  Click on *Open Window* and select *Body*. A new 
free-floating window will open with the body editor.  Close this new 
window.  The body editor will reappear in the Tab pane.  Do the same thing 
with VR or VR3, whichever you have enabled. - open a new window with it, 
then close that window.  Or, if you are using VR3, issue the Minibuffer 
command *vr3-toggle-tab *instead.

If the log pane appears after this in the same frame as the tree, then use 
the splitter context menu *Toggle Split Direction* to get it side-by-side 
with the tree's frame.

A screen shot illustrating this layout is attached

On Sunday, April 28, 2024 at 7:48:28 AM UTC-4 Edward K. Ream wrote:

> On Friday, April 26, 2024 at 2:50:16 PM UTC-5 Edward K. Ream wrote:
>
> > I'm convinced. Replacing the body pane is a preference worth considering.
>
> See #3892 . The 
> corresponding PR will make minimal changes to Leo's core and the VR and VR3 
> plugins.
>
> Your comments, please.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3bb6efc3-f2b2-480c-b8a8-7398355db595n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

On Friday, April 26, 2024 at 1:31:41 PM UTC-4 Edward K. Ream wrote:

The Easter Egg is the only way to expand the VR pane. An optional floating 
VR window would solve that problem.


Here you go:

ns = c.free_layout.get_top_splitter()
ns.open_window('_leo_viewrendered3')
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a9734be6-dc2c-44ee-adea-9310dead5cd3n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

I'm with you here.  Between VR3 and Freewin, I've tried floating windows, 
new frames, and rendering into a tab in the log frame.  Freewin has a 
switchable display (edit <-> render) and I find that convenient and easy to 
work with, even without a way to set the default to *render*. Having the 
body pane display style be switchable would work very well for me as a UI, 
should not be hard to implement, and would not preclude any of those other 
display modes.

On Friday, April 26, 2024 at 1:52:49 PM UTC-4 gates...@gmail.com wrote:

> Why would a floating window solve any problems here?  How are you 
> envisioning that a floating VR3 window, *which can already be done* *today 
> without any additional coding*, would help the situation?
>
> As a counterpoint, I only have a single display available to me.  I 
> generally do my work (in Leo) on a single desktop monitor, or a tiny laptop 
> screen.  In *both cases* I would much prefer a switchable pane, rather 
> than a floating window.  The current solution of VR eating up a third of 
> the screen by default, or of faffing about with a floating window (even 
> more irksome on a laptop with a touchpad), is such a poor UX that I avoid 
> it. Enough so that I've effectively stopped using Leo for anything that 
> needs to be rendered.
>
> Adding a first-class 'floating window' feature to VR/3 wouldn't fix any 
> issues.  It would strictly exacerbate the issue.  But a context-aware 
> switchable tab, which is eminently doable, would solve *every single one* 
> of my personal problems.  And I know it's a workable solution *because 
> I've done it*.
>
> Leo is, to me, an editor, an IDE, and a platform.  But it is increasingly 
> *not* an authoring tool for me, because of the current implementation of 
> VR.  And that's frustrating, because authoring any sort of complex 
> documentation *should be* where Leo shines, given the first-class 
> outlining and clones.
>
> Just my $0.02.  I wish we wouldn't just discard things out of hand because 
> of perceived 'dubiousness'.  Experimentation is fruitful, and painless, 
> given git branching.
>
> Jake
>
> On Fri, Apr 26, 2024 at 1:31 PM Edward K. Ream  wrote:
>
>> On Fri, Apr 26, 2024 at 11:49 AM Thomas Passin  wrote:
>>
>> >> Trilium undervalues the power of text:
>>
>> > I think that Edward does not appreciate how often users want to use Leo 
>> as a Notebook...
>>
>> I agree. Leonistas *should *be able to use lots of graphics :-) That's 
>> why improving the VR plugins and (maybe) the rst3 plugin seems like a good 
>> idea.
>>
>> > Trillium...shows you a rendered view of its nodes and makes it harder 
>> to edit and work with the content.
>>
>> > Leo makes it easy to edit and work with text, but harder to insert and 
>> look at rendered graphics, etc.
>>
>> That's a reasonable summary. A floating VR pane would be a step forward.
>>
>> > VR3 can display [jupyter] files using an @jupyter node type. Any text 
>> display would only show the raw html...
>>
>> Yes, sometimes the rendered view is preferable. But that's no reason to 
>> complicate Leo's interface.
>>
>> *Summary*
>>
>> The Easter Egg is the only way to expand the VR pane. An optional 
>> floating VR window would solve that problem.
>>
>> Edward
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/CAMF8tS1WZmuDxfRg8vU-oWsXKRZOoKSqn2ZP0cGX0Duw_5ys4A%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/leo-editor/CAMF8tS1WZmuDxfRg8vU-oWsXKRZOoKSqn2ZP0cGX0Duw_5ys4A%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/47847ae3-a0eb-45ef-993b-957beece1c2cn%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

On Friday, April 26, 2024 at 1:13:38 PM UTC-4 Edward K. Ream wrote:

On Fri, Apr 26, 2024 at 8:02 AM Thomas Passin wrote:

>> As an option, the VR pane could become a floating window. 

> This is already possible, at least with VR3.  With VR3 enabled, right 
click on the boundary between two frames to get the splitter menu.  Select 
*Window* then *VR3*.  VR3 opens in a new floating window.  

Surely this can be done w/o Terry's Easter Egg.


I wouldn't call it an Easter Egg, exactly, because it's not really hidden.  
But it's awkward to use.  It seems to me that whatever command is called by 
the final splitter menu selection - if we can figure out what it is - 
should be callable by some other means.  I'd rather do that than mess with 
the VR3 code at this stage.  BTW, you can open a standard body editing pane 
as a separate window in the same way.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/64ab1c7c-3594-436a-847d-e61a1343bbe5n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

On Friday, April 26, 2024 at 7:45:11 AM UTC-4 Edward K. Ream wrote:

This Engineering Notebook post contains second thoughts about Trilium Notes.

*Trilium's weaknesses*

Trilium undervalues the power of text:

I think that Edward does not appreciate how often users want to use Leo as 
an *Notebook* as opposed to a *writing* tool.  For a notebook, one wants to 
include all kinds of material, text and graphics, and then *look at and 
read* it many times.  For writing, developing code, and so on one mostly 
wants to *edit and read text*. Trillium by default, it seems to me, shows 
you a rendered view of its nodes and makes it harder to edit and work with 
the content.  Leo makes it easy to edit and work with text, but harder to 
insert and look at rendered graphics, etc.

An example is those Mermaid diagrams.  Leo can't currently use Mermaid, but 
it can create and render Plantum diagrams, which are somewhat similar, 
using VR3 with Asciidoc.  It's necessary to install a stand-alone Asciidoc 
engine with the right plugins, but it's very feasible.  Once created, I at 
least would like to see a series of diagrams rendered.  The text view would 
be useless, and it's unlikely I would be changing the diagrams once 
perfected.  Seeing the textual source would be a distraction.

Think about how Jupyter notebooks are usually used.  It's great to be able 
to develop your code in one, complete with graphics and notes.  But once 
developed, they are generally shared as a set of HTML  files, and only 
looked at not edited.  VR3 can display those files using an @jupyter node 
type.  Any text display would only show the raw html, which is essentially 
useless and distracting to look at.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6af83645-d756-4029-b1c4-5e4fa93f4db9n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

On Friday, April 26, 2024 at 7:45:11 AM UTC-4 Edward K. Ream wrote:

This Engineering Notebook post contains second thoughts about Trilium 
Notes. 

*tl;dr:* Leo might add only *incremental *improvements inspired by Trilium 
Notes. All fundamental aspects of Leo will remain as they are.

*Summary*

*Changing the rendering of Leo's body pane is a dubious idea.* Instead:

- As an option, the VR pane could become a floating window.

This is already possible, at least with VR3.  With VR3 enabled, right click 
on the boundary between two frames to get the splitter menu.  Select 
*Window* then *VR3*.  VR3 opens in a new floating window.  Presumably if 
only VR were enabled you could do the same (untested). The whole procedure 
is a little awkward but presumably could be made to work from a command or 
button.

[Aside - this capability is a tribute to the people who worked up the 
splitter mechanism (was that Terry Brown?).  Plugins like VR3 were not 
written with any code to become free-floating windows, but the basic plugin 
mechanism automatically makes them available to the splitter machinery, 
which can do the job.]

I have found that using a view like VR3 in a separate window is not as 
useful as I would like because window overlaps obscure too much.  It would 
work fairly well with a very wide monitor.  Freewin is also a freefloating 
window, and it can switch between text and rendered views, but the expected 
usage lends itself better to using several narrower windows next to the 
main Leo window.  Freewin was intended mostly for comparing two nodes while 
being live with its underlying host node so that the host can be edited 
while looking at the comparison node.

- The VR pane could use a modular architecture based on plugins. I look 
forward to discussing this topic with Thomas.

VR/VR3 basically work in a way that could be more modularized, I would 
think.  Basically, the plugin must:
1. Figure out what kind of node it is looking at, usually by page 
directives like *@language;*
2. Send the contents of the node or subtree to some appropriate code that 
transforms it into HTML;
3. Send the HTML to a rendering engine;  This is normally the Qt WebEngine 
widget (for VR3) but could be something else.  As an alternative, for a 
node with computer code the code can be extracted and sent to a code engine 
for execution.  VR3 can collect and display or execute all the code chunks 
even if they are separated by non-code parts (so VR3 can do literate 
programming basically for free).

- Leo's rst3 command might support VR-related nodes.

I'm not sure just what this means - "VR-related nodes".  VR3 can already 
render an rst tree because it can (optionally) render any subtree.  So you 
can get an approximation of what your document will look like, including 
any graphics. I use this capability when I author a Sphinx document.  It's 
very handy. But it is limited because some internal links and other 
features have to be created by Sphinx after the rst3 command has been 
issued so you can't get a fully complete rendering just from the Leo nodes.

I welcome all comments.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c81dac45-fec8-4f9b-9a31-6debcea505a4n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

On Thursday, April 25, 2024 at 1:55:38 PM UTC-4 Thomas Passin wrote:

On Thursday, April 25, 2024 at 1:25:21 PM UTC-4 Thomas Passin wrote:

>From an architectural point of view, the current Leo editor widget could 
get replaced by a widget with several child widgets (a tabbed widget is one 
possibility), of which one is the current editor widget, and most keyboard 
and mouse input will go to it no matter whether the text or rendering 
widget is visible.  This plan would require minimal changes to the rest of 
Leo's code.


Once we have such a widget,  VR3 could render right to it, just as it does 
now to a log pane tab. VR3 may not be exactly what we want to end up with 
in the long run, but going this route would very quickly give us a working 
prototype to get experience with.  The approach is to make the rendering 
widget in the new node display widget be VR3's rendering widget.


We already have such a widget and all the machinery we need!  It's the Log 
frame.  We create a frame like the Log frame but with the LeoQt edit widget 
instead of the Log widget.  We put this frame into the location that 
currently holds the edit widget.  We use the same technique to insert the 
VR3 widget into the Log frame but instead we put it into the new 
Edit/Render frame.  This would require no changes to VR3 or the LeoQt edit 
widget.

If all goes well we could even have a prototype working in hours, or days 
at the most.  Most of the work would be in constructing the Edit/Render 
frame (based on the Log frame), and setting it up when a commander is 
constructed.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ac51e552-92c3-41bc-8887-1a6f8c2bcc18n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

On Thursday, April 25, 2024 at 1:25:21 PM UTC-4 Thomas Passin wrote:

>From an architectural point of view, the current Leo editor widget could 
get replaced by a widget with several child widgets (a tabbed widget is one 
possibility), of which one is the current editor widget, and most keyboard 
and mouse input will go to it no matter whether the text or rendering 
widget is visible.  This plan would require minimal changes to the rest of 
Leo's code.


Once we have such a widget,  VR3 could render right to it, just as it does 
now to a log pane tab. VR3 may not be exactly what we want to end up with 
in the long run, but going this route would very quickly give us a working 
prototype to get experience with.  The approach is to make the rendering 
widget in the new node display widget be VR3's rendering widget.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5eb10299-5e92-4e0d-a334-f93a13a6e4e9n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

We are really on the same page here!

On Thursday, April 25, 2024 at 12:39:33 PM UTC-4 Edward K. Ream wrote:

On Thursday, April 25, 2024 at 6:57:17 AM UTC-5 Thomas wrote:

Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, 
we could overlay the rendering frame over the editing frame. We could 
switch in and out of rendering mode to allow editing.  I bet that wouldn't 
be too hard.

Thomas, you may have solved a problem that has bedeviled me for ages! Here 
are my first thoughts:

I've never liked the VR pane. It seems like a significant waste of real 
estate.

I completely agree about the real estate.  Almost always, I display VR3 
renderings in a tab in the log pane just for this reason even though the 
view is smaller.  I have a button to toggle the VR3 tab on and off.  When 
off, the delay after each few keystrokes for rendering is not incurred, so 
the button gets used a lot.  BTW, whether in a separate frame or in a tab 
in the log frame, the VR3 display will update as you type.  The same is 
true in freewin if you toggle to the rendered view (you don't type into the 
freewin window, you type into the parent node in the main Leo window).

Edit modes are confusing, but *visual modes* will work! Here are some 
preliminary thoughts:

*Rendering modes*

Both headlines and body text will specify a *default rendering mode* for 
*each *node:

I have been thinking exactly this.  We have to make sure that the defaults 
do the right thing almost all the time so that people who don't care, and 
legacy outlines, work right without needing to change.

- Headlines like @movie and @html (and all the others that VR and VR3 
support) would set the default rending mode to some graphics mode.

- Otherwise, @language directives will specify the preferred rendering 
mode, usually *text mode*. However, @language rst would specify *rst mode*.

Exactly; remember that VR3 can handle multiple (software) languages in a 
node (only one rendering language per node, though, i.e., RsT, Md, etc.).  
 It would be nice not to lose that ability.  VR3 can also execute the code 
in a node that has intermixed code and non-code sections.

- A possibility: *@rst-tree* in the headline would specify that the 
rendered contents would consist of the node's body and the bodies of all 
descendant nodes.

Tricky - a long subtree can incur too long a rendering time, or too much 
scrolling, especially when graphics are involved.  That's why VR3 has a 
menu item to render a subtree or only the current node.  I bet we could 
come up with a nearly painless way to do the same, but I have found that I 
want to sometimes see the node and sometimes the tree - so I don't think 
that *@rst-tree* is a good way to go.

*Switching modes*

The *toggle-rendering-mode* command will toggle between the *default *and 
*alternate *rendering modes. Text mode will always be one of those modes.

Users are unlikely to become confused about which mode is in effect because 
graphics look very different from text. If confusion does arise, *graphics 
icons* could mark graphics-capable nodes.

Agree. Again, most of the code we need is already working in VR3 and/or 
freewin.  Mainly we need to work out how to provide the overlay frame, and 
how to provide good user controls for switching between text and rendered 
views.

I assume that this capability will be built into the core, since it will 
involve multiple widgets where now there is only an editing widget. We 
should eventually make sure that there is an extension mechanism (via 
plugins) so that people can add new graphic renderings without needing to 
touch core Leo code.

>From an architectural point of view, the current Leo editor widget could 
get replaced by a widget with several child widgets (a tabbed widget is one 
possibility), of which one is the current editor widget, and most keyboard 
and mouse input will go to it no matter whether the text or rendering 
widget is visible.  This plan would require minimal changes to the rest of 
Leo's code.

*Summary*

Rendering body text as either text or graphics seems like a natural idea. 
Why didn't I ever think of this before? And how did we ever live without it?

The *toggle-rendering-mode* command will toggle between graphics and text 
views.
Users are unlikely to become confused about what body panes contain. 

Rendering either text or graphics in the body pane:
- Significantly increases Leo's effective real estate.
- Promises to give Leo the visual capabilities of the most sophisticated 
outliners.

Today is a milestone in Leo's history. And there is further room for 
invention!

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

This sounds pretty much what I had in mind.  The freewin plugin actually 
does the same (in its own separate window). VR/VR3 also replace the 
rendering widget type depending on what is to be rendered.  Currently VR3 
can optionally render to a tab in the log frame instead of to a new frame 
within the overall Leo window.  So we're not far off.

On Thursday, April 25, 2024 at 8:37:59 AM UTC-4 gates...@gmail.com wrote:

> I actually implemented something similar in a private 'leoapp' (app that 
> lives in a .leo file) I wrote for myself a few years back.  Pretty simple 
> to get done, IIRC.
>
> My general pattern was to have a controller class that contained two 
> 'view' widgets (a QTextBrowser for rendered HTML, and a QTextEdit for 
> editing).  The controller class had a wrapper widget that also had an 
> 'edit' toggle button.  When 'edit' is clicked, a callback is fired off to 
> remove the active view widget and replace it with the new one (and set some 
> state in the controller so it doesn't lose track of things).  Content is 
> updated between the two widgets whenever this swap happens.  Internally 
> they are two completely different objects, but to the user, the swap is 
> fairly seamless.
>
> I did write this app relying on PyQt5, unfortunately, so I have a fair bit 
> of updating to do if I want it to work on modern Leo.  Ah well.
>
> Jake
>
> On Thu, Apr 25, 2024 at 8:10 AM Edward K. Ream  wrote:
>
>>
>>
>> On Thu, Apr 25, 2024 at 6:57 AM Thomas Passin  wrote:
>>
>>> Except that standard Leo nodes don't render graphics and other non-text 
>>> items.  That's a big difference. We get around it to a degree with VR/VR3.  
>>> Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, 
>>> we could overlay the rendering frame over the editing frame. We could 
>>> switch in and out of rendering mode to allow editing.  I bet that wouldn't 
>>> be too hard. One way would be to use a 2-frame tabbed widget.  Leo would 
>>> then have no disadvantage compared with Trillium and its ilk, and would 
>>> keep all of its advantages.
>>>
>>> Yowee!
>>>
>>
>> I'm interested. Let's see what you can do.
>>
>> Edward
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/CAMF8tS2oz4FPGXyuztu8e%3DpA3_vLG3DCF2x24p1FM_kSrRPJKw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/leo-editor/CAMF8tS2oz4FPGXyuztu8e%3DpA3_vLG3DCF2x24p1FM_kSrRPJKw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2903cdcc-8f76-456a-9723-f448afecba32n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

See new issue Allow VR/VR3-style rendering overlaid on standard editing 
nodes <https://github.com/leo-editor/leo-editor/issues/3887>.

On Thursday, April 25, 2024 at 8:10:51 AM UTC-4 Edward K. Ream wrote:

> On Thu, Apr 25, 2024 at 6:57 AM Thomas Passin  wrote:
>
>> Except that standard Leo nodes don't render graphics and other non-text 
>> items.  That's a big difference. We get around it to a degree with VR/VR3.  
>> Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, 
>> we could overlay the rendering frame over the editing frame. We could 
>> switch in and out of rendering mode to allow editing.  I bet that wouldn't 
>> be too hard. One way would be to use a 2-frame tabbed widget.  Leo would 
>> then have no disadvantage compared with Trillium and its ilk, and would 
>> keep all of its advantages.
>>
>> Yowee!
>>
>
> I'm interested. Let's see what you can do.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3335ebeb-a416-4d23-bf4e-1e741956ee5cn%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

Except that standard Leo nodes don't render graphics and other non-text 
items.  That's a big difference. We get around it to a degree with VR/VR3.  
Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, 
we could overlay the rendering frame over the editing frame. We could 
switch in and out of rendering mode to allow editing.  I bet that wouldn't 
be too hard. One way would be to use a 2-frame tabbed widget.  Leo would 
then have no disadvantage compared with Trillium and its ilk, and would 
keep all of its advantages.

Yowee!

On Thursday, April 25, 2024 at 5:12:02 AM UTC-4 Edward K. Ream wrote:

> On Thu, Apr 25, 2024 at 3:49 AM Christoph  wrote:
>
> Of course, dealing with hierarchical data sooner or later requires a 
>> mechanism that allows to put data in more than one branch of the 
>> hierarchy so this seems to be a logical step. However, Leo has taken 
>> this step more than 20 years ago and made it its fundamental design 
>> feature.
>>
>
> And Leo has way better programming features, including c, g, p, 
> generators, @others, @clean, and the Mulder/Ream update algorithm.
>
> I'm not worried about competition, and Félix is several years ahead of 
> would-be imitators.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0589aa0a-96a9-4a47-9531-ac40397f5d56n%40googlegroups.com.

Re: Current Devel Branch Fails To Start Using Python 3.9

[Thomas Passin]

Lucky I've still got Python 3.9 on my machine!

On Wednesday, April 24, 2024 at 11:02:34 AM UTC-4 Edward K. Ream wrote:

> On Wed, Apr 24, 2024 at 9:30 AM Thomas Passin  wrote:
>
>> py -3.9 -m leo.core.runLeo
>> ... 
>>from leo.core import leoVim
>>   File "C:\Tom\git\leo-editor\leo\core\leoVim.py", line 25, in 
>> from typing import Any, TypeAlias, TYPE_CHECKING
>> ImportError: cannot import name 'TypeAlias' from 'typing' (C:\Program 
>> Files\Python39\lib\typing.py)
>>
>> This changeset does run using Python 3.10 and up.
>>
>
> Thanks for this report, Thomas.  See #3884 
> <https://github.com/leo-editor/leo-editor/issues/3884>. I'll fix this 
> immediately.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/55b95cee-f57e-47a0-bcaf-414e3744c79fn%40googlegroups.com.

Current Devel Branch Fails To Start Using Python 3.9

[Thomas Passin]

py -3.9 -m leo.core.runLeo
... 
   from leo.core import leoVim
  File "C:\Tom\git\leo-editor\leo\core\leoVim.py", line 25, in 
from typing import Any, TypeAlias, TYPE_CHECKING
ImportError: cannot import name 'TypeAlias' from 'typing' (C:\Program 
Files\Python39\lib\typing.py)

This changeset does run using Python 3.10 and up.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4f70543c-7bee-4820-9f4e-1634282ed7c6n%40googlegroups.com.

Re: Leo shortcut on windows fail with devel branch

[Thomas Passin]

You can see what would get installed with requirements.txt by adding the 
flag --dry-run. pip will go through the motions but not actually install 
anything.  For example, I just ran py -m pip install -r requirements.txt 
--dry-run and got this report:

Would install Send2Trash-1.8.3 cffi-1.16.0 coverage-7.4.4 
cryptography-42.0.5 pycparser-2.22 pytest-cov-5.0.0 ruff-0.4.1 
types-Markdown-3.6.0.20240316 types-PyYAML-6.0.12.20240311 
types-docutils-0.20.0.20240406 types-paramiko-3.4.0.20240311 
types-requests-2.31.0.20240406 types-six-1.16.21.20240311

Looks Like some of my packages need updating.
On Monday, April 22, 2024 at 5:58:06 AM UTC-4 Edward K. Ream wrote:

> On Sun, Apr 21, 2024 at 7:55 PM Félix  wrote:
>
> Searching for ' leo-message ' in Leo's codebase, I see the 'leo-message' 
>> script is mentioned in 'running.html' 
>>
>
> Thanks, Thomas, for your help.
>
> And thanks, Félix for reporting this problem. This glitch is what Viktor 
> asked about several days ago. It bit you because, yes, Leo's requirements 
> *did* recently change. Thankfully, that's a rare event.
>
> and also in 'add-desktop-links.leox'. 
>>
>
> I failed to find this file yesterday because I searched for 'leo-message' 
> as a filename rather than as the contents of a file.
>
> And now I see why this file isn't in LeoPyRef.leo: the file 
> leo/scripts/desktop-integration.leo contains `@file` nodes for the .leox 
> file above and two other related .leox files.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0e1d78b0-8522-4da4-9821-01484a5dc50en%40googlegroups.com.

Re: Leo shortcut on windows fail with devel branch

[Thomas Passin]

On Sunday, April 21, 2024 at 7:05:08 PM UTC-4 Félix wrote:

After trying to simply install pyqt6, I get yet another error when trying 
to launch: *cannot import name 'QtWebEngineCore' from 'PyQt6'*


It's in a separate package from PyQt6.  Requirements.txt should get it 
installed. 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/37cf3651-8f3c-4cd7-8b86-480993a94550n%40googlegroups.com.

Re: Leo shortcut on windows fail with devel branch

[Thomas Passin]

py -m pip install -r requirements.txt

On Sunday, April 21, 2024 at 9:05:10 PM UTC-4 Félix wrote:

> Weird, i'm getting that -r is not an option... I'll investigate further... 
> [image: Untitled.png]
>
>
>
> On Sunday, April 21, 2024 at 8:55:57 PM UTC-4 Félix wrote:
>
>> Thanks Edward,
>>
>> Searching for ' leo-message ' in Leo's codebase, I see the 'leo-message' 
>> script is mentioned in 'running.html' 
>>
>> and also in 'add-desktop-links.leox'. 
>>
>> Félix
>> On Sunday, April 21, 2024 at 7:32:29 PM UTC-4 Edward K. Ream wrote:
>>
>>>
>>>
>>> On Sun, Apr 21, 2024 at 5:37 PM Félix  wrote:
>>>
>>> > I had to revert to the master branch on my windows pc to get the 
>>> shortcut to work.
>>>
>>> leo-messages.exe probably isn't nefarious, but it sure is mysterious.
>>>
>>> Running *pip -r requirements.txt* should install the missing dependency.
>>>
>>> Edward
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/f5a799ac-8c06-4ed9-bd8a-3365a95b0c56n%40googlegroups.com.

Re: MACOS M2 Ventura

[Thomas Passin]

I'm glad to hear it, Geoff.

The bigger question is how to make sure other Mac users can learn about 
this.  I doubt that Leo's install system could make the required changes, 
so how can we inform users?  I don't have a Mac and don't know much about 
them.

On Thursday, April 11, 2024 at 6:51:09 AM UTC-4 Geoff Evans wrote:

> Thanks Thomas,
> When I worked up the courage to adjust my qt.conf file as suggested, 
> everything worked! :-)
> I'll have to get used to the options living at the top of the main screen 
> and not the top of the leo window.  But that's a minor issue.
>
> geoff
>
> On Sunday 7 April 2024 at 05:39:32 UTC-2:30 Edward K. Ream wrote:
>
>>
>>
>> On Sat, Apr 6, 2024 at 6:27 AM Thomas Passin  wrote:
>>
>>> Solved in
>>>
>>>
>>> https://stackoverflow.com/questions/76898551/qt-qpa-plugin-could-not-find-the-qt-platform-plugin-cocoa-in
>>
>>
>> Thanks for your help, Thomas.
>>
>> Edward
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e89821c6-82a7-4066-9f4f-855ee0f05e04n%40googlegroups.com.

Jon Udell On Using LLMs With Your Code Base To Help Write Documentation

[Thomas Passin]

Jon Udell's LLM saga continues -

Code in Context: How AI Can Help Improve Our Documentation 


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a6aaff86-49bb-40db-935d-1124a65f9652n%40googlegroups.com.

Re: MACOS M2 Ventura

[Thomas Passin]

Solved in

https://stackoverflow.com/questions/76898551/qt-qpa-plugin-could-not-find-the-qt-platform-plugin-cocoa-in

On Saturday, April 6, 2024 at 2:05:23 AM UTC-4 Edward K. Ream wrote:

> On Mon, Apr 1, 2024 at 5:58 AM Geoff Evans  wrote:
>
>> I've tried to get leo via pip:
>>
>> pip install pyqt6 leo
>>
>> but when I try to run it I get:
>>
>>  ~/WXP/OGMAP/now/base > leo ogmap.leo 
>> qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in ""
>> This application failed to start because no Qt platform plugin could be 
>> initialized. Reinstalling the application may fix this problem.
>>
>> The obvious "pip install cocoa" didn't help.  Any ideas?
>>
>
> Not really. Did you try pip install pyqt6 first?
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8d1a23b5-a188-45e4-bebb-c3a7cb8f5130n%40googlegroups.com.

Re: Script to expand toolbar

[Thomas Passin]

Better, I think: background-color: @text-foreground; This should work for 
any (dark) color theme. If you omit the #qt_toolbar_ext_button, the style 
will get applied to the menubar's "menu-indicator" also, as well as any 
other toolbar (yes, the menubar also has an overflow indicator, if you can 
see it).  This is most likely what one wants.

On Wednesday, April 3, 2024 at 12:47:35 PM UTC-4 Edward K. Ream wrote:

> On Wednesday, April 3, 2024 at 9:56:16 AM UTC-5 Edward K. Ream wrote:
>
> Googling shows that the QToolbar class has inherent limitations. There is *no 
> way* to split QToolButton widgets into separate rows. 
>
>
> This statement is misleading. The easiest workaround is to assign 
> buttons/widgets to *multiple* QToolbar instances.
>
> And one can probably use QLayouts to control placement of toolbar items.
>
> But I'll leave all such issues to the interested reader, hehe.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4faf3b44-001a-4679-b853-87e720b7b271n%40googlegroups.com.

Re: Script to expand toolbar

[Thomas Passin]

It's not just a black background that hides it.  There must be a css 
selector for it, mustn't there? 

On Wednesday, April 3, 2024 at 10:56:16 AM UTC-4 Edward K. Ream wrote:

> On Wednesday, April 3, 2024 at 4:54:32 AM UTC-5 Edward K. Ream wrote:
>
> It took me a while to understand what the @button node is doing.
>
> ...
>
> I'm satisfied neither with #407 
>  nor with the 
> script. I would prefer some ways of splitting the icon bar at specific 
> places. I have just created #3851 
> .
>
>
> Alright, I think I understand the bounds of the problem.
>
>
> Googling shows that the QToolbar class has inherent limitations. There is *no 
> way* to split QToolButton widgets into separate rows. Happily, the 
> toolbar shows an *extension icon* on the far right when there are too 
> many buttons. Clicking this icon will show the remaining widgets on 
> separate lines. The newly revealed icons *remain visible* until the user 
> clicks the extension icon again.
>
>
> I never noticed this behavior before. Worse, my dark theme obscured the 
> extension icon! I've corrected that bug by giving the icon a lighter 
> background color.
>
>
> *@button expand-toolbar*
>
>
> This script needs more explanation. The script creates a button that 
> duplicates the purpose of the extension icon. The script (@button node) 
> does nothing if everything in the icon bar is already visible.
>
>
> The script simulates a *single* keypress (and release) on the extension 
> icon. Therefore, the newly revealed icons will *remain visible* until the 
> user presses the button (or the actual extension icon).
>
>
> The test:  if w.objectName() == 'qt_toolbar_ext_button':
>
>
> looks for the name that Qt assigns to the expansion icon. This name *has 
> nothing to do with the headline of the @button node!*
>
>
> *Summary*
>
>
> At long last, I understand the inherent limitations of the QToolbar 
> widget. There seems to be no way to split its contents into separate 
> (always visible) lines.
>
>
> Otoh, the extension icon shows all widgets when clicked and *continues to 
> do so* until clicked again. This behavior is good enough for most 
> purposes.
>
>
> I've corrected my dark theme to show the extension icon. The icon must not 
> have a black background.
>
>
> The given @button script works, but it needs some explanation. I'll amend 
> #3851  accordingly.
>
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/bf2cc648-946f-4784-bc1d-59366014037fn%40googlegroups.com.

Re: LeoJS Status Report & Video Demo/Tutorial

[Thomas Passin]

Felix, I appreciate all the work but I'm not able to work with the intro 
video.  Everything happens too fast and I think you do some things that are 
not visible.  For example, you somehow open a Preview pane that can render 
Markdown.  I'd like to do that. I have to guess that you got to it by a 
right mouse click, but when I right click in the body pane I don't get a 
menu item to open a preview.  The video doesn't give me any guidance about 
how to set that up.

It's similar with the Git integration.  There are just too many things to 
take in during the time that a drag takes place, and then something else 
happens that there also isn't time to take in.

If things were slowed down and there were more titles or explanatory text 
the video would be much more helpful.  I know that making these videos is 
time-consuming and has a large learning curve - that's why I haven't tried 
making my own! Please don't take these comments as criticizing your work - 
I'm just trying to be helpful. 

On Sunday, March 31, 2024 at 4:30:18 PM UTC-4 Félix wrote:

> The sample Leo scripts shown in the video are collected in this github 
> repository: https://github.com/boltex/scripting-samples-leojs
>
> The sample "LeoJS-Plugin" extension shown in the video also has its own 
> github repository at: https://github.com/boltex/extension-sample-leojs
>
> On Sunday, March 31, 2024 at 4:28:00 PM UTC-4 Félix wrote:
>
>> *LeoJS Status Report*
>>
>> After stabilizing the beta version, now reaching its twelfth revision at 
>> 0.2.12, and getting rid of its most obvious bugs and defects, I thought it 
>> would be a good moment to address the questions posed on this forum about 
>> the possible features and capabilities of LeoJS by producing a video 
>> demonstration.
>>
>> This took a bit longer than I would have thought, months instead of 
>> weeks, but nevertheless, here it is!
>>
>> https://www.youtube.com/watch?v=M_mKXSbVGdE
>>
>> *This five-minute video quickly goes over each of the following:*
>>
>>- Using LeoJS on the web
>>- Commits & pull requests from VSCode's UI
>>- Running Leo scripts in LeoJS
>>- Interacting with the UI from scripts (Sample scripts)
>>- Creating a plugin/extension that uses LeoJS (Sample extension)
>>- Invoking commands, using the minibuffer and @buttons
>>- Using a @settings node
>>- UNL link support
>>- Previewing live render of SVG (or markdown, etc.) external files
>>
>> Hoping this will answer most questions the experienced leonistas had 
>> about LeoJS being able to reproduce the original Leo's functionalities from 
>> within VSCode.
>>
>> *Last but not least: I've also remade the classic 'Introduction to Leo' 
>> video with LeoJS! *
>>
>> https://www.youtube.com/watch?v=j0eo7SlnnSY
>>
>> Hope you like those two videos!
>>
>> I'll now focus on the very last few remaining LeoJS issues and features 
>> needed for a proper 1.0 version release of LeoJS. (Hopefully this spring!) 
>>
>> Félix
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/7ccae901-b661-490b-a9d2-be746ae95aden%40googlegroups.com.

Re: I just had successful eye surgury

[Thomas Passin]

Sorry to hear this.  Best wishes for a quick and full recovery!

On Thursday, March 28, 2024 at 4:03:52 PM UTC-4 Edward K. Ream wrote:

> A vitrectomy 
> of
>  
> the rt eye. I'll be limited in what I can do for about a week.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9ca2247e-d7ac-44cd-9c6e-d680f05874f1n%40googlegroups.com.

Re: Please test the ekr-2882-qt-only2 branch

[Thomas Passin]

I got the same results using the qt-only2 branch.

On Wednesday, March 27, 2024 at 7:49:52 PM UTC-4 Thomas Passin wrote:

> Oops, the last two were tested with devel, not the qt-only-2 branch..  
> I'll have to go back and repeat the test.
>
> On Wednesday, March 27, 2024 at 3:57:11 PM UTC-4 Thomas Passin wrote:
>
>> Some more Linux results:
>> ubuntu
>> nav, console ok.  vr3 image problem
>> XUbuntu
>> nav, console ok.  vr3 image problem
>>
>> OpenSUSE
>> needs libQt6WebEngineCore6, libQt6Quick6
>> After installing them, Leo still couldn't start.  Those libQt6xx
>> libraries were installed by zypper to /usr/lib64 but pyqt6
>> wants version `Qt_6_PRIVATE_API' 
>>
>> Fedora
>> seems ok, vr3 images seem ok
>>
>> On Monday, March 25, 2024 at 12:51:20 PM UTC-4 Edward K. Ream wrote:
>>
>>> On Monday, March 25, 2024 at 6:37:36 AM UTC-5 Edward K. Ream wrote:
>>>
>>> The "ekr-2882-qt-only2" branch is ready for testing. See PR #3828 
>>> <https://github.com/leo-editor/leo-editor/pull/3828>.
>>>
>>>
>>> This PR is a milestone: it removes all vestiges of Qt5 from Leo's 
>>> codebase. As a result, much stronger mypy annotations are possible, but 
>>> improved annotations will be the subject of a follow-on PR.
>>>
>>>
>>> A recent rev makes the QSci module optional for the time being. This rev 
>>> also improves the message that appears if Leo fails to load.
>>>
>>> I'll fix the nits Thomas has reported and merge the PR later today or 
>>> tomorrow.
>>>
>>> Edward
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c72a21af-ef88-4832-85a8-c62efbe80ff4n%40googlegroups.com.

Re: Please test the ekr-2882-qt-only2 branch

[Thomas Passin]

Oops, the last two were tested with devel, not the qt-only-2 branch..  I'll 
have to go back and repeat the test.

On Wednesday, March 27, 2024 at 3:57:11 PM UTC-4 Thomas Passin wrote:

> Some more Linux results:
> ubuntu
> nav, console ok.  vr3 image problem
> XUbuntu
> nav, console ok.  vr3 image problem
>
> OpenSUSE
> needs libQt6WebEngineCore6, libQt6Quick6
> After installing them, Leo still couldn't start.  Those libQt6xx
> libraries were installed by zypper to /usr/lib64 but pyqt6
> wants version `Qt_6_PRIVATE_API' 
>
> Fedora
> seems ok, vr3 images seem ok
>
> On Monday, March 25, 2024 at 12:51:20 PM UTC-4 Edward K. Ream wrote:
>
>> On Monday, March 25, 2024 at 6:37:36 AM UTC-5 Edward K. Ream wrote:
>>
>> The "ekr-2882-qt-only2" branch is ready for testing. See PR #3828 
>> <https://github.com/leo-editor/leo-editor/pull/3828>.
>>
>>
>> This PR is a milestone: it removes all vestiges of Qt5 from Leo's 
>> codebase. As a result, much stronger mypy annotations are possible, but 
>> improved annotations will be the subject of a follow-on PR.
>>
>>
>> A recent rev makes the QSci module optional for the time being. This rev 
>> also improves the message that appears if Leo fails to load.
>>
>> I'll fix the nits Thomas has reported and merge the PR later today or 
>> tomorrow.
>>
>> Edward
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/dfdbda83-4082-4f30-ae27-b08c091706fan%40googlegroups.com.

Re: Please test the ekr-2882-qt-only2 branch

[Thomas Passin]

Some more Linux results:
ubuntu
nav, console ok.  vr3 image problem
XUbuntu
nav, console ok.  vr3 image problem

OpenSUSE
needs libQt6WebEngineCore6, libQt6Quick6
After installing them, Leo still couldn't start.  Those libQt6xx
libraries were installed by zypper to /usr/lib64 but pyqt6
wants version `Qt_6_PRIVATE_API' 

Fedora
seems ok, vr3 images seem ok

On Monday, March 25, 2024 at 12:51:20 PM UTC-4 Edward K. Ream wrote:

> On Monday, March 25, 2024 at 6:37:36 AM UTC-5 Edward K. Ream wrote:
>
> The "ekr-2882-qt-only2" branch is ready for testing. See PR #3828 
> .
>
>
> This PR is a milestone: it removes all vestiges of Qt5 from Leo's 
> codebase. As a result, much stronger mypy annotations are possible, but 
> improved annotations will be the subject of a follow-on PR.
>
>
> A recent rev makes the QSci module optional for the time being. This rev 
> also improves the message that appears if Leo fails to load.
>
> I'll fix the nits Thomas has reported and merge the PR later today or 
> tomorrow.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/f870519a-8f06-4003-bc87-7c0a8ba9d71en%40googlegroups.com.

Re: Please test the ekr-2882-qt-only2 branch

[Thomas Passin]

Both Nav and Python Console are present on Linux Manjaro. Also, on Debian 
and Mint, if VR3 tries and fails to display an image, it stops working 
until Leo is restarted.  This hasn't happened as yet on Manjaro.

Lint is derived from Debian.  I wonder if they have something in common 
that's related?

On Monday, March 25, 2024 at 9:49:55 AM UTC-4 Edward K. Ream wrote:

> On Mon, Mar 25, 2024 at 8:45 AM Thomas Passin  wrote:
>
> Nav tab is missing on Debian, Python Console tab is missing on Linux 
>> Mint.  No apparent error messages.
>>
>
> Thanks for your testing!  Now I'll definitely delay the merge.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c097efbe-2dbb-4129-81bc-191f9fc82f18n%40googlegroups.com.

Re: Please test the ekr-2882-qt-only2 branch

[Thomas Passin]

Nav tab is missing on Debian, Python Console tab is missing on Linux Mint.  
No apparent error messages.

On Monday, March 25, 2024 at 9:25:25 AM UTC-4 Thomas Passin wrote:

> What is Leo using QScintilla for?
>
> On Monday, March 25, 2024 at 9:21:00 AM UTC-4 Thomas Passin wrote:
>
>> That took care of the problem and the branch of Leo now runs on Ubuntu.  
>> Also, VR3 opens.
>>
>> On Monday, March 25, 2024 at 9:05:18 AM UTC-4 Edward K. Ream wrote:
>>
>>> On Mon, Mar 25, 2024 at 7:47 AM Thomas Passin  wrote:
>>>
>>>> Fails on Ubuntu:
>>>>
>>>> *cannot import name 'Qsci' from 'PyQt6' 
>>>> (/home/tom/.local/lib/python3.10/site-packages/PyQt6/__init__.py)*
>>>>
>>>
>>> Good catch. My apologies for the confusion.
>>>
>>> This is a documentation error or a "transition" problem, depending on 
>>> your point of view.
>>>
>>> It's easy to fix: *pip install PyQt6-QScintilla *
>>>
>>> I say this is a transition problem because requirements.txt now 
>>> includes PyQt6-QScintilla.
>>>
>>> There's no automatic way to avoid the extra dependency. Otoh, Leo 6.7.9 
>>> will provide the dependency automatically.
>>>
>>> *Summary*
>>>
>>> *Everyone *who uses GitHub should run *pip install PyQt6-QScintilla *
>>>
>>> Edward
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b6bd6ecb-f58c-487c-abac-96af26336f5an%40googlegroups.com.

Re: Please test the ekr-2882-qt-only2 branch

[Thomas Passin]

What is Leo using QScintilla for?

On Monday, March 25, 2024 at 9:21:00 AM UTC-4 Thomas Passin wrote:

> That took care of the problem and the branch of Leo now runs on Ubuntu.  
> Also, VR3 opens.
>
> On Monday, March 25, 2024 at 9:05:18 AM UTC-4 Edward K. Ream wrote:
>
>> On Mon, Mar 25, 2024 at 7:47 AM Thomas Passin  wrote:
>>
>>> Fails on Ubuntu:
>>>
>>> *cannot import name 'Qsci' from 'PyQt6' 
>>> (/home/tom/.local/lib/python3.10/site-packages/PyQt6/__init__.py)*
>>>
>>
>> Good catch. My apologies for the confusion.
>>
>> This is a documentation error or a "transition" problem, depending on 
>> your point of view.
>>
>> It's easy to fix: *pip install PyQt6-QScintilla *
>>
>> I say this is a transition problem because requirements.txt now includes 
>> PyQt6-QScintilla.
>>
>> There's no automatic way to avoid the extra dependency. Otoh, Leo 6.7.9 
>> will provide the dependency automatically.
>>
>> *Summary*
>>
>> *Everyone *who uses GitHub should run *pip install PyQt6-QScintilla *
>>
>> Edward
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6e75ccf4-d024-490c-af54-938b014a8c19n%40googlegroups.com.

Re: Please test the ekr-2882-qt-only2 branch

[Thomas Passin]

That took care of the problem and the branch of Leo now runs on Ubuntu.  
Also, VR3 opens.

On Monday, March 25, 2024 at 9:05:18 AM UTC-4 Edward K. Ream wrote:

> On Mon, Mar 25, 2024 at 7:47 AM Thomas Passin  wrote:
>
>> Fails on Ubuntu:
>>
>> *cannot import name 'Qsci' from 'PyQt6' 
>> (/home/tom/.local/lib/python3.10/site-packages/PyQt6/__init__.py)*
>>
>
> Good catch. My apologies for the confusion.
>
> This is a documentation error or a "transition" problem, depending on your 
> point of view.
>
> It's easy to fix: *pip install PyQt6-QScintilla *
>
> I say this is a transition problem because requirements.txt now includes 
> PyQt6-QScintilla.
>
> There's no automatic way to avoid the extra dependency. Otoh, Leo 6.7.9 
> will provide the dependency automatically.
>
> *Summary*
>
> *Everyone *who uses GitHub should run *pip install PyQt6-QScintilla *
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/bb69f912-6aa9-4cb7-9ea3-76681ef9aeean%40googlegroups.com.

Re: Please test the ekr-2882-qt-only2 branch

[Thomas Passin]

Fails on Ubuntu:

*cannot import name 'Qsci' from 'PyQt6' 
(/home/tom/.local/lib/python3.10/site-packages/PyQt6/__init__.py)*

*** Leo could not be started ***

Please verify you've installed the required dependencies:



On Monday, March 25, 2024 at 7:37:36 AM UTC-4 Edward K. Ream wrote:

> The "ekr-2882-qt-only2" branch is ready for testing. See PR #3828 
> .
>
>
> This PR is a milestone: it removes all vestiges of Qt5 from Leo's 
> codebase. As a result, much stronger mypy annotations are possible, but 
> improved annotations will be the subject of a follow-on PR.
>
>
> Thomas has raised three minor issues about this PR. I'll resolve these 
> issues before merging the PR. I thank Thomas for his careful review.
>
>
> I'll merge this PR later today or tomorrow. We'll continue our testing 
> after the merge.
>
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/264dc3e9-8db1-400c-8c79-5e830db2ae90n%40googlegroups.com.

Re: About PR #3828: Require Qt6.6+

[Thomas Passin]

Every one of my fleet of Linux VMs has finally got PyQt 6.6, so that's 
favorable. No one can prove that *every* distro will have it - there are 
just too many variations - but so be it.  I don't know about ARM versions 
and don't have a way to check, but I suppose they are still not a likely 
host for Leo.

On Sunday, March 24, 2024 at 8:17:29 AM UTC-4 Edward K. Ream wrote:

> I am now working on PR #3828 
> : require Qt 6.6+. 
> This PR is experimental and possibly controversial.
>
>
> *The good news*
>
>
> - leoQt.py contains no conditional imports. 
>
> - leoQt.py defines all constants unambiguously.
>
> - No Qt-related switches exist*.* Hurray! Removing these switches 
> (especially isQt5 and isQt6) simplifies code throughout Leo.
>
>
> *The controversial news*
>
>
> Four Qt modules no longer exist in Qt6: *phonon*, *QtDeclarative*, 
> *QtWebKit*, and *QtWebKitWidgets*. As a result, I have retired five of 
> Terry Brown's plugins. There is no obvious way to make these plugins work 
> with Qt6. 
>
>
> *Summary*
>
>
> PR #3828  removes all 
> vestiges of Qt5 from Leo's codebase. Now is probably a good time to move to 
> Qt6. Leo 6.7.8 installs only Qt6 without anyone complaining :-)
>
>
> A one-line change to requirements.txt installs all necessary Qt6 modules. 
> There is no need for conditional code in leoQt.py.
>
>
> Five plugins are incompatible with Qt6 and have been retired to the attic: 
> *notebook.py*, *richtext.py*, and three "editpane" plugins: 
> *pandownview.py*, *webengineview.py*, and *webkitview.py*. These plugins 
> are no great loss. They do not work with the typical installation of Leo 
> 6.7.8.
>
>
> Please tell me what you think.
>
>
> Edward
>
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/43c0e3d7-615b-42a7-91e0-3153986d9cd7n%40googlegroups.com.

Re: A Script To Insert An Image

[Thomas Passin]

It's still a good question, though.  Is there an actual use for a setting 
of type "@path"?Having it included in that documentation section seems 
to imply that there is, though its inclusion may have been meant only as a 
syntax example. Can anyone resolve this?

On Sunday, March 24, 2024 at 8:24:47 AM UTC-4 Edward K. Ream wrote:

> On Sun, Mar 24, 2024 at 7:01 AM Thomas Passin  wrote:
>
>> Settings and headlines are not the same.
>>
>
> At last I understand :-)  As Thomas says, the syntax for settings nodes is 
> different from directives.
>
> In other words, Leo's documentation appears to be correct.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/68e70299-1e4a-45eb-b7b2-31aa9bced5can%40googlegroups.com.

Re: A Script To Insert An Image

[Thomas Passin]

Settings and headlines are not the same.

On Sunday, March 24, 2024 at 6:39:03 AM UTC-4 jkn wrote:

> Hi Edward
> I put the link (to a different part of the documentation) in an earlier 
> post: 
> https://leo-editor.github.io/leo-editor/customizing.html#simple-settings-nodes
>
> The section you reference is clear, and correct. The link above perhaps 
> references an older syntax?
>
> Regards, J^n
>
>
> On Sunday, March 24, 2024 at 10:27:45 AM UTC Edward K. Ream wrote:
>
>> On Sun, Mar 24, 2024 at 4:20 AM jkn  wrote:
>>
>>>
>>> I am commenting on the fact that the documentation says that an @path 
>>> directive (and all the others in the table below) takes the form
>>>
>>> @path **=** my/path
>>>
>>> whereas in fact no equals sign is necessary (any might well cause an 
>>> error?)
>>>
>>> @path  my/path
>>>
>>
>> I see no equal sign in Leo's directive reference 
>>  page. What 
>> documentation are you talking about?
>>
>> Edward
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c367b9f6-6c96-4a8d-8e49-173d4f9f5c3an%40googlegroups.com.

Re: A Script To Insert An Image

[Thomas Passin]

en run with an image in the (global) clipboard, it saves this to a 
>>>>>> local timestamped file (under ~/tmp), and indicates how a markdown 
>>>>>> reference to that file could be inserted.
>>>>>>
>>>>>> There's plenty more needed but this is the QClipboard part, I think.
>>>>>>
>>>>>> import os
>>>>>> import time
>>>>>> 
>>>>>> def unique_png_fname():
>>>>>> """ return a unique (timestamped) filename to use
>>>>>> """
>>>>>> FORMAT="%Y-%m-%d-%H-%M-%S.png"
>>>>>> return time.strftime(FORMAT)
>>>>>>
>>>>>> def link_string_md(fname):
>>>>>> """ get markdown format to insert a filename
>>>>>> """
>>>>>> return "![[%s]]" % fname
>>>>>>
>>>>>> def main():
>>>>>> # get clipboard contents - default mode is global clipboard
>>>>>> cb = g.app.gui.qtApp.clipboard()
>>>>>> # is it in image format?
>>>>>> img = cb.image()
>>>>>> if not img.isNull():
>>>>>> basefiledir = os.path.expanduser("~/tmp")
>>>>>> fqfilepath = os.path.join(basefiledir, unique_png_fname())
>>>>>> img.save(fqfilepath, "PNG")
>>>>>> g.es("wrote clipboard to:", fqfilepath)
>>>>>> g.es("could insert:", link_string_md(fqfilepath))
>>>>>> else:
>>>>>> g.es("clipboard not in image format")
>>>>>>
>>>>>> main()
>>>>>>
>>>>>>
>>>>>> On Monday, March 11, 2024 at 8:23:42 PM UTC jkn wrote:
>>>>>>
>>>>>>> Doh! should have read the documentation better.
>>>>>>>
>>>>>>> you have to test for a 'null image' using eg. img.isnull()
>>>>>>>
>>>>>>> on with my trivial experiments...
>>>>>>>
>>>>>>>
>>>>>>> On Monday, March 11, 2024 at 8:10:03 PM UTC jkn wrote:
>>>>>>>
>>>>>>>> Has anyone played much with class QClipboard? I did a couple of 
>>>>>>>> trivial experiments but I must be misunderstanding something.
>>>>>>>>
>>>>>>>> for instance, QClipboard.image() returns a non-null value even if 
>>>>>>>> the clipboard does not contain an image.
>>>>>>>>
>>>>>>>> J^n
>>>>>>>>
>>>>>>>>
>>>>>>>> On Monday, March 11, 2024 at 4:33:23 PM UTC tbp1...@gmail.com 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> It turns out that to get the relative path conversion w have to 
>>>>>>>>> remove any quotation marks around the path before running 
>>>>>>>>> os.relpath(). So 
>>>>>>>>> the script becomes:
>>>>>>>>>
>>>>>>>>> """Insert RsT code at cursor to display an image.
>>>>>>>>>
>>>>>>>>> The path to the image file will come from a file dialog.
>>>>>>>>> This action is undoable.
>>>>>>>>> """
>>>>>>>>> PATH = g.app.gui.runOpenFileDialog(c,
>>>>>>>>> title="Import File",
>>>>>>>>> filetypes=[("All files", "*"),],
>>>>>>>>> defaultextension=".*",
>>>>>>>>> multiple=False)
>>>>>>>>>
>>>>>>>>> if PATH:
>>>>>>>>> from os.path import relpath
>>>>>>>>> PATH = PATH.replace('"', '').replace("'", '')
>>>>>>>>> PATH = relpath(PATH)
>>>>>>>>> PATH = PATH.replace('\\', '/')
>>>>>>>>>
>>>>>>>>> IMAGE_TEMPLATE = f'''
>>>>>>>>>
>>>>>>>>> .. figure:

Re: A Script To Insert An Image

[Thomas Passin]

yed much with class QClipboard? I did a couple of 
>>>>> trivial experiments but I must be misunderstanding something.
>>>>>
>>>>> for instance, QClipboard.image() returns a non-null value even if the 
>>>>> clipboard does not contain an image.
>>>>>
>>>>> J^n
>>>>>
>>>>>
>>>>> On Monday, March 11, 2024 at 4:33:23 PM UTC tbp1...@gmail.com wrote:
>>>>>
>>>>>> It turns out that to get the relative path conversion w have to 
>>>>>> remove any quotation marks around the path before running os.relpath(). 
>>>>>> So 
>>>>>> the script becomes:
>>>>>>
>>>>>> """Insert RsT code at cursor to display an image.
>>>>>>
>>>>>> The path to the image file will come from a file dialog.
>>>>>> This action is undoable.
>>>>>> """
>>>>>> PATH = g.app.gui.runOpenFileDialog(c,
>>>>>> title="Import File",
>>>>>> filetypes=[("All files", "*"),],
>>>>>> defaultextension=".*",
>>>>>> multiple=False)
>>>>>>
>>>>>> if PATH:
>>>>>> from os.path import relpath
>>>>>> PATH = PATH.replace('"', '').replace("'", '')
>>>>>> PATH = relpath(PATH)
>>>>>> PATH = PATH.replace('\\', '/')
>>>>>>
>>>>>> IMAGE_TEMPLATE = f'''
>>>>>>
>>>>>> .. figure:: {PATH}
>>>>>> :scale: 50%
>>>>>>
>>>>>> '''
>>>>>>
>>>>>> w = c.frame.body.wrapper
>>>>>> p = c.p
>>>>>> s = p.b
>>>>>> u = c.undoer
>>>>>>
>>>>>> start, _ = w.getSelectionRange()
>>>>>>
>>>>>> undoType = 'insert-rst-image-code'
>>>>>> undoData = u.beforeChangeNodeContents(p)
>>>>>>
>>>>>> head, tail = s[:start], s[start:]
>>>>>> p.b = head + IMAGE_TEMPLATE + tail
>>>>>>
>>>>>> c.setChanged()
>>>>>> p.setDirty()
>>>>>> u.afterChangeNodeContents(p, undoType, undoData)
>>>>>> c.redraw()
>>>>>>
>>>>>> On Saturday, March 9, 2024 at 2:04:19 PM UTC-5 Thomas Passin wrote:
>>>>>>
>>>>>>> We can't directly insert an image into a standard Leo node because 
>>>>>>> they are text-only.  I find this very annoying sometimes, especially 
>>>>>>> when I 
>>>>>>> am writing a note and want to include an image.  
>>>>>>>
>>>>>>> But we can do the next best thing - insert an ReStructuredText (RsT) 
>>>>>>> instruction to display an image so that we can view it with the 
>>>>>>> viewrendered3 plugin (VR3). The instruction is short and easy, but it's 
>>>>>>> still annoying to type and I usually forget the exact details. I have a 
>>>>>>> button that toggles VR3 on and off so that it's easy to view an 
>>>>>>> embedded 
>>>>>>> image once the RsT instruction is there. An embedding command would 
>>>>>>> make 
>>>>>>> embedding with Leo as easy as embedding an image in a word processor.  
>>>>>>>  Aha, this is Leo, let's write a script!
>>>>>>>
>>>>>>> Here is a script that pops up a file dialog and inserts a relative 
>>>>>>> path to the chosen file.  There are several small variations which I 
>>>>>>> discuss after the code.
>>>>>>>
>>>>>>> """Insert RsT code at cursor to display an image.
>>>>>>>
>>>>>>> The path to the image file will come from a file dialog.
>>>>>>> This action is undoable.
>>>>>>> """
>>>>>>> PATH = g.app.gui.runOpenFileDialog(c,
>>>>>>> title="Import File",
>>>>>>> filetypes=[("All files", "*"),],
>>>>>>> defaultextension=".*",
>>>>>>> multiple=False)
>>>>>>>
>>>>>>> if PATH:
>>>>>>> from os.path import relpath
>>>>>>> PATH = relpath(PATH)
>>>>>>> PATH = PATH.replace('\\', '/').replace('"', '').replace("'", '')
>>>>>>> IMAGE_TEMPLATE = f'''
>>>>>>>
>>>>>>> .. figure:: {PATH}
>>>>>>> :scale: 50%
>>>>>>>
>>>>>>> '''
>>>>>>> w = c.frame.body.wrapper
>>>>>>> p = c.p
>>>>>>> s = p.b
>>>>>>> u = c.undoer
>>>>>>>
>>>>>>> start, _ = w.getSelectionRange()
>>>>>>>
>>>>>>> undoType = 'insert-rst-image-code'
>>>>>>> undoData = u.beforeChangeNodeContents(p)
>>>>>>>
>>>>>>> head, tail = s[:start], s[start:]
>>>>>>> p.b = head + IMAGE_TEMPLATE + tail
>>>>>>>
>>>>>>> c.setChanged()
>>>>>>> p.setDirty()
>>>>>>> u.afterChangeNodeContents(p, undoType, undoData)
>>>>>>> c.redraw()
>>>>>>>
>>>>>>> Variations:
>>>>>>> 1.  If you want an absolute path instead of a relative path, delete 
>>>>>>> the lines
>>>>>>> from os.path import relpath
>>>>>>> PATH = relpath(PATH)
>>>>>>> with
>>>>>>>
>>>>>>> 2. If you  want to get the path from the clipboard instead of a file 
>>>>>>> dialog, replace the lines
>>>>>>>
>>>>>>> PATH = g.app.gui.runOpenFileDialog(c,
>>>>>>> title="Import File",
>>>>>>> filetypes=[("All files", "*"),],
>>>>>>> defaultextension=".*",
>>>>>>> multiple=False)
>>>>>>>
>>>>>>> with the line 
>>>>>>>
>>>>>>> PATH = g.app.gui.getTextFromClipboard()
>>>>>>>
>>>>>>> 3. If you want the embedded image to be full width instead of 50%, 
>>>>>>> delete the line
>>>>>>>
>>>>>>> :scale: 50%
>>>>>>>
>>>>>>> 4. You can make this work with Markdown or Asciidoc by using their 
>>>>>>> embedding instruction in the TEMPLATE instead of the RsT one.
>>>>>>>
>>>>>>> I have added the command to my own local menu.  VR3 can open in a 
>>>>>>> tab in the log pane; the command for toggling in a tab is 
>>>>>>> *vr3-toggle-tab. * I usually like opening it in the log pane 
>>>>>>> instead of in its own separate pane.
>>>>>>>
>>>>>>> If you would like to create a local menu of your own and don't know 
>>>>>>> how, it's easy.  Just ask and I'll show what to add to 
>>>>>>> myLeoSettings,leo.
>>>>>>>
>>>>>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/22a3e7ff-0914-4615-9c72-03b88eef96d5n%40googlegroups.com.

Re: A Script To Insert An Image

[Thomas Passin]

Looks pretty straightforward.  Perhaps you'll want to make it undoable (so 
far as Leo is concerned).  As a matter of Python programming, defining a 
main() function here isn't needed.  If you are only going to use it as a 
script, then you don't need a function at all. Just unindent those lines of 
code (and delete the "main()" line) and they will run when the script 
runs.  No need to call main() at all.   If you want that clipboard part of 
the block to run and if it succeeds then insert the markdown text into a 
node, then the function shouldn't be called "main" but something more 
descriptive.

On Saturday, March 23, 2024 at 4:59:25 PM UTC-4 jkn wrote:

> OK, here is a simple demonstration of part of the feature I am interested 
> in.
>
> When run with an image in the (global) clipboard, it saves this to a local 
> timestamped file (under ~/tmp), and indicates how a markdown reference to 
> that file could be inserted.
>
> There's plenty more needed but this is the QClipboard part, I think.
>
> import os
> import time
> 
> def unique_png_fname():
> """ return a unique (timestamped) filename to use
> """
> FORMAT="%Y-%m-%d-%H-%M-%S.png"
> return time.strftime(FORMAT)
>
> def link_string_md(fname):
> """ get markdown format to insert a filename
> """
> return "![[%s]]" % fname
>
> def main():
> # get clipboard contents - default mode is global clipboard
> cb = g.app.gui.qtApp.clipboard()
> # is it in image format?
> img = cb.image()
> if not img.isNull():
> basefiledir = os.path.expanduser("~/tmp")
> fqfilepath = os.path.join(basefiledir, unique_png_fname())
> img.save(fqfilepath, "PNG")
> g.es("wrote clipboard to:", fqfilepath)
> g.es("could insert:", link_string_md(fqfilepath))
> else:
> g.es("clipboard not in image format")
>
> main()
>
>
> On Monday, March 11, 2024 at 8:23:42 PM UTC jkn wrote:
>
>> Doh! should have read the documentation better.
>>
>> you have to test for a 'null image' using eg. img.isnull()
>>
>> on with my trivial experiments...
>>
>>
>> On Monday, March 11, 2024 at 8:10:03 PM UTC jkn wrote:
>>
>>> Has anyone played much with class QClipboard? I did a couple of trivial 
>>> experiments but I must be misunderstanding something.
>>>
>>> for instance, QClipboard.image() returns a non-null value even if the 
>>> clipboard does not contain an image.
>>>
>>> J^n
>>>
>>>
>>> On Monday, March 11, 2024 at 4:33:23 PM UTC tbp1...@gmail.com wrote:
>>>
>>>> It turns out that to get the relative path conversion w have to remove 
>>>> any quotation marks around the path before running os.relpath(). So the 
>>>> script becomes:
>>>>
>>>> """Insert RsT code at cursor to display an image.
>>>>
>>>> The path to the image file will come from a file dialog.
>>>> This action is undoable.
>>>> """
>>>> PATH = g.app.gui.runOpenFileDialog(c,
>>>> title="Import File",
>>>> filetypes=[("All files", "*"),],
>>>> defaultextension=".*",
>>>> multiple=False)
>>>>
>>>> if PATH:
>>>> from os.path import relpath
>>>> PATH = PATH.replace('"', '').replace("'", '')
>>>> PATH = relpath(PATH)
>>>> PATH = PATH.replace('\\', '/')
>>>>
>>>> IMAGE_TEMPLATE = f'''
>>>>
>>>> .. figure:: {PATH}
>>>> :scale: 50%
>>>>
>>>> '''
>>>>
>>>> w = c.frame.body.wrapper
>>>> p = c.p
>>>> s = p.b
>>>> u = c.undoer
>>>>
>>>> start, _ = w.getSelectionRange()
>>>>
>>>> undoType = 'insert-rst-image-code'
>>>> undoData = u.beforeChangeNodeContents(p)
>>>>
>>>> head, tail = s[:start], s[start:]
>>>> p.b = head + IMAGE_TEMPLATE + tail
>>>>
>>>> c.setChanged()
>>>> p.setDirty()
>>>> u.afterChangeNodeContents(p, undoType, undoData)
>>>> c.redraw()
>>>>
>>>> On Saturday, March 9, 2024 at 2:04:19 PM UTC-5 Thomas Passin wrote:
>>>>
>>>>> We can't directly in

Re: Leo 6.7.8 released to pypi

[Thomas Passin]

I've tried out installing post3 on my fleet of Linux VMs.  It succeeded on 
all of them although for some I had to add the pip install option 
*--break-system-packages.  
*After installation, there was a also new "leo" script that launched Leo.  
So it looks like all Edward's hard work has paid off. The install command 
was:

python3 -m pip install --user --upgrade leo

Here is the list of distros I tried:

debian 22.04
fedora
manjaro
mint
opensuse
ubuntu
xubuntu

On Thursday, March 21, 2024 at 4:59:37 PM UTC-4 Edward K. Ream wrote:

>  Leo 6.7.8.post3 is now working as expected in an existing 'venv' w/i a 
>> Fedora 38 VM !
>>
>
> Excellent. Thanks for your testing :-)
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b2165288-6be5-47fe-97f8-0c5fd2ac7e6an%40googlegroups.com.