[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: qt + gl + problems + etc...



Sounds great.  Though I'm sure you've thought of it, maybe have one of those 
"notes" that dpkg uses when a user install libqt-gl, saying VERY LOUDLY that 
they'll have to change the linking option for any qt-gl apps, and emails it 
to them if they have their priority level too high.  Other than that (and the 
fact that my home desktop can't install 2.2 yet, missing kdelibs3 
>=4:2.2-cvsfoo-1 in unstable) and I'm *really* liking this new kde :-)  I've 
been running the alpha at work for the last week (from people.debian.org), 
and aside from konq's tendency to wonk out at seeminly random places once a 
day, it's very nice.  Please keep up the good work!

Many Thanks,

D.A.Bishop

On Wednesday 27 June 2001 17:57, Ivan E. Moore II wrote:
> Ok...so with kde 2.2 mostly uploaded (some bits already installed) to sid I
> turned focus to QT again especially since I've personally had many crashes
> of konsole due to the whole GL bit.
>
> so this lead me to a immediate solution.  I still do not like this solution
> however this is one that I am comfortable in sticking with if a proper
> one does not arise before woody's release.
>
> so your asking...what's the solution???
>
> well...a libqt2-gl package...but not like before.  I have created a
> completely seperate source package (qt-x11-gl) which builds 2 packages: 
> libqt2-gl and libqt-gl-dev.  The actual qt library it creates also has been
> changed.  Instead of it providing /usr/lib/libqt.so.* I've renamed the
> library to libqt-gl so that it can co-exist with a normal (non-gl'd) qt
> library.
>
> So..what does this do for everyone you might ask?
>
>    allows packages that do not need the GL bits of QT to not have to deal
> with a library with them compiled in nor the issues surrounding QT + GL +
> threads. (short answer on this...flash plugin works, no more konsole
> crashes, etc...) This also allows for applications that do need GL support
> to still exist within the distribution.  (oh yea..and the pure_virtual
> problems *should* go away)
>
>
> So..what's the drawbacks you might ask?
>
>     1: (obvious) yet another package (well 2)...not really that big of a
> deal 2: anyone who wants their package to link to the GL'd version of QT
> *must* modify their build process to link to libqt-gl instead of libqt. (
> "-lqt-gl" instead of "-lqt")
>
> Overall I think this will be a good solution until someone comes up with
> another better solution.  I'm sure I'll get several bug reports from people
> saying their GL based apps broke and then I'll hear them gripe when I tell
> them they need to install libqt-gl-dev and modify their source.
>
> any major issues before I upload the new packages?
>
> Ivan



Reply to: