Jay, All,
I have crystal 1.0.7 building on 3.5.13 from git --> ALMOST. Here is what I
did. I need help knowing how to incorporate the cludges correctly, but that's
what the smart folks on the list are for :) What was needed to get crystal
1.0.7 to configure and begin make on tde was: (my prefix = /opt/trinity)
(1) create a link in /opt/trinity/lib
trinity -> kde3
that let's the build find the designer libs
(2) build with:
./configure --prefix=${TDEDIR} --with-qt-dir=${QTDIR}
--with-extra-includes=${TDEDIR}/include/tqt
That takes the build almost to completion:
/bin/sh ../../libtool --silent --mode=link --tag=CXX g++ -Wno-long-long -Wundef
-ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security
-Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common -DQT_PLUGIN
-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -o
kwin_crystal_config.la -rpath /opt/trinity/lib/kde3 -module -L/opt/trinity/lib
-L/opt/qt3/lib -avoid-version -module -no-undefined -Wl,--no-undefined
-Wl,--allow-shlib-undefined -R /opt/trinity/lib -R /opt/trinity/lib -R
/opt/qt3/lib crystalconfig.lo configdialog.lo infodialog.lo -lkdeui -lkio
-lqt-mt -lz -lpng -lz -lm -lXext -lX11 -lSM -lICE -lpthread -lkdecore
/usr/bin/ld: cannot find -lkdeui
collect2: ld returned 1 exit status
make[3]: *** [kwin_crystal_config.la] Error 1
make[3]: Leaving directory `/build/src/crystal-1.0.7/client/config'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/build/src/crystal-1.0.7/client'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/build/src/crystal-1.0.7'
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Build failed, check /mnt/nv1/home/chroot/david/build
dev/ammo suggested:
sed 's#$PREFIX/lib/kde3#$PREFIX/lib/trinity#g'
which I think will work, but I can't figure out how to apply it to configure. We
are getting close. Please add thoughts and I'll try again at lunch.
--
David C. Rankin, J.D.,P.E.
I can build tdebindings against ruby 1.8.7 and 1.9.1 without failure against TQt3.
I thought I'd give qtsharp a whirl. I had to install mono and pnet. I received build errors for a lack of libqtc.la.
Looks like that file is part of some kind of Qt C# bindings that needs to exist before building tdebindings. The best I can tell those bindings no longer exist.
I found old discussion threads that seem to indicate qtsharp has been broken and unsupported in (k)tdebindings for many years. The configure.in.in (very last line) indicates likewise.
The short term solution is to use the DO_NOT_COMPILE option, which already exists in configure.in.in.
Building against ruby 1.9.1 requires a set of patches, all of which are ruby 1.9.x related.
Building against 1.8.7 required some nominal patching too.
With both there are strange messages that look like failures, apparently not fatal, but need attention. I notice differences between the older kdebindings binary package and the one I build. That tells me some files are not building.
I do not have any of the tdebindings support packages installed, which likely makes a difference.
Darrell
Is sip4-tqt an interface layer or a full replacement to sip? I thought an interface layer yet I saw this in the build output:
This is SIP 4.10.5 for Python 2.6.4 on linux2.
sip-4.10.2 is installed on my system.
I have TQt3 installed. I tried building sip4-tqt and saw the following failures:
Creating sipconfig.py...
Creating top level Makefile...
Creating sip code generator Makefile...
Creating sip module Makefile...
make[1]: Entering directory `/dev/shm/sip4-tqt/sipgen'
gcc -c -O2 -march=i486 -mtune=i686 -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -O2 -w -DNDEBUG -I. -o main.o main.c
gcc -c -O2 -march=i486 -mtune=i686 -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -O2 -w -DNDEBUG -I. -o transform.o transform.c
gcc -c -O2 -march=i486 -mtune=i686 -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -O2 -w -DNDEBUG -I. -o gencode.o gencode.c
In file included from sip.h:26,
from transform.c:24:
/usr/include/tqt/tqt.h:54:23: error: ntqglobal.h: No such file or directory
In file included from sip.h:26,
from main.c:26:
/usr/include/tqt/tqt.h:54:23: error: ntqglobal.h: No such file or directory
In file included from sip.h:26,
from gencode.c:27:
/usr/include/tqt/tqt.h:54:23: error: ntqglobal.h: No such file or directory
make[1]: *** [main.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [transform.o] Error 1
make[1]: *** [gencode.o] Error 1
make[1]: Leaving directory `/dev/shm/sip4-tqt/sipgen'
make: *** [all] Error 2
Darrell
I admit much ignorance with localization files. I never built those packages.
First, with past 3.5.10 packages I notice there were localization files for k3b and koffice in addition to the standard localization files. Where are those k3b and koffice localization files in the TDE sources? If those files are missing then let me know and I'll forward the sources.
I don't know how to handle updating localized help files. I can update entities and various header declarations in those help files, but the moment I start editing the content in the top level English help files, the localized versions automatically are out of sync. I'm not even comfortable trying to edit the en-GB help files because I'm unfamiliar with the subtle differences.
What do we do about these changes? We need translators, but without such people there is nothing I can do about keeping those files current and synchronized.
I suspect when a localization file is unavailable then the base system always defaults to the English version. If we don't package those files then end users will see the English versions. Better than a weird failure messages, but not ideal.
I don't know the answers and I'm asking.
Darrell
I'm able to build tdebindings against TQt3. Exceptions are qtsharp and xparts but I plan to test the former today. Yeah, a slight miracle anybody can build that package. :) (Several patches are needed.)
I plan to further test building against both ruby 1.8.7 and 1.9.1.
I notice there are directories in tdebindings named test. I presume these are test programs and scripts to ensure the bindings built correctly? Anybody know for sure?
Darrell
I have working packages. But... they failed rpmlint checking: tdelibs
failed the build process with the errors at the bottom.
Can anyone help?
I: A function overflows or underflows an array access. This could be a
real error,
but occasionaly this condition is also misdetected due to loop
unrolling or strange pointer
handling. So this is warning only, please review.
W: tdelibs arraysubscript
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/libkmid/track.cc:337
I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
W: tdelibs strict-aliasing-punning
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/kimgio/dds.cpp:493, 503
W: tdelibs strict-aliasing-punning
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/kioslave/iso/kiso.cpp:252,
307, 308, 314
W: tdelibs strict-aliasing-punning
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/libkmid/deviceman.cc:547,
560, 579, 601, 622
W: tdelibs strict-aliasing-punning
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/libkmid/fmout.cc:121, 235,
237, 238, 243, 280, 290, 302, 316
W: tdelibs strict-aliasing-punning
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/libkmid/gusout.cc:200, 234,
236, 237, 241, 276, 298, 312, 407
W: tdelibs strict-aliasing-punning
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/libkmid/midiout.cc:81
W: tdelibs strict-aliasing-punning
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/libkmid/synthout.cc:167,
173, 180, 191
W: tdelibs strict-aliasing-punning
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/tdecore/kcrash.cpp:304
I: Program returns random data in a function
E: tdelibs no-return-in-nonvoid-function
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/krsync/rsyncconfigdialog.cpp:180
E: tdelibs no-return-in-nonvoid-function
/home/abuild/rpmbuild/BUILD/tdelibs-R13.99/tdecore/kapplication.cpp:198
--
later daze. :: Robert Xu :: rxu.lincomlinux.org :: protocol.by/rxu
How do I test the tde-i18n localization files?
I can't read the other languages. I'm interested in validating that the various help files reflect entity changes I make in those files. I need to test the files with some basic spot checking of help files and verify the entities are correct.
Oh, and when in the build sequence should those files be built? At the very end after all other packages are built?
Thanks!
Darrell
Tim,
Can you help or shed light how to fix this error? Thanks.
xparthost_kpart.cpp: In constructor 'XPartHost_KPart::XPartHost_KPart(TQWidget*, const char*, TQObject*, const char*)':
xparthost_kpart.cpp:24: error: invalid use of incomplete type 'struct TQXEmbed'
xparthost_kpart.h:10: error: forward declaration of 'struct TQXEmbed'
xparthost_kpart.cpp:25: error: no matching function for call to 'XPartHost_KPart::setWidget(TQXEmbed*&)'
/opt/trinity/include/kparts/part.h:268: note: candidates are: virtual void KParts::Part::setWidget(TQWidget*)
xparthost_kpart.cpp: In member function 'virtual DCOPRef XPartHost_KPart::registerXPart(const DCOPRef&)':
xparthost_kpart.cpp:48: error: invalid use of incomplete type 'struct TQXEmbed'
xparthost_kpart.h:10: error: forward declaration of 'struct TQXEmbed'
xparthost_kpart.cpp:50: error: invalid use of incomplete type 'struct TQXEmbed'
xparthost_kpart.h:10: error: forward declaration of 'struct TQXEmbed'
make[4]: *** [xparthost_kpart.lo] Error 1
Darrell
I pushed some patches to GIT. I don't expect problems but I'm still a newbie at GIT.
Things to watch for:
* You should see changes in the Help Center. Right now most of the changes are cosmetic, but at least when using Help you now see Trinity and TDE rather than KDE.
* If during a package build you see errors about help files, please let me know right away. There should not be any but I'm only one person working on one computer. I have not yet updated help files for applications packages I don't yet build so just let me know and I'll push the patch.
* The tdebase CMakeLists.txt was updated from STARTKDE->STARTTDE. This could affect your build script if you explicitly define that option.
* The tdegraphics CMakeLists.txt was updated from WITH_LIBPAPER to WITH_PAPER. This was broken and since nobody complained I suspect nobody explicitly defined that option in their build scripts. You have to install the libpaper package from your distro repository to use that build option.
* Obsolete tips and links have been removed from KTips. Please verify the tool still works.
You should see all of the changes in the Commit Patches web page sometime tomorrow.
Thanks!
Darrell
Hi All
I have a marketing/advertising background. The following suggestion
is primarily aimed at increasing the name recognition of "Trinity
Desktop" but should have other useful side effects as well.
This idea is structurally similar to the concept of "loss leaders"
that commercial stores use to entice people to come to their store, in
the hopes that they will buy something else while they are there
(which they usually do).
Darrel's suggestion of offering Kate scripts to the Trinity Desktop
audience started me thinking about this idea.
If we had something on the Trinity Desktop web site that people need
or want (outside of Trinity itself), and that could be found through a
Google search--they would go there to check it out and while there...
be able to read what Trinity Desktop is, and what it is trying to do.
If they find things they want and that help them (scripts in this
case) they will post about what they found on social networks, blogs
and forums. If they like what they read about Trinity Desktop, they
will post about that as well--whether or not they are interested in
using Trinity Desktop or not.
These postings would increase hits to the Trinity Desktop site, and
cause it to rise in Google ratings. This hopefully would put Trinity's
matches in the first 100 results of a Google search--which would
radically increase the hits on the Trinity Desktop site and name
recognition.
My idea is to start a "Trinity Desktop scripts" webpage or forum
containing user submitted scripts. This should be interactive and
monitored so I think something like a forum would be the best idea.
The site/page would be based around the concept of "Useful scripts
that can help you to learn scripting as well". It would include
scripts that could be used from Konsole or from inside Kate or
Konqueror (which sometimes have to be structured differently than
standard scripts). Information on how to use scripts inside Kate and
Konqueror would also be available.
To have a script accepted, a vote or committee approval would be
needed. Besides being useful (either in actual use or in learning to
script) the script would have to be heavily documented by the writer
so that the "what" and "why" of the script could be understood by
users not familiar with scripting (the majority of them).
What doing this would require:
1 - A web or forum page.
2 - Someone to create & monitor the page.
3 - Someone to manage the submissions, uploads and page entries for the scripts.
4 - Someone(s) to write a Trinity Desktop oriented description of each
script -- the authors are usually terrible at this.
5 - People (or a voting system) to look at and and approve the scripts
and descriptions.
To seed this site/page--all of us could post of its existence on
social network, forum and wiki sites that we are members of.
I will volunteer to create and manage the web page (if it is not a
wiki). Being a retied webmaster I have the skills to do so. Note
that I will be on the road from mid April to late June. I could start
it and set it up--but would not be able to put a lot of time into it
until after June.
I personally have been considering doing something like this for the
last 5 years as a personal project--so it is not a new concept for me.
Because of this my scripts are already heavily documented and ready
to use. I have somewhere between 50 and 100 scripts that I think would
qualify, and that are ready to be posted. I am sure the rest of you
have quite a few scripts as well. This means that an impressive
number of scripts could be put up rapidly, providing the variety
needed to attract viewers.
Thoughts?
Another useful page/site similar in effect to the above would be one
that specialized post and information on how to modify the appearance
and function of menus, toolbars, popups, etc. for Trinity Desktop
programs.
Keith
