> On Jun 18, 2018, at 1:32 PM, Christian Stimming <[email protected]> > wrote: > > Am Sonntag, 17. Juni 2018, 20:09:24 schrieb John Ralls: >>> I.e. the function qof_book_use_split_action_for_num_field is very very >>> expensive. Currently it does a KVP lookup on each call. What keeps us from >>> turning this KVP value into a normal gboolean value in the struct >>> _QofBook? >> >> Christian, >> >> It’s all about file compatibility, remember? As it stands, if you make >> something a regular member variable then you have to change the schema to >> add the element/column, and write a scrub to update older data. We strongly >> prefer not to do that during a stable release cycle and generally require >> that the last version of the previous stable series be able to read both >> formats. > > Yes. Although what I'm concerned with is only the lookup performance, not the > serialization place of that option. The serialization may be kept unchanged > completely.
Right. So thinking about that some more, persistence (I think that’s a better description of this than serialization) is driven by the backends rather than the objects, so you can create a member variable and as long as you don’t tell the backends about it it won’t be a problem. That seems to be what you’ve tried to do in your patch. > >> One alternative would be to redo the backends so that member variables can >> be designated as stored in KVP, effectively moving KVP out of engine. That >> would be a bit of work but it’s an alternative to changing the schemas. >> It’s a route we’ve discussed before but nobody’s been inclined yet to take >> it on. >> >> The less involved approaches would be to cache the value or to make KVP >> retrieval more efficient. I suspect in this case that caching will be the >> easiest. > > Yes. I've introduced some caching of this value here, but I still need a > little bit of help: > https://github.com/cstim/gnucash/commit/376cc19b7143983ce297f2272abf1a44e72fd851 > This change gets the register UI back to the old speed again. No more 1 > second > delay after hitting enter. (I wonder why I seem to be the only one who got > bugged by this, but whatever.) > > However, I broke the original feature in that change. To reproduce: Open some > register where there is some text in the "Num" field, say "1111". Switch on > the "Double Line" view mode. Then open File -> Properties, and on the first > tab, activate the option "Use Split Action Field for Number". Press Ok. > Before > my commit, in the opened register the "1111" now moved from the first line of > the txn to the second line, and vice versa after changing that option again. > Unfortunately my commit broke that feature. Maybe someone has a good idea > why? > Thanks for some pointers. As a first guess I’d look at the hook list execution to make sure that your adding qof_book_option_num_field_source_changed_cb isn’t somehow preventing gnc_plugin_page_register_sort_book_option_changed (in gnucash/gnome/gnc-plugin-page-register.c) from running. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
