Am Dienstag, 21. April 2020 15:56:26 UTC+2 schrieb Edward K. Ream:
One thought was to put one or more unit tests for node p in p.u, p's user > data. Clearly that's possible. Moreover, a script could discover and run > such unit tests. > > That's not really multidimensionl, just nested, as long as you don't utilize those data in a dedicated view. Though, you could replace the existing tree or the editor with a stackwidget and allow people to choose alternate views on the graph. We've been here before, with the notion of colored links with Leo outline. > What do you mean with colored links? The declutter-code? The conclusion then (and spoiler alert, now) is that the concept isn't that > useful. > If you mean the declutter-code, then it's no surprise. The implementation is aweful and halfassed, as usual. I patched my leo to add support for p.u in there and at the end even outsourced the rules into p.u for dynamic handling. That said, leos tree-redrawing-routine is really aweful there, calling the declutter-code some dozen (or even hundred?) times per second. > If p's user data can contain *another* outline, then any node p-prime in > the new outline could contain yet another outline, contained in p-prime's > user data. And so on... This has little or no appeal :-) > > Just courious, why are you just looking at p.u? Who not also p.b? There can be significant structure in the body which is to simple for adding it at the normal tree. I once experimented adding a "local outline" on the side for this stuff. Spoiler: allowing users to easily adding their own parsers is crucial for this. So my idea is: add another node-local outline which can be controlled by the user. Furthermore, the new pane, say the *user data pane*, would likely take a > lot of screen real estate to show the user data. Most of the time that > space would be wasted (almost useless). > > There is some rather simple solution: replace the editor. Make a tabwidget and add a register of data-views which according to some rule or function loads the best fitting view for a node. The people then can decide which view they wanna use for which data, while the tabwidget still allows them to easily switch to alternate views. Allow plugins to add new views, and you can easily experiment with any view, without harming the existing GUI. This would also solve some other problems the now existing editor has regarding big nodes and long lines for example. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/e96b5a85-37a0-4cd7-bcc4-accd4d1dfffd%40googlegroups.com.
