Realized it was silly, & changed my mind about the 'saved with the leo file' part. I removed the last message
On Thursday, August 27, 2020 at 10:00:54 AM UTC-4, Félix wrote: > > (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/b2687812-6ce2-422f-9540-e89c7b4b8887o%40googlegroups.com.
