ENB: Qt-prototype is finished

[vitalije]

The revision 00bda92 contains improved test and a new command execute_script.

As Brian suggested in another thread I have changed the strategy for performing hypothesis tests. Now test chooses a sequence of commands excluding undo and redo commands. After each command if the outline has changed, test will check to see if the undo really reverts the effect of command and then redo it again. Executing 5000 tests now takes about a minute. No bug has been found yet :-).

The new command `execute_script` has been added to the prototype. In order to keep things simple, this command uses only the body of the selected node as a script. It doesn't expand at-others and section references inside the body, nor it cleans other Leo's directives. If the script throws an exception the outline is reverted to its state before executing script. If the script terminates without exception all changes are recorded in the undo/redo history. This means that the scripts are undoable by default.

This concludes my work on the prototype.

What next?

The main purpose of this prototype was to prove my claims about how Leo architecture should change. Which parts should be moved to View, which should be moved to Model and which should be moved to the Controller.

The classes and methods that belong to VIew are Position, outline commands, chapter commands, hoist commands. But how to achieve that.

Let's imagine an object containing all these methods. Each GUI can create an object with these methods. QtGUI will return an object much like the MyGUI from the prototype. The other GUIs can return an object constructed from the current implementation of these commands in Leo. That way those other GUIs won't have to change much.

There is also another option. Instead of moving code from the prototype to Leo, code can be moved from Leo to the prototype. In that case Leo code can remain mostly unchanged. The prototype will evolve by copying (and adapting if necessary) the rest of Leo's features until it becomes a new complete Leo implementation.

The third option is to forget about other GUIs for the time being. Refactor Leo's code freely in separate branch without limitations of keeping compatibility with other GUIs. Once this process is done, find a way to make other GUIs work again.

Your comments please.

Vitalije

[Thomas Passin]

Very nicely done!

I would favor adapting prototype constructs into Leo.  Any other way would mean that the new branches would be need to catch up to the rest of Leo as it evolves.  Continual catch-up has been a problem for some other projects (more complicated than Leo, no doubt).  It's possible that this wouldn't be a problem in practice, but it's hard to know at this point.  This approach might be more likely to keep current plugins working, or working with minimal change.

[Brian Theado]

Vitalije

On Fri, May 8, 2020 at 7:51 AM vitalije <vita...@gmail.com> wrote:

As Brian suggested in another thread I have changed the strategy for performing hypothesis tests. Now test chooses a sequence of commands excluding undo and redo commands. After each command if the outline has changed, test will check to see if the undo really reverts the effect of command and then redo it again. Executing 5000 tests now takes about a minute. No bug has been found yet :-).

I wasn't necessarily recommending it as a replacement, but just as another way. Conceivably the two different approaches could uncover different bugs. But you are the one neck deep in the code and so are the one who can judge what the best way is.

In order to get the pytest to work I had to save LeoPyRef.leo as LeoPyRef.db. After that in commit 2560fe96a86, I get passing tests using pytest. But with latest head (00bda92c), I'm getting error:

___________________________________________________________________________ test_select_and_commnads ____________________________________________________________________________

    @settings(max_examples=5000, deadline=timedelta(seconds=4))

>   @given(data())

    def test_select_and_commnads(data):

leo/extensions/myleoqt.py:1488:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

leo/extensions/myleoqt.py:1490: in test_select_and_commnads

    app = demo2_app()

leo/extensions/myleoqt.py:1365: in demo2_app

    app.set_c(c)

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <leo.extensions.myleoqt.MyGUI object at 0x7fcc338d4eb0>, c = <leo.extensions.myleoqt.DummyLeoController object at 0x7fcc34427490>

    def set_c(self, c):

        self.c = c

        c.guiapi = self

        self.redraw()

        item = self.tree.currentItem()

>       self.set_item(item, item)

E       AttributeError: 'MyGUI' object has no attribute 'set_item'

leo/extensions/myleoqt.py:371: AttributeError

[vitalije]

Good catch that was a typo that I fixed but forgot to push. The revision 58e901e57d contains the fix.

Vitalije

[Brian Theado]

Vitalije,

On Fri, May 8, 2020 at 7:51 AM vitalije <vita...@gmail.com> wrote:

What next?

The main purpose of this prototype was to prove my claims about how Leo architecture should change. Which parts should be moved to View, which should be moved to Model and which should be moved to the Controller.

The classes and methods that belong to VIew are Position, outline commands, chapter commands, hoist commands. But how to achieve that.

Let's imagine an object containing all these methods. Each GUI can create an object with these methods. QtGUI will return an object much like the MyGUI from the prototype. The other GUIs can return an object constructed from the current implementation of these commands in Leo. That way those other GUIs won't have to change much.

Could you explain more on how that would work? The outline commands, for example, currently live as methods on c. But with your new code they would be available at c.guiapi.xxx.  The code which currently calls these outline commands (minibuffer commands and keystroke callbacks?) would be changed to instead call these c.guiapi.xxx methods? And the wrapper objects on the other GUIs would make calls to the old methods on c so their old behavior is retained?

[vitalije]

Could you explain more on how that would work? The outline commands, for example, currently live as methods on c. But with your new code they would be available at c.guiapi.xxx.  The code which currently calls these outline commands (minibuffer commands and keystroke callbacks?) would be changed to instead call these c.guiapi.xxx methods? And the wrapper objects on the other GUIs would make calls to the old methods on c so their old behavior is retained?

Yes that was the idea. Currently I am working on another idea, but it is too soon to share it. I'll write more once I have something to show.

Vitalije

[Edward K. Ream]

On Sun, May 10, 2020 at 5:00 AM vitalije <vita...@gmail.com> wrote:

Could you explain more on how that would work? The outline commands, for example, currently live as methods on c. But with your new code they would be available at c.guiapi.xxx.  The code which currently calls these outline commands (minibuffer commands and keystroke callbacks?) would be changed to instead call these c.guiapi.xxx methods? And the wrapper objects on the other GUIs would make calls to the old methods on c so their old behavior is retained?

Yes that was the idea. Currently I am working on another idea, but it is too soon to share it. I'll write more once I have something to show.

This sounds reasonable. As always, I'll reserve judgment until I see code. I eagerly await the next phase of this project.

What is the status of the tree-refresh branch? Is it still relevant?

Edward

[Brian Theado]

Edward,

On Sun, May 10, 2020 at 8:29 AM Edward K. Ream <edre...@gmail.com> wrote:

Yes that was the idea. Currently I am working on another idea, but it is too soon to share it. I'll write more once I have something to show.

This sounds reasonable. As always, I'll reserve judgment until I see code. I eagerly await the next phase of this project.

What is the status of the tree-refresh branch? Is it still relevant?

By my understanding, Vitalije's execute_script method integrates the important parts of tree-refresh branch.

Vitalije,

Can you also add a hypothesis test which instead of executing the random modification methods one-at-a-time, they get executed via execute_script? Maybe there are some bugs to shake out there.

Brian

[vitalije]

Can you also add a hypothesis test which instead of executing the random modification methods one-at-a-time, they get executed via execute_script? Maybe there are some bugs to shake out there.

Brian

Thanks, this is a good suggestion. But right now I am considering another idea. I will write about it when I am ready.

Vitalije