(continuing my example) It's not about which command to run if expanded/collapsed, its about which will be selected when the command is run. (if we're considering the command 'selectNextVisible', for instance...
So what is computed by the controller, is which p node to set the selection to, based on the currently selected node p, and what nodes are collapsed/expanded. So the computation to choose the newly selected node, in the controller with the model, is based on expand/collapse data. I could write a script on a node, run it through a button or ctrl+b, and that script could do stuff based on data in the tree, headlines, body content, but also expanded/collapsed states. So its a boolean bit of data, that is merely reflected in the gui, but not primarily stored there, in my opinion. It's important data as much a as headline text and body content. (but only 1 small bit). It should be treated as such, just like headline labels and body text: rendered by the gui, which also exposes ways to change them (body, headlines and collapsed state - oh, and also user attributes). -- Félix On Thursday, August 27, 2020 at 1:29:04 AM UTC-4, vitalije wrote: > > > >> It is visualised as expanded/collapsed in the gui, indeed right, but its >> important in the model/controller as much as the 'headline string' or 'body >> content' because of those commands which set the selected node based on >> whats collapsed/expanded. So it is real model data/state as much as >> headline content and body content. >> >> Nevertheless this piece of data *IS* stored in the Qt GUI, and I am sure > that any GUI you can think of that implements Tree widget will have this > information too. Whenever you have to keep a copy of some data in two or > more places, you'll have to synchronize this data and there is always a > possibility of getting out of sync. OTOH, when the model is designed in > such a way that a single piece of information is always kept in one and > only one place, there is no need for synchronization and it is impossible > by design to get out of sync. > > You might decide for your GUI not to keep track about expanded/collapsed > state and to ask through the Leo bridge every time you need this > information, but still under the hood, bridge won't be able to give you a > stable response. If you decide to keep track of the expanded/collapsed > state in your GUI, you will be able to set this information in Leo > correctly before executing any of the commands you mentioned, or better > yet, those commands can be separated in several different commands and you > just choose one you want depending on the expanded/collapsed state. > > This approach can be taken in any GUI. For example: > # instead of > def my_command(...): > if p.isExpanded(): > do_one_thing() > else: > do_other_thing() > > # it should be > def my_command_when_collapsed(...): > do_one_thing() > > def my_command_when_expanded(...): > do_other_thing() > > And then, let the GUI choose which command to call, depending on the > current expanded/collapsed state. > > Vitalije > -- 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/08ab3543-9be7-4c5f-8039-c927e6481141o%40googlegroups.com.
