trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: September 2010

Re: [trinity-devel] Network status indicator errors

From: "Timothy Pearson" <kb9vqf@...>
Date: Sun, 19 Sep 2010 18:10:35 -0500
> The following errors appear in the xsession logs:
>
> QObject::connect: No such signal MediaImpl::warning(const QString&)
> QObject::connect:  (sender name:   'unnamed')
> QObject::connect:  (receiver name: 'unnamed')
> QObject::connect: No such signal
> ConnectionManager::statusChanged(QString,NetworkStatus::EnumStatus)
> QObject::connect:  (sender name:   'connection_manager')
> QObject::connect:  (receiver name: 'networkstatusindicator')
> QObject::connect: No such signal
> ConnectionManager::statusChanged(QString,NetworkStatus::EnumStatus)
> QObject::connect:  (sender name:   'connection_manager')
> QObject::connect:  (receiver name: 'networkstatusindicator')
>
> I thought the problem might be related to the kded network status daemon.
> Yet I when I disable that daemon I still see the messages. Maybe the
> problem is still related to that daemon, I don't know.
<snip>
Not at all.  There is a built in cross-distro connection monitor
(originally from kdepim); this is what is generating the connection
errors.  I believe I have fixed them in the latest SVN revision of kdelibs
and kdebase.
>
> Maybe the problem is related to a specific network status applet that
> typically runs on Debian systems. I think on Debian systems such an applet
> is presumed, but no such critter on Slackware.
>
> Conversely, after quashing those messages, I'd like to know what specific
> applet (/usr/bin/???) or daemon the code is looking for.
None.  Those are internal Qt connection error messages.

> If an external
> package and not the internal kded daemon, there might be a build script
> floating around for that package. Possibly then I could install and test
> Trinity for what is expected to happen with those error messages.
<snip>
> Based upon the first message, I'm guessing there is a missing #include
> <mediaimpl.h> statement somewhere.

Right you were!

>
> I'm curious why the error messages reference QObject and Qstring rather
> than TQObject and TQString.

TQt is a *very* thin wrapper around Qt.  During compilation, the TQt
objects are converted to the appropriate Qt objects.  This means that at
runtime, the original Qt objects reassert themselves in any error/warning
messages.

Also, I think I have fixed the XDG autostart problem, and the Konqueror
toolbar issue is also fixed.  In other words, barring a major crashing
issue or functionality problem the code should be very close to finalized
for 3.5.12!

Tim