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: glitches installing and starting Leo

[andyjim]

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? 
On Wednesday, May 15, 2024 at 9:20:40 PM UTC-4 tbp1...@gmail.com wrote:

> 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/7f50ef51-ea2b-488a-a689-8e82f7ff78e0n%40googlegroups.com.

Re: Status report re PR #3911

[Edward K. Ream]

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/25125524-e031-4ed3-bedf-6bb0a05aaf2cn%40googlegroups.com.

Re: Status report re PR #3911

[Edward K. Ream]

On Thursday, May 16, 2024 at 9:49:43 AM UTC-5 Thomas wrote:

I'm very enthusiastic about this work.  It will eventually be a real boon 
to users and developers, I'm sure.


Glad you like the concept.
 

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 true "forever". 
Otoh, my hope is that eventually nobody will notice (or care) if the two 
plugins go away. We shall see.

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/5e8db417-b94f-4a56-84c0-a29834a93d9en%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.

Status report re PR #3911

[Edward K. Ream]

 

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/26cd3054-0f41-413d-8973-a1a45a3aa0fcn%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 ?

[Viktor Ransmayr]

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 !
 

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


This was not necessary for my PyVE of Leo's GitHub version ...
 

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


It was already available - See log below: 

user@debian-leo-study-vm:~$ 
user@debian-leo-study-vm:~$ cd PyVE/GitHub/Leo/
(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 pip list | 
grep "pyenchant"
pyenchant 3.2.2
(Leo) user@debian-leo-study-vm:~/PyVE/GitHub/Leo$ 

I double-checked WHY - and - found out that it is part of Leo's required 
packages - See

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

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. 


Once again : Thanks a lot for resolving this issue !

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 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/c239baa3-e6f0-42bb-909c-b187ea598365n%40googlegroups.com.