Re: ENB: rethinking Model/View/Controller split in Leo
I'm always in favor of good separation of interests. It can be hard to achieve in practice, and it's always helpful to be diligent about keeping one's eye on the ball. What I'm reading here sounds pretty interesting. About clones, we always talk about cloning nodes, but it seems to me that what actually gets cloned is an entire subtree - that is, the clone includes (clones of) a node's descendants. Perhaps a change in the conceptual model of clones from nodes to subtrees would make it easier to work out how to handle them. I'm not sure how a subtree is currently modeled in Leo. Since a tree can be built out of nodes that have child and parent nodes, one can be constructed without an explicit model for a (sub)tree. But since many operations we want to do are really on (sub)trees and not nodes, maybe an explicit tree concept in addition to a node concept would be useful(if there isn't one already). On Sunday, May 3, 2020 at 6:12:04 PM UTC-4, SegundoBob wrote: > > I've been thinking about implementing a directed graph editor for a long > time. Of course, most of my thinking is based on my use of Leo-Editor and > my limited understanding of its internals. I've done only a little > implementation of my ideas. I have not produced anything of use to me or > of interest to anyone else. > > But several months ago, I concluded that Leo-Editor positions are a very > bad idea and that using GNX's instead would be much simpler and much more > robust. I also concluded that in a directed graph, I don't need clones > because multiple parents is no big deal in a directed graph. Consequently, > I stopped worrying about clones. So I don't know if clones make GNX's > inadequate as pointers, requiring that v-nodes be used as pointers instead > of just GNX's. > > For the little it is worth, in so far as I understand Vitalije, and I > don't completely understand him, I think he is right. > > Respectfully, > SegundoBob > -- 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/a217cec6-f6b5-40b6-b696-4e366b27810d%40googlegroups.com.
Re: ENB: rethinking Model/View/Controller split in Leo
I've been thinking about implementing a directed graph editor for a long time. Of course, most of my thinking is based on my use of Leo-Editor and my limited understanding of its internals. I've done only a little implementation of my ideas. I have not produced anything of use to me or of interest to anyone else. But several months ago, I concluded that Leo-Editor positions are a very bad idea and that using GNX's instead would be much simpler and much more robust. I also concluded that in a directed graph, I don't need clones because multiple parents is no big deal in a directed graph. Consequently, I stopped worrying about clones. So I don't know if clones make GNX's inadequate as pointers, requiring that v-nodes be used as pointers instead of just GNX's. For the little it is worth, in so far as I understand Vitalije, and I don't completely understand him, I think he is right. Respectfully, SegundoBob -- 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/00f1ac75-6700-49d6-9a90-a551be45de6d%40googlegroups.com.
ENB: rethinking Model/View/Controller split in Leo
The relevant code is in the mvc-prototype branch in leo/extensions/myleoqt.py. Leo architecture follows MVC design pattern. However during its long history some code parts ended up misplaced. In this post I'll try to explain why I think that the present split between Model, View and Controller is not optimal. There were several factors that caused this misplacement. Moving from Tk to Qt (and for a long time keeping both GUIs around) is one of the causes. Tk didn't have tree widget and Leo had to provide tree drawing code. By switching to Qt which has a decent tree widget and keeping the old method for drawing nodes Leo didn't use Qt tree widget to its full potential. Also adding some features like user defined icons per node, chapters and hoist/dehoist commands many of the native tree widget features were not used but instead they were re-implemented. All these features are natively supported by qt tree widget. They naturally belong to the *View* but they ended up in *model* and in *controller*. In every GUI framework which has a tree widget like Qt, wxPython, Jython/Swing, ... Tree widget has its own data model. The more powerful widget is, the more data goes in its model and more work for Leo to synchronize its own model with the model of tree widget. By moving these features from Leo's *Controller* and *Model* to the *View* the synchronization between Leo's *Model* and tree widgets model becomes greatly simplified. To prove this claim I wrote a little prototype. It is a Qt application which has three widgets: tree, body and toolbar. It can read Leo documents in '.leo.db' format. To keep this prototype as simple as possible I didn't want to add reading and writing of external files. The '.leo.db' file contains the whole outline (including external files). In the toolbar there are several buttons for outline modification commands. Moving selected node up, down, left or right; demoting and promoting selected node, as well as undo/redo buttons. Using these buttons one can freely modify outline and then undo or redo operations. Selecting nodes in the tree causes body to show content of the selected node. One can edit body and changes will be recorded in Leo's model. Node can be selected either by mouse click or using keyboard when tree has focus. By double clicking node user can edit the headline and the change will be recorded in Leo's model too. [Note that undo/redo work only for outline modifications not for typing in body or changing the headlines.] There are also hoist and dehoist commands that work just like in Leo. If you hoist on the node whose headline starts with '@chapter' its children will become top level nodes. Otherwise hoisted node becomes the only top level node. Dehoist button returns the tree in its previous state. Hoists can be stacked. All this functionality is achieved in less than 500 lines including comments. *How it works?* Instead of making changes in Leo's model (by linking and unlinking v-nodes) and then asking the tree to re-arrange its items according to the v-nodes which is at least O(n) complexity operation and can be a performance bottleneck for large outlines, or even worse asking the tree to recreate the whole data model from scratch, in this prototype all those outline operations are made at the same time in both tree widget data-model and in v-nodes. This eliminates need for synchronization between these two models. No need for c.redraw_after..., c.redraw, c.redraw_later,... No need for several locks, for checking if the selected position is visible or not, is it outside hoist/chapter,... Then there is a nice feature that each clone can be expanded or collapsed independently of the other clones. In Leo this feature suffers from instability of position instances when outline changes. In this prototype this feature is fully supported. I haven't implemented yet preserving this expanded/collapsed state between two application runs, but it would be trivial to store this information in the c.db and restore it back on next run. Please note that in this prototype I haven't use the leoNodes.Position class at all. In Leo's current code the Positions are used everywhere and their instability makes many of Leo's methods much more complicated than it is really necessary. The way I see it, positions are used in two ways. 1. as a handle for v. (whenever p.v, p.h, p.b, p.u, p.is... are used). And Position was meant to be just a pointer to some v node on its particular place in the outline. Now, every tree widget must have its own data-model and its own way of pointing to the particular node painted on the screen. In Qt it is a trivial to attach user data to those pointers. Pointers are tree widget items, and they have an API for storing and retrieving user data. I used it in this prototype to attach v node to each item. If the tree widget in some other framework doesn't offer such API, it
Re: Question related to 'Installing Leo with Git'?
Am Sonntag, 26. April 2020 01:35:03 UTC+2 schrieb Matt Wilkie: > > > As the footnoted reference says, If you install from Git, you can get the >> latest development versions. What it does not say is that the latest >> development version is usually not in the "master" branch of the git >> repository. It is usually in the "devel" branch. >> > > Good point, I added how to switch. > Thanks! - I've been able to check out the development branch from the cloned repository - and - install it using pip. The logical next step would be to deliver a simple change, e.g. fixing the simple typo ``git chekout devel`` in * .../leo-editor/leo/doc/LeoDocs.leo#Leo's Documentation-->Installing & running Leo-->@rst html/installing.html-->Installing Leo itself-->Installing Leo with git as a pull request (PR) for leo-editor ... Is there anything specific to Leo, that should be considered in addition to the available information on GitHub on how to deliver PRs? 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/9d72336e-38c9-48c8-9dcb-56c95622b73c%40googlegroups.com.
Re: Nodes arbitrairily contract when inserting near the root node
Thank you very much Vitalije for those details... Indeed it was in clones as you described! So thanks again! -- Félix On Saturday, May 2, 2020 at 10:59:30 PM UTC-4, Félix wrote: > > I thought I was going crazy while trying to debug something weird in > leoInteg so I tested what I was doing directly in Leo and it turns out > it was Leo who was contracting nodes in the outline when I was selecting > nodes near the top and using the usual ctrl+i command to insert a node. > > Should I grab more data and screen animation captures ? or is this a known > bug/feature that I didnt know about? > Thanks to anyone in advance who would care to acknowledge this :) > -- > Félix (edit:typos) > > i'm using : > > Leo Log Window > Leo 6.1-final, master branch, build cfca6f348c > 2020-02-09 13:51:19 -0500 > Python 3.6.9, PyQt version 5.9.5 > linux > read 7 files in 0.03 seconds > read outline in 0.05 seconds > > -- 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/5c9f3502-ebec-437f-ac72-9be12ef7820c%40googlegroups.com.
