On 02/01/2012 17:17, Tommaso Cucinotta wrote:
Il 02/01/2012 17:00, Abdelrazak Younes ha scritto:
I have a pending patch that introduces Qt signals in Buffer and
BufferView, I'll try to cleanup and commit that one.
Ok, I don't know what changes will be introduced by this patch of
yours, anyway, please, drop a message on the list about the implied
changes on the code.
It's just a patch that converts Buffer::changed() and all to Qt
signals and so gets rid of WorkAreaManager and GuiDelegates.
Ok, so, unless my memory is being unfaithful to me:
1) we dropped boost::signal() for compilation performance reasons
(AFAICR, someone said that it was pulling 7K lines of code into each
compilation unit)
2) we introduced WorkAreaManager and other equivalent features via
custom dedicated classes
Because Qt's signals and slots were not tolerated in core at the time.
3) now we go back to signals, but in the Qt flavour.
Last LyX meeting (3 years ago?) we decided that Qt Core is allowed in
the core and that we should do the transition to Qt's signals and slots.
It's just that nobody did the job, until now.
This time I guess we don't have the problems of boost::signal, because
Qt is much more polymorphic oriented, rather than being
template-oriented ?
Qt uses the moc preprocessor whereas boost signal is C++ only indeed.
However, I guess the immediate drawback will be that each class
willing to issue signals, will have to be a derivate of QObject, and
have in its declaration some weird Qt macros, such as Q_OBJECT and
similar ?
Yes, very tiny price to pay IMO. Using boost signal is much more verbose
than Qt in my experience. So the 3 or 4 macros are worth it.
AFAICR, the original boost signals didn't have any constraints/impact
like that on the code.
We *are* already using Qt's signals and slots. It makes absolutely no
sense to have two different flavors of signals and slots. The old code
using boost signal was very difficult to follow and was causing a lot of
indirections all over the place.
Abdel.
