Andre Poenitz wrote:
I was looking for a way out of the dilemma given by the following
restrictions:
- signals and slots are a very powerful concepts leading to simple code,
- boost/signals.hpp is very expensive at compile time (+60000 lines
per compilation unit) and fragile wrt to object construction/destruction
order
- Qt signal/slot is still not considered politically correct to use in
src/*.{h,cpp}
I'll attach a proof-of-concept implementation of a thin wrapper around
Qt's signals and slots that does not mention the letter 'Q' in the the
public interface. According to the current rules that would be acceptable
for src/support/...
Looks good to me.
In theory, the implementation could use boost::signal without changing
the interface, but that would still leave us vulnerable to the fragile
destruction order. And not using boost::signal would allow us to remove
~2500-3000 lines of third party code we distribute with LyX.
Actually, I think we don't use boost::iostreams nor boost::filesystem
nowadays so we could already remove both compilations from the makefiles.
Unless people manage to hit me very hard with some big blunt item I'd
start "converting" our codebase soonish. Should be not too much of a
change, actually, and after that we can use signal/slot freely without
worrying about compile times...
I have a question: will this work fine if support becomes a dll?
Abdel.
