Le mardi 21 septembre 2010 à 08:31 -0700, Luca Invernizzi a écrit : > > 2. Use the gtk.gdk.Lock (with gtk.gdk.lock) (see the doc about it). > > > > > > I recommand you to read : > > http://friendpaste.com/2wKdvQpUKruG0PeUl2PKIV > > > > > > What do you think ? > > Sounds still very painful, but perharps it will work. > Nice resource on this matter: http://live.gnome.org/GdkLock > > Could you expand a bit on how the Treeview "explores" the TreeModel? > I'm thinking that keeping a thin treemodel with only the rows stored. > The model locks at every change, and it's unlocked by the ui. This is, > basically, an easier version that the one you were thinking about > (keeping a revision number of every change).
The "exploration" is highly dependant of what you have above your treemodel (a treeview, a treemodelfilter or a treemodelsort). There implementation is completely different. I thought about an even easier idea, which is a gross hack but would make it fine if it works. Currently, in filteredtree, in my dethreadization branch, a state is represented by a self.cache_nodes and a self.cache_vr. The change is now atomic : we switch to a new state in a lock and also increase a self.state_id counter. What we could easily do is to simply save those state with their corresponding state_id. All the methods would get an additional parameter which would be the required state_id. If none, the behavior would be the current one (the latest state_id). The treemodel will keep the nbr of the state id he's currently in as a global variable. This variable will be incremented each time a signal is processed (in my branch, signals already carry the number of the revision they are announcing). That means that, if the tree model has in queue the signal 43 and 44 but they are not processed yet, it will ask the filteredtree the answer at state 42. Given the current code of filteredtree, this would be fairly easy. To avoid memory growth, we could simply add a way for the treemodel to say that a signal has been processed (and thus that we can forget all the previous states). This is hackish, ugly and make the liblarch code highly specific (I will not release a self-standing liblarch which such an ugly workaround) but : 1. With the current code, it would be fairly easy (albeit a bit long and boring) 2. Should not impede to much performances 3. Will not require to work with the global lock or anything else (all of what is needed is already done in my branch). 4. I've already proven in my branch than by setting an higher priority to the handling of signals in treemodel reduces significantly the number of errors. (the treemodel listen more to signals and explore less by itself between them). The only bug we would need to solve is to ensure that we have a "one new state -> one signal" rule. It's not the case when deleting currently. I wanted to give it a try tonight but I will not be able so I write the idea to have an external point of view. I'm tired of that and it could be a workable exit. Lionel _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
