Angus Leeming wrote:
Angus Leeming wrote:
I don't think that you'll get a definitive answer from them. This
signal precedes Abdel
Indeed but I could have answered . Eventually all the boost signals
should disappear...
I don't agree with that. There are some, such as the signal from the
core that the buffer has changed, that are handled elegantly by emitting
a signal. Different dialogs do different things when the buffer changes.
Some refresh their contents, some close, some do nothing. All are free
to do what they think is best because they connect to the signal that
tells them the change has occurred.
I am not sure the behavior you are describing is the one actually used
in present code in the case of a buffer update. I was a bit strong in my
word though, some boost signals may stay but they shall be transfered to
the frontend. Let me clarify my thinking:
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. The
GUI should use the kernel and not the other way-around. Right now, there
is a lot of back or forth communication between the two and this is that
I am aiming to clean up.
If there is a need for signal type communication, the frontend should be
responsible for implementing it. But you are probably right in the sense
that, at the end, we would keep using boost signals for that.
FWIW, the redrawGUI signal was best implemented as a signal IMO. It just
happens that the need for the code has gone with the removal of the XForms
frontend.
Sure. I don't pretend there was no need for it.
However, there definitely are signals that just obfuscate. Proceed with
your clean up and you'll fix them I'm sure.
That's what I meant of course. I am going carefully step by steps.
Abdel.
