Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| So, using your terminology, I'd say that Buffer is the server and
| the
| the WorkArea (thus the frontend) is the client as one buffer might be
| edited and/or visualized in multiple WorkArea. I would agree with
| that, but I think that having the BufferView emitting signals is
| wrong. The BufferView is just a tool used by the frontend to visualize
| the buffer.
Yes, but it is not only "The Frontend" it might be "Frontends", and
then signals for communicating is nice (and asynchronus, which we
like).
Then splitting the server and the client in two processes would make
even more sense. Then the signals would be replaced by pipes or sockets.
That would be a nice long term goal ;-)
Anyway, I agree but let's not forget that when a frontend is asking
specifically for a change, it does not have to "react" to that change.
That's part of a simplification I was talking about. I am not sure I am
clear so let me take an example:
Right now, when the user press a key, th Qt event handler calls the
processKeySym lfun which calls BufferView::update() (two times). The
signal LyXView::view_state_changed() is then emitted from there (two
times). But the frontend was of course aware of the keyPress as it was
asking for it. So it does not have to react to it but just to complete
the action with the relevant needed update (titles, dialogs, etc). My
next cleanup round eliminates this view_state_changed signal.
Abdel.
