I know that there were some changes in this filed with the
introduction of TQt with already translated Q* objects to QT*. But I
have I noticed on my system another thing having both qt3.3.8d and
qt4.8.0 installed and I don't know if there are movements to resolve
this.
Qt provides set of tools that enable creation of qt-based
applications. Those are: assistant, designer, linguist , lrelease,
lupdate, moc, qmake, qtconfig, uic. Those are provided both by qt4 and
our qt3.
If I have both of the qt versions installed and I try to run one of
those applications, only the qt4 versions are launched, and I am
unable to launch qt3 ones unless i specify full path to them as
command.
That may be because I installed qt4 as second, and if I were to
install it first and then qt3 then I'd be able to start only those
provided by qt3.
If I run those commands through whereis I get:
assistant: /usr/bin/assistant /opt/qt/bin/assistant
designer: /usr/bin/designer /opt/qt/bin/designer
linguist: /usr/bin/linguist /opt/qt/bin/linguist
lrelease: /usr/bin/lrelease /opt/qt/bin/lrelease
lupdate: /usr/bin/lupdate /opt/qt/bin/lupdate
moc: /usr/bin/moc /opt/qt/bin/moc
qmake: /usr/bin/qmake /opt/qt/bin/qmake
qtconfig: /usr/bin/qtconfig /opt/qt/bin/qtconfig
Obviously, if I invoke assistant, the first path is executed.
As a temporary solution for my packages I create links to the qt3
tools in $prefix/bin/ and name them in the Qt3* scheme. Anyway I think
those should be renamed in the TQt3 to avoid collisions with Qt4 ones.
Would one of you artists lend a hand in updating a PNG image file:
tdelibs/doc/common/kde_logo.png
We need to retain the same attributes (size, depth, etc.) but update the image to reflect Trinity.
This image is used primarily in the web version of the help files, but is used in a few other places.
When finished, please submit the updated image to bug report 694.
Thanks!
Darrell
Just a reminder that the meeting is 01 February at 12 PM Eastern Standard Time.
You may join us on IRC in the #trinity-desktop-meeting channel. If you
do not have an IRC client, you may use this link: http://bit.ly/zVixaW
to join us and participate.
See you then!
--
later daze. :: Robert Xu :: rxu.lincomlinux.org :: protocol.by/rxu
As I revise and update the Trinity documentation, I will confront questions I can't answer, or should not answer on my own without team opinions.
The documentation often refers to the K-Menu.
The Trinity artwork contains a "T" button icon rather than a K. Should we refer to this button as the T-Menu?
I lean toward updating all documentation to reference the T-Menu despite some of the underlying app and library names. For example, kmenueditor. Many TDE apps still use the "k" prefix and so this would not be any different. Yet I think T-Menu is more consistent with "Trinity Desktop Environment."
Objections?
Darrell
Many of us who have used KDE3/TDE for many years probably have forgotten that in the T-Menu is an option named Help. The kdehelpcenter starts when selecting that menu option. The second link in the help center table of contents is to the KDE3 User's Guide, which I am updating to become the Trinity User's Guide.
I propose we include a new T-Menu option just above or below the Help option with a direct link to the TDE User's Guide.
To computer savvy users this new menu option might seem redundant, but the new menu option would prove useful to new users.
Rather than "hard-coding" the new menu option like the Help menu, this new menu option could be an optional menu in the Panel configuration. The default Trinity desktop would have that menu option enabled.
Are there any objections to this proposal?
A second proposal is the default Trinity desktop includes an icon that is a direct link to the User's Guide.
This could be a special "device icon" much like "My Documents," "Printers," or "Trash" that allows users to control the appearance, but the default Trinity desktop would display that icon, just like the other special device icons.
Are there any objections to this proposal?
Darrell
I have wireless-tools-29-i486-6 insttalled.
iwlib.h exists in /usr/include.
When compiling tdenetwork from git it stops fails during config telling me
it couldn't find wireless tools 29>+.
Disabling the building of wifi (only used for kwifimanager?) allows me to
compile.
After looking through configure.in.in for wifi it appears to be searching
for a certain version of iwlib.h, but misses the mark.
Any ideas why it may be blind to wireless tools?
Jay
From what I recall of the syntax, this fragment from kpanelapplet.cpp
in kdelibs-3.5.13 *looks* like it's making direct calls into QT3's
namespace (not tqtinterface's), even though it doesn't #include any
QT files, just TQT stuff:
Qt::Orientation KPanelApplet::orientation() const
{
if( _position == pTop || _position == pBottom ) {
return Qt::Horizontal;
} else {
return Qt::Vertical;
}
}
My understanding is, the QT namespace is included in this code
via TQT, allowing the code to compile.
If so, this might explain the lengthy linking bug I posted a little
while ago (--as-needed does not like transitive dependencies like
this). Can someone confirm that this is in fact what is happening?
I haven't written a line of C++ code in ~15 years, so I'm not sure
I remember how it works.
If I'm right, I'll go ahead and file the bug, but I don't want to
clutter Bugzilla with non-issues.
First little introduction:
As some of you know I'm in the process of creating PKGBUILDs for arch
linux, which are instructions for building binaries.
And I want them to be nearly-perfect and provide everything that they
should provide. How do I know what they should provide? By looking
what was done in the past. I got PKGBUILDs for 3.5.12 form kdemod3
git, i looked a little at old official KDE3 PKGBUILDs for arch, and I
managed to include everything up until I got to kdebase PKGBUILD.
My problem:
I noticed that kdemod3 provided configuration files for pam. I was
compiling kdebase with pam support, but never cared to check if this
support was complete with configuration files. I got curious and begun
examining things.
From what I understood reading README.pam found in kdebase main dir,
the "make install" should create automatically pam config files using
mkpamserv script found in kdebase. By default the pam service would be
called kde and the config file would be called the same. This would
fit, since from what I read up until now on pam, the config file
should be called the same as service name specified in pam_start()
function. But usign autotools one could change the default name to
something else using --with-pam=<name> (in fact this was done in the
kdemod3 PKGBUILD to ensure KDE4 compatibility, since KDE4 packages
provide it's own pam config file called kde), or better, provide
different pam config files for each app that used pam using
--with-kdm-pam=<name> for kdm, --with-kpc-pam=<name> for kcheckpass
and --with-kss-pam for kscreensaver.
Now, with CMake this isn't done. I still can manually generate the pam
config files, using mkpamsrv script, but I wonder how the pam session
(and config file) should be called. By default it would be kde, but I
can't use it, since it would overwrite the kde4 pam config or would be
overwritten on kde4 installation. And if I simply generate pam config
files with other name, how do I ensure that apps with pam support are
actually using them, and not serching instead for config/session
called kde?
Followup: 2/3 PM EST? Or back such as 12 PM EST?
Also, can we get a list of topics?
The few ones I can think of (I detached myself from Trinity stuff the
past few months):
Git migration
Qt3/TQt3?
CMake - what's left
Observations/Concerns
--
later daze. :: Robert Xu :: rxu.lincomlinux.org :: protocol.by/rxu
