John Beardmore wrote: > Well - I don't know too much about how Scribus handles things, and I > don't even know what your other package is, but it would be nice to have > Scribus be more responsive. > > I don't know if the underlying issue here is Qt
It is not. If anything, Qt is a major positive influence on Scribus's performance. This issue is caused by design choices made in early versions of Scribus that became somewhat entrenched and entangled with the file format, the rest of the redraw code, etc. I know there's been some work done on improving the underlying cause of the performance issues being discussed here, though I don't know what the current state is in 1.3.5 . It's complicated and difficult to improve, and as you may have noticed nobody working on Scribus gets paid to spend their time on it. Only a few people contribute actively to the core code, and there's a huge amount to do both in cleanups and in desired enhancements. > but if it is, > presumably it would be a huge rewrite, if not impossible to change it now ? Probably a total rewrite. Scribus not only uses Qt for its GUI, but for all its internal data structures. It also uses the Qt signals/slots system heavily throughout the app. In any case, I the only reason I can imagine you would want to write a GUI C++ application with anything but Qt would be licensing constraints. -- Craig Ringer
