Yes it does. Can you try this test: In the file kdelibs/kdecore/kxerrorhandler.h, insert the following line:
#include <tqevent.h>
directly before this block of text:
#include <tqvaluelist.h> #include <tqwindowdefs.h> #include <kdelibs_export.h> #include <X11/Xlib.h>
Retry the compilation; if it gets farther please let me know.
Still failed. I'm attaching the output. I verified after the build failed that the file was updated.
Yes it does. Can you try this test: In the file kdelibs/kdecore/kxerrorhandler.h, insert the following line:
#include <tqevent.h>
directly before this block of text:
#include <tqvaluelist.h> #include <tqwindowdefs.h> #include <kdelibs_export.h> #include <X11/Xlib.h>
Retry the compilation; if it gets farther please let me know.
Still failed. I'm attaching the output. I verified after the build failed that the file was updated.
OK, I have one more thing for you to try. (If you haven't guessed already, I cannot replicate the build failure here).
In the file kdelibs/kdecore/kipc.cpp, insert the following line:
#include <tqevent.h>
directly before this block of text:
#include "config.h"
#include <tqwindowdefs.h>
#if defined Q_WS_X11
From the build log, I would guess that the word "None" is getting #defined somewhere too early--this will help isolate the problem.
Thanks!
Tim
1. In which package is the mouse cursor defined? I want to make the passive mouse cursor the default when I build the package. Where do I do that in the code?
2. I'm unsure, but I think your modified Kubuntu uses the oxygen mouse cursors as the default. I want to set the traditional mouse cursor as the default when I build the package. Where do I do that in the code?
3. When a person runs the Personalizer applet, usually run the first time a person runs KDE, I want the passive mouse pointer set when the person selects zero desktop effects. Where do I do that in the code?
4. The default mouse double-click time is too fast. People with disabilities cannot operate the mouse buttons that fast. I want to set the default double-click time to about 700 ms. Where do I do that in the code?
I realize some of this might require enhancement requests in the bugzilla, but I need to know where to start looking.
Thanks.
The kdelibs sources were modified to avoid compile errors when the --disable-dnssd option is used and avahi is not installed.
In the stock Slackware build script that option is not used. The stock Slackware build script compiles without those errors.
In configure --help, the default option is not explicitly declared. Only the --disable-dnssd option is mentioned in the help output. There is no --enable-dnssd option mentioned in the --help options. I think the latter option is valid, however. In the stock configure there is a test for --enable-dnssd. One way or another, I presume that dnssd support is enabled by default.
To the best of my knowledge Slackware does not include any kind of dnssd service. So an obvious question is why does the Slackware build script not fail?
The stock configure file contains the following mild warning:
if test "$have_libdns_sd" = "no"; then echo "" echo "You're missing Apple mDNSResponder 85 or later, therefore" echo "dnssd will be compiled as stub, without any real functionality." echo "If you want zeroconf support (www.zeroconf.org), you should install mDNSResponder first." echo "See dnssd/INSTALL for details." echo "" all_tests=bad fi
I think this warning is the same as Trinity KDE. Yet the stock KDE 3.5.10 builds without halting if no such service is installed while the Trinity version does not.
Based upon that warning, kdelibs should compile with or without the --disable-dnssd option and the KDE DNS-SD watcher service should compile as an unfunctional stub.
At this point I don't think being required to use the --disable-dnssd option is the correct approach.
Related to this issue, what will happen if I compile kdelibs with avahi installed, but an end-user installs that package without avahi installed? Will KDE choke or spew forth a bunch of error messages? As we have not yet ironed out the bugs that will allow me to install these recompiled packages, I have no idea of the result. I can see the KDE DNS-SD watcher service in the my stock version of the Control Center. Hopefully compiling with avahi but installing without causes no problems and the KDE watcher services just shrugs, so to speak. I can add some verbosity in the build script explaining that building with avahi installed is a good idea but installing the kdelibs package does not require having avahi installed.
I doubt the Slackware maintainer compiled kdelibs with avahi installed. He's not that kind of person. His philosophy is to provide a basic operating system. If an end-user wants DNS-SD suppor then that would be up to the end-user. Therefore I think kdelibs should compile without needing the --disable-dns option or having avahi installed.
I have all the original stock KDE 3.5.10 sources. Please let me know what information to forward to better resolve this issue. I can send anything from the stock Slackware build process too.
Thanks.
Darrell
In several of the Slackware 12.2 KDE build scripts, there is a configure option --with-xinerama.
That option is not recognized in the Trinity build process and a non-fatal error is provided when using that option.
Slackware 12.2 is about one and a half years old. In terms of free/libre software, that is considered by some people to be ancient and obsolete. :) I'm guessing the --with-xinerama is no longer supported because X has changed much in the past year and half.
Should that option still be supported?
Darrell
In several of the Slackware 12.2 KDE build scripts, there is a configure option --with-xinerama.
That option is not recognized in the Trinity build process and a non-fatal error is provided when using that option.
Slackware 12.2 is about one and a half years old. In terms of free/libre software, that is considered by some people to be ancient and obsolete. :) I'm guessing the --with-xinerama is no longer supported because X has changed much in the past year and half.
Should that option still be supported?
Darrell
Hmmm....Xinerama works just fine on Ubuntu. I wonder if the the option is now either locked to "enable" or if Trinity may just be using Qt's underlying Xinerama support at this point (my guess).
Did you get a chance to try modifying kdelibs/kdecore/kipc.cpp yet? I will commit the 3.5.12 version change along with that file if the build problem was fixed.
Thanks!
Tim
Hmmm....Xinerama works just fine on Ubuntu. I wonder if the the option is now either locked to "enable" or if Trinity may just be using Qt's underlying Xinerama support at this point (my guess).
Okay. I'll just delete that option from the build script.
Does building each Trinity package depend upon having the previous package in the build chain installed?
For example, do I have to have the Trinity version of kdelibs installed to build kdebase?
Or can I build each Trinity package on my stock KDE 3.5.10 system?
Does building each Trinity package depend upon having the previous package in the build chain installed?
For example, do I have to have the Trinity version of kdelibs installed to build kdebase?
Or can I build each Trinity package on my stock KDE 3.5.10 system?
No, each Trinity package must be installed before the next can be built. The include files have changed dramatically from KDE3.5.10 due to the new features (e.g. the new low level libkrandr library) and also due to the TQt conversion.
No, each Trinity package must be installed before the next can be built. The include files have changed dramatically from KDE3.5.10 due to the new features (e.g. the new low level libkrandr library) and also due to the TQt conversion.
Hmm. Okay. I'll create a virtual Slackware 12.2 machine that does not have KDE 3.5.10, or arts installed and start building in that environment.
Could some of these build errors have to do with me building in an a KDE 3.5.10 environment?
No, each Trinity package must be installed before the next can be built. The include files have changed dramatically from KDE3.5.10 due to the new features (e.g. the new low level libkrandr library) and also due to the TQt conversion.
Hmm. Okay. I'll create a virtual Slackware 12.2 machine that does not have KDE 3.5.10, or arts installed and start building in that environment.
Could some of these build errors have to do with me building in an a KDE 3.5.10 environment?
Absolutely! I'm surprised the builds even got as far as they did.
Absolutely! I'm surprised the builds even got as far as they did.
Good news.
I reconfigured my virtual Slackware 12.2 machine with no KDE remnants.
The kdelibs package built for about 63 minutes before failing. The virtual machine is a tad slower than the actual hardware. When we were testing the Ark modifcations I could build the stock 3.5.10 kdelibs in about 50 minutes. Thus I am guessing that the build in the clean environment might have been close to completion before failing.
As my first pass was a test, I did not keep a log of the output.
I just updated svn and am now running another build pass. I'll send an update in a few hours.
No, each Trinity package must be installed before the next can be built. The include files have changed dramatically from KDE3.5.10 due to the new features (e.g. the new low level libkrandr library) and also due to the TQt conversion.
Seems then that in my prerequisite checks I should test for the installation of stock 3.5.10 packages?
Should each subsequent package build script test that the previous Trinity packages are installed?
Are there any special files I can query to ensure the Trinity packages are installed and not the stock packages?
Slackers tend to be DIY types but I think providing warnings or checks might be prudent.
WDYT?
No, each Trinity package must be installed before the next can be built. The include files have changed dramatically from KDE3.5.10 due to the new features (e.g. the new low level libkrandr library) and also due to the TQt conversion.
Seems then that in my prerequisite checks I should test for the installation of stock 3.5.10 packages?
Should each subsequent package build script test that the previous Trinity packages are installed?
Are there any special files I can query to ensure the Trinity packages are installed and not the stock packages?
The only thing I can think of is to check the KDE version number; if it is greater than or equal to 3.5.11 then Trinity is installed.
Slackers tend to be DIY types but I think providing warnings or checks might be prudent.
WDYT?
Probably a good idea; I don't have the time at the moment to pursue it further but if you come up with a reliable method for doing this I would be willing to look at it and commit it to SVN.
Probably a good idea; I don't have the time at the moment to pursue it further but if you come up with a reliable method for doing this I would be willing to look at it and commit it to SVN.
I don't know of a way to merge those checks into svn. Currently I am writing some basic checks in my build scripts and I will continue expanding those checks as I learn more. Perhaps eventually those checks can be merged into svn so as to help any person with any distro.
When building kdelibs I always receive the following configure warning:
lua.h was not found or was not usable, Lua 5.0 headers are required !
I see that same warning when I build from the stock KDE and Slackware build scripts. Obviously the package builds just fine in Slackware, so I'm just wondering what that warning is all about.
Darrell
When building kdelibs I always receive the following configure warning:
lua.h was not found or was not usable, Lua 5.0 headers are required !
I see that same warning when I build from the stock KDE and Slackware build scripts. Obviously the package builds just fine in Slackware, so I'm just wondering what that warning is all about.
Darrell
I have no idea. Maybe you should create a new bug on the bugtracker named "Build cleanup" or something similar, and add all instances of spurious non-fatal warnings (such as the lua one) to that bug. That way someone can go through and try to clean up the build system in the future.
Trinity is intended to coexist with KDE4.
If I set my build options to install in /usr rather than /opt/kde3, how much will break because Trinity expects to exist in /opt?
Hopefully nothing in the sources is hard-coded to /opt.
I want to make that an option in my build scripts and not a requirement.
In my build scripts I can set the --prefix option to /usr. Or /opt/kde3. Or whatver.
I really do not want to install in /opt and have no motivation at this time to install KDE4. I suspect many people using KDE3 don't care about KDE4, although ensuring they can coexist is a pragamatic decision.
Darrell
Trinity is intended to coexist with KDE4.
If I set my build options to install in /usr rather than /opt/kde3, how much will break because Trinity expects to exist in /opt?
Hopefully nothing in the sources is hard-coded to /opt.
No it is not.
I want to make that an option in my build scripts and not a requirement.
In my build scripts I can set the --prefix option to /usr. Or /opt/kde3. Or whatver.
Yes you can, and it will install to wherever you specify.
I really do not want to install in /opt and have no motivation at this time to install KDE4. I suspect many people using KDE3 don't care about KDE4, although ensuring they can coexist is a pragamatic decision.
Fine with me; I leave those decisions up to the package maintainers for any given distribution. Just please mention the incompatibility on the page where you release the packages, and that it is a distribution decision not a Trinity one. ;-) That will avoid Emails coming directly to me about incompatibilities.
Darrell
Tim
Excuse my ignorance or blindness, but is there a master change log anywhere?
I notice change logs in each .svn directory, which seem to match the ChangeLog in the parent directory, but they all are outdated terribly.
Darrell
Excuse my ignorance or blindness, but is there a master change log anywhere?
I notice change logs in each .svn directory, which seem to match the ChangeLog in the parent directory, but they all are outdated terribly.
Darrell
You can get one by running:
svn log
in the master directory (e.g. the one containing kdelibs, kdebase, etc.). Or, you can view the change list on the Trinity project website (http://trinity.pearsoncomputing.net) by clicking on the "Trinity Patches from SVN" link on the left hand side.
Hope this helps!
Tim
You can get one by running:
svn log
Okay. That works. I was thinking a more human readable log that most people are accustomed to reading. The trick would be to massage that list into something friendlier.
I ask because when I announce that this project works with Slackware, I expect people to ask what has changed.
If most people think the only thing provided is simply compiling 3.5.10 to work with newer software layers, then many will not be motivated to investigate. If they know that Trinity actually provides many bug fixes and enhancements, then those who have wanted to stay with 3.5.x will be more motivated.
I am aware of your kubuntu web page with a handful of screen shots. I was thinking a more verbose but friendly change log link at that page might be useful and simple marketing.
You can get one by running:
svn log
Okay. That works. I was thinking a more human readable log that most people are accustomed to reading. The trick would be to massage that list into something friendlier.
I ask because when I announce that this project works with Slackware, I expect people to ask what has changed.
Gotcha. I'll see what I can do; I'm running tight on time myself, which is why the Website is as basic as it is now.
If most people think the only thing provided is simply compiling 3.5.10 to work with newer software layers, then many will not be motivated to investigate. If they know that Trinity actually provides many bug fixes and enhancements, then those who have wanted to stay with 3.5.x will be more motivated.
I am aware of your kubuntu web page with a handful of screen shots. I was thinking a more verbose but friendly change log link at that page might be useful and simple marketing.
What is the status of the KDE help files?
I always found them terribly outdated in the stock KDE. As Trinity is being patched and wonderfully updated, are the Help files being updated too?
Darrell
What is the status of the KDE help files?
I always found them terribly outdated in the stock KDE. As Trinity is being patched and wonderfully updated, are the Help files being updated too?
No. I would welcome help on this front from anyone willing to provide it!
Darrell
No. I would welcome help on this front from anyone willing to provide it!
Heh. I have provided technical writing services for a couple of decades or so.
Some challenges I forsee:
1. I have to learn how to edit and make KDE Help files.
2. I need a way to monitor the master change log to know what needs updating. that was one reason I asked about change logs.
Which version of qca and qca-tls must be installed to build Trinity KDE?
I'm guessing that qt-3.3.8b, qca-1.0, and qca-tls-1.0 should be rebuilt on any Slackware system after 12.2?
Slackware 12.2 provided the following:
qt-3.3.8b qca-1.0 qca-tls-1.0
Slackware 13.0 did not provide KDE 3.5.10 but KDE 4.x. Therefore qt-3.3.8b was not installed but qt4. 13.0 provided:
qca-2.0.1 qca-cyrus-sasl-2.0.0_beta3 qca-gnupg-2.0.0_beta3 qca-ossl-2.0.0_beta3
As far as I can tell there is no qca-tls package provided.
Slackware 13.1 and Current (testing):
qca-2.0.2 qca-cyrus-sasl-2.0.0_beta3 qca-gnupg-2.0.0_beta3 qca-ossl-2.0.0_beta3
I'm guessing these additional qca packages are specific to qt4.
Which version of qca and qca-tls must be installed to build Trinity KDE?
I'm guessing that qt-3.3.8b, qca-1.0, and qca-tls-1.0 should be rebuilt on any Slackware system after 12.2?
Correct.
Slackware 12.2 provided the following:
qt-3.3.8b qca-1.0 qca-tls-1.0
Slackware 13.0 did not provide KDE 3.5.10 but KDE 4.x. Therefore qt-3.3.8b was not installed but qt4. 13.0 provided:
qca-2.0.1 qca-cyrus-sasl-2.0.0_beta3 qca-gnupg-2.0.0_beta3 qca-ossl-2.0.0_beta3
As far as I can tell there is no qca-tls package provided.
Slackware 13.1 and Current (testing):
qca-2.0.2 qca-cyrus-sasl-2.0.0_beta3 qca-gnupg-2.0.0_beta3 qca-ossl-2.0.0_beta3
I'm guessing these additional qca packages are specific to qt4.
Yes.
-
Darrell Anderson -
Timothy Pearson