Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| In principle I agree that the use of signals is very beneficial in the
| case of event driven application. This is the case for
| pseudo-desynchronized dialogs and for forked process handling. But in
| the case of kernel <-> frontend I am not sure this is useful at all.
You shouldn't really think too much in the kernel<->frontend space.
Think more server<->client, and the server can have more than one
client, but all clients will need to be notified sometimes. Thus
signals are nice.
| The GUI should use the kernel and not the other way-around.
Setting it solely like that limits our possibilites quite a lot.
I think we talk about the same thing, for me the kernel is just the "LyX
lib" really; a collection of handful routines and class for
understanding the LyX format and presenting it on screen.
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.
So maybe the buffer is the kernel for you. Having some signals defined
in Buffer.h make a lot of sense to me but not all of them are related to
Buffer. For example "updateTitles" and "resetAutosaveTimers" are
misplaced there IMHO.
Abdel.
