In Git, what is the difference between tqt3 and qt3?
What is dependencies/libart and when would I build that package?
Darrell
In Git, what is the difference between tqt3 and qt3?
What is dependencies/libart and when would I build that package?
Darrell
tqt3 is a modified version of Qt3 which allows the use of Qt4 classes in new TDE programs, and is preferred over qt3 when compiling TDE.
libart is the new upstream location of a small, useful graphics library that TDE and other projects need to function. It should replace any version of libart provided by the distribtion maintainers, as those older versions contain a bug that can cause crashes under TDE.
Tim
tqt3 is a modified version of Qt3 which allows the use of Qt4 classes in new TDE programs, and is preferred over qt3 when compiling TDE.
Ok. Why would somebody build with qt3 rather than tqt3? Why don't we delete qt3?
libart is the new upstream location of a small, useful graphics library that TDE and other projects need to function. It
Which TDE packages use libart?
should replace any version of libart provided by the distribtion maintainers, as those older versions contain a bug that can cause crashes under TDE.
Past my bed time. :) I checked my package list and there is a libart_lgpl-2.3.20-i486-1 installed. One of the many packages I never paid any attention.
What kind of problems would we see if we don't install the TDE version of libart?
Darrell
tqt3 is a modified version of Qt3 which allows the use of Qt4 classes in new TDE programs, and is preferred over qt3 when compiling TDE.
Ok. Why would somebody build with qt3 rather than tqt3? Why don't we delete qt3?
We maintain Qt3 for anyone who wants to use it. TQt3 is autogenerated from Qt3, so any bugs patched in Qt3 propagate to TQt3. This keeps both source trees up to date and maintains our upstream status for Qt3. ;-)
libart is the new upstream location of a small, useful graphics library that TDE and other projects need to function. It
Which TDE packages use libart?
tdebase (kicker).
should replace any version of libart provided by the distribtion maintainers, as those older versions contain a bug that can cause crashes under TDE.
Past my bed time. :) I checked my package list and there is a libart_lgpl-2.3.20-i486-1 installed. One of the many packages I never paid any attention.
What kind of problems would we see if we don't install the TDE version of libart?
http://bugs.trinitydesktop.org/bugzilla/show_bug.cgi?id=554
Tim
2011/12/30 Timothy Pearson kb9vqf@pearsoncomputing.net:
tqt3 is a modified version of Qt3 which allows the use of Qt4 classes in new TDE programs, and is preferred over qt3 when compiling TDE.
Ok. Why would somebody build with qt3 rather than tqt3? Why don't we delete qt3?
We maintain Qt3 for anyone who wants to use it. TQt3 is autogenerated from Qt3, so any bugs patched in Qt3 propagate to TQt3. This keeps both source trees up to date and maintains our upstream status for Qt3. ;-)
So, instead of installing Qt3, I can install TQt3 and everything will work? Which dependencies it exclude?
libart is the new upstream location of a small,
useful
graphics library that TDE and other projects need to
function. It
Which TDE packages use libart?
tdebase (kicker).
should replace any version of libart provided by the distribtion
maintainers,
as those older versions contain a bug that can cause crashes
under TDE.
Past my bed time. :) I checked my package list and
there is a
libart_lgpl-2.3.20-i486-1 installed. One of the many
packages I never paid
any attention.
What kind of problems would we see if we don't install
the TDE version of
libart?
I never have seen any crash like those described. Then again, Slackware has libart 2.3.20 installed. I wonder whether these libart crashes are Debian related only because of the old version? I see the point of maintaining the package now, but I wonder whether version 2.3.20 has all of the alleged missing patches.
I guess I don't worry about libart unless I start seeing related packages?
Darrell
I never have seen any crash like those described. Then again, Slackware has libart 2.3.20 installed. I wonder whether these libart crashes are Debian related only because of the old version? I see the point of maintaining the package now, but I wonder whether version 2.3.20 has all of the alleged missing patches.
The crashes seem to be happening on certain hardware only. For example I have not seen them myself on server-grade hardware, but others with comparable desktop hardware have had kicker crash.
There is inherent instability in libart, and it is possible that even if you don't see the crash that some of your users might in the future.
Tim
On 30 December 2011 16:11, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
I never have seen any crash like those described. Then again, Slackware has libart 2.3.20 installed. I wonder whether these libart crashes are Debian related only because of the old version? I see the point of maintaining the package now, but I wonder whether version 2.3.20 has all of the alleged missing patches.
The crashes seem to be happening on certain hardware only. For example I have not seen them myself on server-grade hardware, but others with comparable desktop hardware have had kicker crash.
There is inherent instability in libart, and it is possible that even if you don't see the crash that some of your users might in the future.
Tim
How dependent is kicker on libart? It might be easier to just recreate the few functions used by kicker and libart, sort of absorbing it into kicker. I'd rather have a few extra drawing ops then maintaining another library.
Any thoughts?
On 30 December 2011 16:11, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
I never have seen any crash like those described. Then again,
Slackware
has libart 2.3.20 installed. I wonder whether these libart crashes are Debian related only because of the old version? I see the point of maintaining the package now, but I wonder whether version 2.3.20 has
all
of the alleged missing patches.
The crashes seem to be happening on certain hardware only. For example I have not seen them myself on server-grade hardware, but others with comparable desktop hardware have had kicker crash.
There is inherent instability in libart, and it is possible that even if you don't see the crash that some of your users might in the future.
Tim
How dependent is kicker on libart? It might be easier to just recreate the few functions used by kicker and libart, sort of absorbing it into kicker. I'd rather have a few extra drawing ops then maintaining another library.
Any thoughts?
The library is small and we would probably end up putting just as much effort into rewriting those parts of kicker to be honest.
Unless someone here is REALLY good with vector graphics and the mechanics of making things work properly when they are rasterized keeping libart is the easiest/safest thing to do.
Tim
On 30 December 2011 16:34, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
On 30 December 2011 16:11, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
I never have seen any crash like those described. Then again,
Slackware
has libart 2.3.20 installed. I wonder whether these libart crashes are Debian related only because of the old version? I see the point of maintaining the package now, but I wonder whether version 2.3.20 has
all
of the alleged missing patches.
The crashes seem to be happening on certain hardware only. For example I have not seen them myself on server-grade hardware, but others with comparable desktop hardware have had kicker crash.
There is inherent instability in libart, and it is possible that even if you don't see the crash that some of your users might in the future.
Tim
How dependent is kicker on libart? It might be easier to just recreate
the
few functions used by kicker and libart, sort of absorbing it into
kicker.
I'd rather have a few extra drawing ops then maintaining another library.
Any thoughts?
The library is small and we would probably end up putting just as much effort into rewriting those parts of kicker to be honest.
Unless someone here is REALLY good with vector graphics and the mechanics of making things work properly when they are rasterized keeping libart is the easiest/safest thing to do.
Tim
ok understood
-
Calvin Morrison -
Darrell Anderson -
L0ner sh4dou -
Timothy Pearson