On Fri, 2003-10-17 at 05:58, Craig Ringer wrote: > > I've compiled Qt 3.2.2 and recompiled Scribus with the optimisations > > which are available via the anoncvs server. There is a marked > > improvement in the Qt parts as well as a rather large speed up in the > > main application. > > That's a thought. Is there any reason not to build Scribus against a > /private/ vanilla copy of qt? Given the number of issues Scribus has > with various packaged versions of qt, due to age, excessive vendor > patching, etc, I understand why you reccomend a "vanilla" current qt.
There is no reason whatsoever why folks shouldn't use a vanilla Qt instead of the botched pre-packaged versions. I'd recommend that after people are happy with their setup that they make their own version of Qt as not only will they be rid of some of the dreadful botches that some vendors put in (I finally found the bugs in Mandrake and Slackwares versions about a week ago and they're as bad as some of the MS botches you find in their libs - Slack was worse than Mandrake) but the code will be compiled for their processor type (i.e. not as a base processor type but actual processor type). > It's a right pain for most users, though. Not really. The instructions are clear enough in the Qt readme file for setting it up. If you then use ./configure -thread -fast, compilation time is cut down as well. > One way around this would be to install a copy of qt in, say, > /usr/local/scribus-qt and set the LD_LIBRARY_PATH in a wrapper script to > scribus. Is there any reason not to do this? Any other libraries not > provided by qt that could conflict? You would also need to say where the header files are for that version of Qt and there is the potential for things to get really snarled up, but there isn't that much reason not to do it. > Ideally, of course, something like this wouldn't be needed. Hopefully > once distros start packaging Scribus it'll be less of a problem. I talked to RH at the LinuxExpo and while Sun will package it on their Solaris companion CD/DVD, getting it onto the Fedora discs may be more of a problem. Though I hate to say it, the Debian people seem to be very silly over Scribus (the website is saying the unstable is 1.0.1) > I've just been lurking lately, but this struck me as a possibility for > working around some of the issues people have with qt without disrupting > other apps on their system. One could even, in theory, apply a patch to > qt to fix something causing problems for scribus - without worrying > about other apps. Yep, I've found though that using a vanilla Qt has no kickbacks on other apps though. TTFN Paul -- One OS to fool them all One browser to find them One email client to bring them all And through security holes, blind them...
