On Mon, 2013-04-29 at 14:46 +0200, Vincent van Ravesteijn wrote: > There have been ideas to remove the ugly connections using the > WorkAreaManager and GuiBufferDelegate and to replace them by Qt signals. > > I'm not sure it is a good idea to have a connection between each inset > and the gui. I'm afraid it will become a mess. What's wrong with telling > the Buffer "I (inset 0x3234234) have changed", and let the buffer > forward this to the gui. > > That is, if we decide to use this kind of connection.
I'm not wedded to using Qt signals/slots in the core, but I think we need a better way to communicate changes to the UI. It's not that the scanning is terribly costly, it's everything that happens on top of it (the UI repainting, etc) that I'm worried about. What I would really like to see if a method of updating the UI that components of the document have changed, without having to rebuild the entire view every time a user hits enter or backspace. This would solve many problems. For example, one issue I've had reported is that there is a noticeable flicker in the Corkboard each time there is a document update (I've had complaints on every keystroke, other say only on backspace and enter. The problem doesn't appear on OS X, since Apple seems to use double buffering to repaint UI flicker.) I've tried very hard to double buffer and only repaint once on all platforms, but catching all of the events which trigger the repaint event has proved ... difficult. Tying individual items on the corkboard to some underlying structure and updating on change would be much better. It seemed that signals/slots were a natural way to do this, as they are already used within the UI. The salient question, though, is where the update should happen. Right now we recreate the toc model and related classes on every update. Is the toc model the best place, or would it be better to try and handle it in WorkAreaManager, or GuiBufferDelegate, ... Thoughts? Cheers, Rob
