20 Dec
2011
20 Dec
'11
11:23 a.m.
I have a testing account I use often. That account gets used in my real machines and
virtual machines. For many years I have used a left-handed mouse (mouse buttons reversed).
Because the virtual machine passes the mouse buttons transparently, I wrote a snippet for
that user's .bashrc file to test the mouse button configuration and swap the mouse
buttons in kcminputrc as necessary. That way I can use a left-handed mouse regardless of
which environment the account gets used.
To test my mouse buttons I run the following in that user's .bashrc:
kreadconfig --file $PROFILE_HOME/share/config/kcminputrc --group Mouse --key
MouseButtonMapping
Simple enough.
Today I booted my PII machine that has a partition for Trinity 3.5.13. I login from the
command line, which means X is not yet running. When I logged in with that testing account
I received the following message:
NVIDIA OpenGL Driver requires CPUs with SSE to run.
The current CPU does not support SSE.
Superficially, I saw this message because originally I had cloned a testing partition from
another hard drive and that partition had the proprietary Nvidia drivers installed. The
PII machine does not support those drivers. Hence the messages.
The real mystery is what is kreadconfig and kwriteconfig doing that indirectly causes
those messages? I suspect a linking problem, which ldconfig resolved after I removed the
Nvidia packages. Nonetheless, why are those two commands querying X libraries when X is
not running? Is this a feature or a bug? :)
Darrell
20 Dec
20 Dec
11:41 a.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
On Mon, 19 Dec 2011 20:23:51 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
I have a testing account I use often. That account
gets used in my
real machines and virtual machines. For many years I have used a
left-handed mouse (mouse buttons reversed). Because the virtual
machine passes the mouse buttons transparently, I wrote a snippet for
that user's .bashrc file to test the mouse button configuration and
swap the mouse buttons in kcminputrc as necessary. That way I can use
a left-handed mouse regardless of which environment the account gets
used.
To test my mouse buttons I run the following in that user's .bashrc:
kreadconfig --file $PROFILE_HOME/share/config/kcminputrc --group
Mouse --key MouseButtonMapping
Simple enough.
Today I booted my PII machine that has a partition for Trinity
3.5.13. I login from the command line, which means X is not yet
running. When I logged in with that testing account I received the
following message:
NVIDIA OpenGL Driver requires CPUs with SSE to run.
The current CPU does not support SSE.
Superficially, I saw this message because originally I had cloned a
testing partition from another hard drive and that partition had the
proprietary Nvidia drivers installed. The PII machine does not
support those drivers. Hence the messages.
The real mystery is what is kreadconfig and kwriteconfig doing that
indirectly causes those messages? I suspect a linking problem, which
ldconfig resolved after I removed the Nvidia packages. Nonetheless,
why are those two commands querying X libraries when X is not
running? Is this a feature or a bug? :)
dd@darkstar:~$ ldd `which kwriteconfig`
linux-gate.so.1 => (0xffffe000)
libkdecore.so.4 => /opt/kde3/lib/libkdecore.so.4 (0xf7489000)
libDCOP.so.4 => /opt/kde3/lib/libDCOP.so.4 (0xf744c000)
libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0xf741b000)
libtqt.so.4 => /opt/kde3/lib/libtqt.so.4 (0xf7419000)
libqt-mt.so.3 => /opt/kde3/lib/libqt-mt.so.3 (0xf6d52000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xf6d2f000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xf6c14000)
libz.so.1 => /usr/lib/libz.so.1 (0xf6c00000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xf6bfd000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xf6bf8000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xf6be0000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xf6bd8000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf6ae8000)
libm.so.6 => /lib/libm.so.6 (0xf6ac2000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xf6aa5000)
libc.so.6 => /lib/libc.so.6 (0xf6942000)
libdl.so.2 => /lib/libdl.so.2 (0xf693d000)
libmng.so.1 => /usr/lib/libmng.so.1 (0xf68da000)
libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0xf68a5000)
libpng14.so.14 => /usr/lib/libpng14.so.14 (0xf687f000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xf6814000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0xf67fd000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xf67f6000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xf67ed000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xf67ea000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xf67d7000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xf6761000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xf6732000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xf6724000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf670b000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xf66f3000)
libuuid.so.1 => /lib/libuuid.so.1 (0xf66ef000)
/lib/ld-linux.so.2 (0xf774f000)
liblcms.so.1 => /usr/lib/liblcms.so.1 (0xf66bb000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xf66b6000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xf66b3000)
libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xf66b1000)
libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xf66a1000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xf6697000)
libXt.so.6 => /usr/lib/libXt.so.6 (0xf6646000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xf6643000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xf663e000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xf6618000)
librt.so.1 => /lib/librt.so.1 (0xf660e000)
dd@darkstar:~$ ldd /opt/kde3/lib/libkdecore.so.4.2.0
linux-gate.so.1 => (0xffffe000)
libDCOP.so.4 => /opt/kde3/lib/libDCOP.so.4 (0xf7451000)
libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0xf7420000)
libz.so.1 => /usr/lib/libz.so.1 (0xf73f2000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xf73ef000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xf73e9000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xf73d2000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xf73ca000)
libdl.so.2 => /lib/libdl.so.2 (0xf73c6000)
libtqt.so.4 => /opt/kde3/lib/libtqt.so.4 (0xf73c4000)
libqt-mt.so.3 => /opt/kde3/lib/libqt-mt.so.3 (0xf6cfe000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xf6cf4000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xf6bd9000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf6ae9000)
libm.so.6 => /lib/libm.so.6 (0xf6ac3000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xf6aa6000)
libc.so.6 => /lib/libc.so.6 (0xf6943000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xf6934000)
libuuid.so.1 => /lib/libuuid.so.1 (0xf6930000)
/lib/ld-linux.so.2 (0xf7754000)
libmng.so.1 => /usr/lib/libmng.so.1 (0xf68cd000)
libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0xf6898000)
libpng14.so.14 => /usr/lib/libpng14.so.14 (0xf6872000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xf6806000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0xf67f0000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xf67e9000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xf67e0000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xf67dd000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xf67ca000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xf6753000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xf6725000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf670c000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xf66f4000)
liblcms.so.1 => /usr/lib/liblcms.so.1 (0xf66c1000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xf66bb000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xf66b8000)
libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xf66b6000)
libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xf66a6000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xf669d000)
libXt.so.6 => /usr/lib/libXt.so.6 (0xf664b000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xf6648000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xf6643000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xf661d000)
librt.so.1 => /lib/librt.so.1 (0xf6614000)
I don't think we should go much farther in the investigation: the
dependency of kwriteconfig on kdelibs brings automatic dependency on X
libraries even if it is a console program.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
11:52 a.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
/dev/ammo42 wrote:
I don't think we should go much farther in the
investigation: the
dependency of kwriteconfig on kdelibs brings automatic dependency on X
libraries even if it is a console program.
Good point. That is one reason I like Qt4 much beter than Qt3. For
applications that don't need X, you don't pull that stuff in. Qt3 is a
single monolithic library with everything, while Qt4 is a collection of
21 libraries. For something like kwriteconfig, it would probably only
need libQtCore.
-- Bruce
12:44 p.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
I don't
think we should go much farther in the
investigation: the
dependency of kwriteconfig on kdelibs brings
automatic
dependency on X
libraries even if it is a console program.
Good point. That is one reason I like Qt4 much beter
than Qt3. For applications that don't need X, you
don't pull that stuff in. Qt3 is a single monolithic
library with everything, while Qt4 is a collection of 21
libraries. For something like kwriteconfig, it would
probably only need libQtCore.
12:55 p.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
Darrell Anderson wrote:
I doubt it. Porting from Qt3 to Qt4 is non-trivial, but the amount of
work depends on the program. There's no way to eliminate X as long as
Qt3 is used.
-- Bruce
>> I don't think we should go much farther in
the
> investigation: the
>> dependency of kwriteconfig on kdelibs brings automatic
> dependency on X
>> libraries even if it is a console program.
Good point.
That is one reason I like Qt4 much beter than Qt3.
For applications that don't need X, you don't pull that stuff in.
Qt3 is a single monolithic library with everything, while Qt4 is a
collection of 21 libraries. For something like kwriteconfig, it
would probably only need libQtCore.
Thanks to both.
For you folks more experienced with coding TDE and Qt3, are there any
clever ways to eliminate the overhead with the non X commands? Seems
that would be more efficient and shave a few micro/millisecond
response times here and there, especially for older hardware. :)
1:49 p.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
For you folks
more experienced with coding TDE and
Qt3, are there any
clever ways to eliminate the overhead with the
non X
commands? Seems
that would be more efficient and shave a few
micro/millisecond
response times here and there, especially for
older
hardware. :)
I doubt it. Porting from Qt3 to Qt4 is non-trivial,
but the amount of work depends on the program. There's
no way to eliminate X as long as Qt3 is used. 
4:54 p.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
For you folks more experienced with coding TDE and
Qt3, are there any
clever ways to eliminate the overhead with the
non X
commands? Seems
that would be more efficient and shave a few
micro/millisecond
response times here and there, especially for
older
hardware. :)
I doubt it. Porting from Qt3 to Qt4 is non-trivial,
but the amount of work depends on the program. There's
no way to eliminate X as long as Qt3 is used. 
8:15 p.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
On 20 Dec 2011, Timothy Pearson spake thusly:
I was not implying any porting to Qt4. :) Is there a decent technical
reason why the X overhead can't be eliminated from the non X TDE commands?
In theory it might be possible to modify the Qt3 source and add an X-less
application constructor. I have no idea how complex that would be.
Of course this would still pull in the X shared libraries, incurring
most of the startup costs nonetheless. Fixing *that* would be a lot more
work. (Also, who knows how many places inside Qt3 assume the existence
of a live X display connection? After all, they've always had one they
can rely on.)
--
NULL && (void)
For you folks
more experienced with coding TDE and
Qt3, are there any
clever ways to eliminate the overhead with the
non X
commands? Seems
that would be more efficient and shave a few
micro/millisecond
response times here and there, especially for
older
hardware. :)
I doubt it. Porting from Qt3 to Qt4 is non-trivial,
but the amount of work depends on the program. There's
no way to eliminate X as long as Qt3 is used.
21 Dec
21 Dec
12:21 a.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
Nix wrote:
Of course this would still pull in the X shared
libraries, incurring
most of the startup costs nonetheless. Fixing *that* would be a lot more
work. (Also, who knows how many places inside Qt3 assume the existence
of a live X display connection? After all, they've always had one they
can rely on.)
Trolltech did the separation in Qt4. Their major libraries are
libQtCore, libQtGui, libQtMultimedia.so, and libQtNetwork.so. The other
libraries essentially add on additional functionality.
The same sort of thing could be done with Qt3, but I question the value.
If someone is building a new application, they would probably just
build it with Qt4.
-- Bruce
12:41 a.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
On 20 December 2011 12:21, Bruce Dubbs <bruce.dubbs(a)gmail.com> wrote:
Nix wrote:
Of course this would still pull in the X shared libraries, incurring
some applications would load faster and/or use less memory because they
aren't linking a giant so file and instead fewer smaller ones that they
actually need
most of the startup costs nonetheless. Fixing
*that* would be a lot more
work. (Also, who knows how many places inside Qt3 assume the existence
of a live X display connection? After all, they've always had one they
can rely on.)
Trolltech did the separation in Qt4. Their major libraries are libQtCore,
libQtGui, libQtMultimedia.so, and libQtNetwork.so. The other libraries
essentially add on additional functionality.
The same sort of thing could be done with Qt3, but I question the value.
If someone is building a new application, they would probably just build
it with Qt4.
-- Bruce
12:54 a.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
Calvin Morrison wrote:
On 20 December 2011 12:21, Bruce Dubbs
<bruce.dubbs(a)gmail.com> wrote:
> Trolltech did the separation in Qt4. Their major
libraries are libQtCore,
> libQtGui, libQtMultimedia.so, and libQtNetwork.so. The other libraries
> essentially add on additional functionality.
>
> The same sort of thing could be done with Qt3, but I question the value.
> If someone is building a new application, they would probably just build
> it with Qt4.
some applications would load faster and/or use less
memory because they
aren't linking a giant so file and instead fewer smaller ones that they
actually need
LOL. The libraries you refer to are already in memory. They don't have
to be loaded again. That's what a shared library does. Even if they
weren't in memory, the system would have to be instrumented to measure
the change. It would be imperceptible to the user.
-- Bruce
22 Dec
22 Dec
3:54 a.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
On 20 Dec 2011, Bruce Dubbs said:
Calvin Morrison wrote:
It would use a bit less memory, and speed up startup a bit, because
fewer relocations are required, and relocations necessarily require
making the page containing the relocations private to that process, and
writable. Even on a prelinked system, some memory would be saved,
because two relocations are required per C++ class even when prelink is
in use, and a split Qt would contain many fewer classes in the
non-X-using part than exist in all of Qt now.
(But despite that, you are surely right that the cost/benefit tradeoff
is surely not worth it for Qt3.)
--
NULL && (void)
On 20 December 2011 12:21, Bruce Dubbs
<bruce.dubbs(a)gmail.com> wrote:
> Trolltech did the separation in Qt4. Their
major libraries are libQtCore,
> libQtGui, libQtMultimedia.so, and libQtNetwork.so. The other libraries
> essentially add on additional functionality.
>
> The same sort of thing could be done with Qt3, but I question the value.
> If someone is building a new application, they would probably just build
> it with Qt4.
some applications would load faster and/or use
less memory because they
aren't linking a giant so file and instead fewer smaller ones that they
actually need
LOL. The libraries you refer to are already in memory. They don't have
to be loaded again. That's what a shared library does. Even if they
weren't in memory, the system would have to be instrumented to measure
the change. It would be imperceptible to the user.
9:11 a.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
On 21 December 2011 15:54, Nix <nix(a)esperi.org.uk> wrote:
It would use a bit less memory, and speed up startup a bit, because
fewer relocations are required, and relocations necessarily require
making the page containing the relocations private to that process, and
writable. Even on a prelinked system, some memory would be saved,
because two relocations are required per C++ class even when prelink is
in use, and a split Qt would contain many fewer classes in the
non-X-using part than exist in all of Qt now.
(But despite that, you are surely right that the cost/benefit tradeoff
is surely not worth it for Qt3.)
--
NULL && (void)
It would not be a giant benefit to users who already have loaded the
libraries into memory, but it would for people who are looking to use
Trinity applications as stand alone.
On 20 Dec 2011, Bruce Dubbs said:
Calvin
Morrison wrote:
libQtCore,
On 20 December 2011 12:21, Bruce Dubbs
<bruce.dubbs(a)gmail.com> wrote:
>> Trolltech did the separation in Qt4. Their major libraries are >> libQtGui, libQtMultimedia.so, and
libQtNetwork.so. The other libraries
>> essentially add on additional functionality.
>>
>> The same sort of thing could be done with Qt3, but I question the
value.
>> If someone is building a new
application, they would probably just
build
> it
with Qt4.
some applications would load faster and/or use
less memory because they
aren't linking a giant so file and instead fewer smaller ones that they
actually need
LOL. The libraries you refer to are already in memory. They don't have
to be loaded again. That's what a shared library does. Even if they
weren't in memory, the system would have to be instrumented to measure
the change. It would be imperceptible to the user.
9:49 a.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
It would not be a giant benefit to users who
already have loaded the libraries into memory, but it would
for people who are looking to use Trinity applications as
stand alone.
Okay, computer science majors. Quit trying to see who can crow the loudest. :)
All I want to know is whether the non gui commands of TDE such as kwriteconfig and
kreadconfig can (easily) be built without the X overhead.
Darrell
10:02 a.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
On Wed, 21 Dec 2011 18:49:01 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
You would either have to:
-separate non-X-dependent parts of Qt like for Qt4
-not do that separation but instead use the X functions as weak symbols
and add a dlopen() of X libraries to every X-using Qt3 application
I really don't see a really easy option; there is a third option which
would be to compile both with-X and without-X versions of kdelibs and
Qt3 but without significant linker magic it is likely to load both
versions of kdelibs and Qt3 within a Trinity session.
It would not
be a giant benefit to users who
already have loaded the libraries into memory, but it would
for people who are looking to use Trinity applications as
stand alone.
Okay, computer science majors. Quit trying to see who can crow the
loudest. :)
All I want to know is whether the non gui commands of TDE such as
kwriteconfig and kreadconfig can (easily) be built without the X
overhead.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
12:02 p.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
All I want to
know is whether the non gui commands of
TDE such as
kwriteconfig and kreadconfig can (easily) be
built
without the X
overhead.
You would either have to:
-separate non-X-dependent parts of Qt like for Qt4
-not do that separation but instead use the X functions as
weak symbols
and add a dlopen() of X libraries to every X-using Qt3
application
I really don't see a really easy option; there is a third
option which
would be to compile both with-X and without-X versions of
kdelibs and
Qt3 but without significant linker magic it is likely to
load both
versions of kdelibs and Qt3 within a Trinity session.
1:14 p.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
Darrell Anderson wrote:
Here's an easy option:
if [ -r ~/.kde/share/config/kcminputrc -a \
"x`grep LeftHanded ~/.kde/share/config/kcminputrc`" != "x" ];
then
echo left
else
echo right
fi
-- Bruce
>> All I want to know is whether the non gui
commands of TDE such as
>> kwriteconfig and kreadconfig can (easily) be built without the X
>> overhead.
> You would either have to: -separate
non-X-dependent parts of Qt
> like for Qt4 -not do that separation but instead use the X
> functions as weak symbols and add a dlopen() of X libraries to
> every X-using Qt3 application
I really
don't see a really easy option; there is a third option
which would be to compile both with-X and without-X versions of
kdelibs and Qt3 but without significant linker magic it is likely
to load both versions of kdelibs and Qt3 within a Trinity session.
Fair enough. Too bad. :(
1:26 p.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
> I really
don't see a really easy option; there is
a third option
> which would be to compile both with-X and
without-X versions of kdelibs and Qt3 but without
significant linker magic it is likely
> to load both versions of kdelibs and Qt3
within a
Trinity session.
Fair enough. Too bad. :(
Here's an easy option:
if [ -r ~/.kde/share/config/kcminputrc -a \
"x`grep LeftHanded
~/.kde/share/config/kcminputrc`" != "x" ]; then
echo left
else
echo right
fi
1:56 p.m.
New subject: [trinity-devel] Unexpected kreadconfig/kwriteconfig messages
Darrell Anderson wrote:
Thanks much, but you must have missed my original post --- I'm
already doing that. :)
Yes, I missed that.
> I really don't see a really easy option; there
is
a third option
> which would be to compile both with-X and
without-X versions of kdelibs and Qt3 but without
significant linker magic it is likely
> to load both versions of kdelibs and Qt3
within a
Trinity session.
Fair enough. Too bad. :(
Here's an
easy option:
if [ -r ~/.kde/share/config/kcminputrc -a \
"x`grep LeftHanded
~/.kde/share/config/kcminputrc`" != "x" ]; then
echo left
else
echo right
fi In my original message I asked why I saw specific
Nvidia error
messages when using an allegedly non-gui command in a console outside of
X. I solved that mystery and was shown that the commands were built with
X dependencies.
Yes.
The discussion since then is why those non-gui
commands can't build
without the X dependency. My "too bad" comment was in reference to
building those commands otherwise. :)
That's one reason Qt4 has multiple libraries. Doing that for Qt3 seems
to be reinventing the wheel. BTW, I tried to build Qt4 without the X
libraries, even though there is a configure option --without-x. It
didn't work. However, I could write a program that did not link to any
X libraries. Also, programs written to Qt4 (not KDE4) work fine in
KDE3, graphical or otherwise.
-- Bruce
4789
days inactive
4791
days old
18 comments
6 participants
participants (6)
-
/dev/ammo42 -
Bruce Dubbs -
Calvin Morrison -
Darrell Anderson -
Nix -
Timothy Pearson