My first usability test of Trinity was in a virtual machine. Trinity loaded just fine --- but ignored all of my previous ~/.kde profile settings. Hey! What? :)
Not to mention the evil bouncing mouse cursor! Okay, I can solve that irritant when I build the package.
What happened with my desktop?
First clue: Trinity is using ~/.kde3 rather than ~/.kde. Yet my $KDEHOME environment variable is set to ~/.kde. Hmm. Where is this being ignored or overridden?
Yes, I can rename ~/.kde to ~/.kde3. But I should not have to. Trinity should honor my $KDEHOME variable.
First suspect: /usr/bin/startkde. I have some proposed patches for startkde, but that can wait for another thread. Nope. Not the culprit because I exited KDE, restored my ~/.kde profile, renamed the new startkde, and restored my old startkde. When I started X, Trinity again created ~/.kde3 and ignored my ~/.kde profile and $KDEHOME variable..
What is hard-coded to create and use ~/.kde3? A .desktop file somewhere?
Been a looooong time since I wandered around with the KDE startup sequence.
Second, there are folder icons on the desktop for every directory in the root level. They are not device icons and I don't know how to disable that effect. I also have lost my previous desktop icons.
Third, something is starting the HP system tray. I remember that being an annoyance three or four years ago, but I don't remember how to stop that. There is a file in /etc/xdg/autostart, but there is one in my office system too and the tray does not start there.
Fourth, There are messages in xsession-errors that seem to indicate something accessing samba, a service I don't have started in the virtual machine.
Fifth, the Klipper tray icon is huge and does not display completely in the tray --- the top and bottom of the icon are missing. I don't seem to find anything in kcontrol/icons.
Sixth, the color of my konsole changed from black to white.
I realize some of the problems might be cause by using a 3.5.10 profile, but then again perhaps not.
I'm suffering a bit from new culture shock. 3.5.12 is not 3.5.10. I did not expect so many configuration changes, however. :) If I have to start with a new profile and rebuild the profile I have been using for several years I am likely to become manic depressive.
Suddenly I feel very tired!
My first usability test of Trinity was in a virtual machine. Trinity loaded just fine --- but ignored all of my previous ~/.kde profile settings. Hey! What? :)
Not to mention the evil bouncing mouse cursor! Okay, I can solve that irritant when I build the package.
What happened with my desktop?
First clue: Trinity is using ~/.kde3 rather than ~/.kde. Yet my $KDEHOME environment variable is set to ~/.kde. Hmm. Where is this being ignored or overridden?
Yes, I can rename ~/.kde to ~/.kde3. But I should not have to. Trinity should honor my $KDEHOME variable.
First suspect: /usr/bin/startkde. I have some proposed patches for startkde, but that can wait for another thread. Nope. Not the culprit because I exited KDE, restored my ~/.kde profile, renamed the new startkde, and restored my old startkde. When I started X, Trinity again created ~/.kde3 and ignored my ~/.kde profile and $KDEHOME variable..
What is hard-coded to create and use ~/.kde3? A .desktop file somewhere?
Been a looooong time since I wandered around with the KDE startup sequence.
Second, there are folder icons on the desktop for every directory in the root level. They are not device icons and I don't know how to disable that effect. I also have lost my previous desktop icons.
Third, something is starting the HP system tray. I remember that being an annoyance three or four years ago, but I don't remember how to stop that. There is a file in /etc/xdg/autostart, but there is one in my office system too and the tray does not start there.
Fourth, There are messages in xsession-errors that seem to indicate something accessing samba, a service I don't have started in the virtual machine.
Fifth, the Klipper tray icon is huge and does not display completely in the tray --- the top and bottom of the icon are missing. I don't seem to find anything in kcontrol/icons.
Sixth, the color of my konsole changed from black to white.
I realize some of the problems might be cause by using a 3.5.10 profile, but then again perhaps not.
I'm suffering a bit from new culture shock. 3.5.12 is not 3.5.10. I did not expect so many configuration changes, however. :) If I have to start with a new profile and rebuild the profile I have been using for several years I am likely to become manic depressive.
Suddenly I feel very tired!
You should be able to use your existing profile without problems. Come to think of it, I ran into similar problems on one of my systems once. Do you have stock KDE 3.5.10 installed on that virtual machine anywhere or is only Trinity 3.5.12 installed?
Beyond that, I would try the following:
Back up your .kde directory, remove the .kde3 directory, and let Trinity create its own .kde3 profile directory from scratch. (This is just for a test; we need to find a way to get your old profile to work). Do you see the same issues on the "new" desktop?
Trinity is supposed to honor the KDEHOME variable. Let me do a little digging to see what happened.
Tim
My first usability test of Trinity was in a virtual machine. Trinity loaded just fine --- but ignored all of my previous ~/.kde profile settings. Hey! What? :)
Not to mention the evil bouncing mouse cursor! Okay, I can solve that irritant when I build the package.
What happened with my desktop?
First clue: Trinity is using ~/.kde3 rather than ~/.kde. Yet my $KDEHOME environment variable is set to ~/.kde. Hmm. Where is this being ignored or overridden?
Yes, I can rename ~/.kde to ~/.kde3. But I should not have to. Trinity should honor my $KDEHOME variable.
First suspect: /usr/bin/startkde. I have some proposed patches for startkde, but that can wait for another thread. Nope. Not the culprit because I exited KDE, restored my ~/.kde profile, renamed the new startkde, and restored my old startkde. When I started X, Trinity again created ~/.kde3 and ignored my ~/.kde profile and $KDEHOME variable..
What is hard-coded to create and use ~/.kde3? A .desktop file somewhere?
~/.kde3 is set in kstandarddirs.cpp and also in startkde. startkde now has a fix to honor the $KDEHOME environment variable, and kstandarddirs.cpp has always had code to honor it.
Been a looooong time since I wandered around with the KDE startup sequence.
Second, there are folder icons on the desktop for every directory in the root level. They are not device icons and I don't know how to disable that effect. I also have lost my previous desktop icons.
<snip>
I am looking into this one, which fortunately I am still able to replicate on the older machine I mentioned earlier. Something is messed up with the XDG desktop paths; on my system "kde-config --userpath desktop" returns "/".
Tim
My first usability test of Trinity was in a virtual machine. Trinity loaded just fine --- but ignored all of my previous ~/.kde profile settings. Hey! What? :)
Not to mention the evil bouncing mouse cursor! Okay, I can solve that irritant when I build the package.
What happened with my desktop?
First clue: Trinity is using ~/.kde3 rather than ~/.kde. Yet my $KDEHOME environment variable is set to ~/.kde. Hmm. Where is this being ignored or overridden?
Yes, I can rename ~/.kde to ~/.kde3. But I should not have to. Trinity should honor my $KDEHOME variable.
First suspect: /usr/bin/startkde. I have some proposed patches for startkde, but that can wait for another thread. Nope. Not the culprit because I exited KDE, restored my ~/.kde profile, renamed the new startkde, and restored my old startkde. When I started X, Trinity again created ~/.kde3 and ignored my ~/.kde profile and $KDEHOME variable..
What is hard-coded to create and use ~/.kde3? A .desktop file somewhere?
~/.kde3 is set in kstandarddirs.cpp and also in startkde. startkde now has a fix to honor the $KDEHOME environment variable, and kstandarddirs.cpp has always had code to honor it.
Been a looooong time since I wandered around with the KDE startup sequence.
Second, there are folder icons on the desktop for every directory in the root level. They are not device icons and I don't know how to disable that effect. I also have lost my previous desktop icons.
<snip>
I am looking into this one, which fortunately I am still able to replicate on the older machine I mentioned earlier. Something is messed up with the XDG desktop paths; on my system "kde-config --userpath desktop" returns "/".
Tim
OK, I think the problem has been fixed in revision 1176159. Slackware must not set up XDG correctly; Trinity needed some default settings added to handle this particular case.
Update kdelibs and kdebase, and recompile/reinstall both. Hopefully that will get you a functional desktop, and the minor issues can be debugged more easily.
With respect to ~/.kde3, how did you set HDEHOME? On my systems I would do this in the terminal:
export KDEHOME=~/.kde /opt/kde3/bin/startkde
Once kdebase has been updated it should respect the above sequence (I will check it myself after recompilation is finished).
Tim
I'll continue my previous usability report with additional details. I can submit several bug reports to bugzilla, but I'll first post my observations here.
My apologies for not sending this post before you started troubleshooting. I'll update svn and rebuild, but I think most of these details still hold.
I ran these tests in a sandboxed virtual machine as root and as non-root.
===========================================================
1. As non-root Trinity seems to completely honor $KDEHOME. There is no ~/.kde3 directory created and Trinity uses my existing ~/.kde directory.
As root Trinity does not fully honor $KDEHOME.
2. Because $KDEHOME is not honored, Trinity creates a new ~/.kde3 directory and ignores all previous settings in ~/.kde. Running kde-config --localprefix shows that I built the packages using ~/.kde3. That's fine as a default, but should be ignored if $KDEHOME is already set in the environment.
3. Some echo commands reveal $KDEHOME is set before startkde runs, but the variable is ignored. I suspect Trinity is partially honoring the variable but sometime in the loading process shifts to ignoring. I have a conky display in my original ~/.kde/Autostart diretory and the conky display loads after Trinity starts. The conky.desktop file is not in the newer ~/.kde3/Autostart directory. Exiting X and restarting Trinity again starts the conky display. Thus my suspicion of first honoring $KDEHOME and then later ignoring.
The $KDEHOME problem seems isolated to root. Anal fanatics can argue all they want that people should not run as root or run X as root. Those are security arguments and not usability arguments. If people want to run X as root then they will --- and the system should be bug-free. :)
===========================================================
4. The existing startkde is Debianized and causes breakage on Slackware systems. I am submitting a proposed new startkde script. The proposed script avoids certain presumptions and adds some tests before running various commands. The proposed script also adds additional echo messages to help debugging efforts.
===========================================================
5. As root, the .xsession-error log shows the following errors:
... startkde: Starting KDE. (message is from my proposed startkde script) KDE_FULL_SESSION: true (message is from my proposed startkde script) KDE_SESSION_UID: 0 (message is from my proposed startkde script) kbuildsycoca running... Reusing existing ksycoca Invalid entry (missing '=') at /tmp/kde-root/kconf_updatea8Qi7b.tmp:1 Invalid entry (missing '=') at /tmp/kde-root/kconf_updateBSSSOa.tmp:1 startkde: Looks like kdeinit started. (message is from my proposed startkde script) Warning: connect() failed: : No such file or directory QObject::connect: No such signal Kicker::settingsChanged(SettingsCategory) QObject::connect: (sender name: 'kicker') QObject::connect: (receiver name: 'animtt') kbuildsycoca running... Reusing existing ksycoca ...
As non-root: the .xsession-error log shows the following errors:
QObject::connect: No such signal Kicker::settingsChanged(SettingsCategory) QObject::connect: (sender name: 'kicker') QObject::connect: (receiver name: 'animtt') /usr/bin/xmodmap: unable to open file '/usr/share/apps/kxkb/ubuntu.xmodmap' for reading /usr/bin/xmodmap: 1 error encountered, aborting. /usr/bin/xmodmap: unable to open file '/home/users/tester/.Xmodmap' for reading /usr/bin/xmodmap: 1 error encountered, aborting.
Ubuntu.xmodmap? This is Slackware. :) I can stop those error messages when I disable the related keyboard options in kcontrol. Regardless, I don't use an xmodmap file here. Users should not be bothered with such related messages. The messages might be caused by xmodmap,but I never have seen any such errors before until running Trinity. I have the same X packages installed on my virtual system as my actual system.
I saw these additional error messages as non-root:
WARNING: DCOPReply<QString>: cast to 'TQString' error QObject::connect: No such signal ConnectionManager::statusChanged(NetworkStatus::EnumStatus) QObject::connect: (sender name: 'connection_manager') QObject::connect: (receiver name: 'networkstatusindicator') QObject::connect: No such signal ConnectionManager::statusChanged(NetworkStatus::EnumStatus) QObject::connect: (sender name: 'connection_manager') QObject::connect: (receiver name: 'networkstatusindicator')
So again, seems there is some kind of Debianization here looking for some kind of network manager that does not exist on Slackware.
===========================================================
6. Something is trying access samba config files. I have seen such messages before when testing Debian Lenny. Therefore I suspect some kind of Trinity/Debian hook into a network manager of some sort.
params.c:OpenConfFile() - Unable to open configuration file "/root/.smb/smb.conf.append": No such file or directory Using netbios name {HOSTNAME}. Using workgroup {WORKGROUP}.
===========================================================
7. Trinity seems to be ignoring ~/.config/autostart. In that directory I have a hplip-systray.desktop with the following [Desktop Entry] directive: Hidden=true. That directive should prevent hplip-systray from starting. An hplip-systray.desktop file is found in /etc/xdg/autostart, but the Hidden directive should override starting that app. I don't have this problem on 3.5.10.
[35;01mwarning: hp-systray should not be run as root/superuser.[0m [31;01merror: hp-systray cannot be run as root. Exiting.[0m
[01mHP Linux Imaging and Printing System (ver. 2.8.10)[0m [01mSystem Tray Status Service ver. 2.0[0m
Copyright (c) 2001-8 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details.
In addition to the hplip-systray errors, running as non-root produces two additional lines:
[31;01merror: PyQt not installed. GUI not available. Exiting.[0m [35;01mwarning: Qt/PyQt 3 initialization failed.[0m
True, I do not have PyQT compiled or installed.
===========================================================
8. In the shutdown sequence there are messages about creating a link:
Creating link /root/.kde/socket-{hostname}. Created link from "/root/.kde/socket-{hostname}" to "/tmp/ksocket-root"
The messages seem to be generated from kdelibs/kinit/lnusertemp.c. I don't know why those links are created at shutdown. Some people maintain those links in tmpfs and by intent, are lost on power down.
===========================================================
9. Something is creating a .directory file at the top root level of my file system. Yes, this is possible only because I am running the tests as root, but running as root tends to reveal these kinds of quirks. :)
As non-root I saw the following related error message:
cp: cannot create regular file `//.directory': Permission denied
===========================================================
10. Trinity displays desktop folder icons for every directory in the top root level of my files system. I don't know where these icons are from or how to stop them. This probably is something trivial, which epxlains why I don't see the solution. :) However, my original desktop icons no longer are available.
===========================================================
11. Something is overriding my konsole settings. I run konsole with a black background. This changes to white when running Trinity. I have seen this behavior before when testing Debian Lenny. Hence I suspect some kind of Debian remnant in Trinity. This happens with both root and non-root.
===========================================================
12. Please consider changing the default mouse pointer to "No busy cursor." The bouncing cursor is annoying and always has been.
===========================================================
I hope this information helps. I realize I have posted much here and we need to tackle one thing at a time. Please let me know how to help troubleshoot.
<snip>
- As non-root Trinity seems to completely honor $KDEHOME. There is no
~/.kde3 directory created and Trinity uses my existing ~/.kde directory.
As root Trinity does not fully honor $KDEHOME.
<snip> Quick comment here. The above was very important. ;-) Trinity expects to see KDEROOTHOME set, not KDEHOME, when run as root. Maybe you can help here; is this a Debian-only distinction, or do other Linux systems also use KDEROOTHOME?
===========================================================
- The existing startkde is Debianized and causes breakage on Slackware
systems. I am submitting a proposed new startkde script. The proposed script avoids certain presumptions and adds some tests before running various commands. The proposed script also adds additional echo messages to help debugging efforts.
Can you attach it please? I would like to look at it/get it in SVN ASAP as we have already run past the feature freeze and these types of major changes need to be tested thoroughly prior to release.
===========================================================
- As root, the .xsession-error log shows the following errors:
... startkde: Starting KDE. (message is from my proposed startkde script) KDE_FULL_SESSION: true (message is from my proposed startkde script) KDE_SESSION_UID: 0 (message is from my proposed startkde script) kbuildsycoca running... Reusing existing ksycoca Invalid entry (missing '=') at /tmp/kde-root/kconf_updatea8Qi7b.tmp:1 Invalid entry (missing '=') at /tmp/kde-root/kconf_updateBSSSOa.tmp:1 startkde: Looks like kdeinit started. (message is from my proposed startkde script) Warning: connect() failed: : No such file or directory QObject::connect: No such signal Kicker::settingsChanged(SettingsCategory) QObject::connect: (sender name: 'kicker') QObject::connect: (receiver name: 'animtt') kbuildsycoca running... Reusing existing ksycoca ...
As non-root: the .xsession-error log shows the following errors:
QObject::connect: No such signal Kicker::settingsChanged(SettingsCategory) QObject::connect: (sender name: 'kicker') QObject::connect: (receiver name: 'animtt') /usr/bin/xmodmap: unable to open file '/usr/share/apps/kxkb/ubuntu.xmodmap' for reading /usr/bin/xmodmap: 1 error encountered, aborting. /usr/bin/xmodmap: unable to open file '/home/users/tester/.Xmodmap' for reading /usr/bin/xmodmap: 1 error encountered, aborting.
Ubuntu.xmodmap? This is Slackware. :) I can stop those error messages when I disable the related keyboard options in kcontrol. Regardless, I don't use an xmodmap file here. Users should not be bothered with such related messages. The messages might be caused by xmodmap,but I never have seen any such errors before until running Trinity. I have the same X packages installed on my virtual system as my actual system.
I saw these additional error messages as non-root:
WARNING: DCOPReply<QString>: cast to 'TQString' error QObject::connect: No such signal ConnectionManager::statusChanged(NetworkStatus::EnumStatus) QObject::connect: (sender name: 'connection_manager') QObject::connect: (receiver name: 'networkstatusindicator') QObject::connect: No such signal ConnectionManager::statusChanged(NetworkStatus::EnumStatus) QObject::connect: (sender name: 'connection_manager') QObject::connect: (receiver name: 'networkstatusindicator')
So again, seems there is some kind of Debianization here looking for some kind of network manager that does not exist on Slackware.
That looks more like OpenSUSE code IMHO. I'm not going to spend a lot of time tracking them down right now, as they are pretty much harmless and fall into the irritant category.
===========================================================
- Something is trying access samba config files. I have seen such
messages before when testing Debian Lenny. Therefore I suspect some kind of Trinity/Debian hook into a network manager of some sort.
params.c:OpenConfFile() - Unable to open configuration file "/root/.smb/smb.conf.append": No such file or directory Using netbios name {HOSTNAME}. Using workgroup {WORKGROUP}.
That might be Debian, or it might be the Samba kioslave.
===========================================================
- Trinity seems to be ignoring ~/.config/autostart. In that directory I
have a hplip-systray.desktop with the following [Desktop Entry] directive: Hidden=true. That directive should prevent hplip-systray from starting. An hplip-systray.desktop file is found in /etc/xdg/autostart, but the Hidden directive should override starting that app. I don't have this problem on 3.5.10.
This one is more serious and will need to be looked into.
[35;01mwarning: hp-systray should not be run as root/superuser.[0m [31;01merror: hp-systray cannot be run as root. Exiting.[0m
[01mHP Linux Imaging and Printing System (ver. 2.8.10)[0m [01mSystem Tray Status Service ver. 2.0[0m
Copyright (c) 2001-8 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details.
In addition to the hplip-systray errors, running as non-root produces two additional lines:
[31;01merror: PyQt not installed. GUI not available. Exiting.[0m [35;01mwarning: Qt/PyQt 3 initialization failed.[0m
True, I do not have PyQT compiled or installed.
Irritant.
===========================================================
- In the shutdown sequence there are messages about creating a link:
Creating link /root/.kde/socket-{hostname}. Created link from "/root/.kde/socket-{hostname}" to "/tmp/ksocket-root"
The messages seem to be generated from kdelibs/kinit/lnusertemp.c. I don't know why those links are created at shutdown. Some people maintain those links in tmpfs and by intent, are lost on power down.
I'll look into it. Might be a Debian change that needs to be reverted.
===========================================================
- Something is creating a .directory file at the top root level of my
file system. Yes, this is possible only because I am running the tests as root, but running as root tends to reveal these kinds of quirks. :)
As non-root I saw the following related error message:
cp: cannot create regular file `//.directory': Permission denied
Needs to be fixed ASAP.
===========================================================
- Trinity displays desktop folder icons for every directory in the top
root level of my files system. I don't know where these icons are from or how to stop them. This probably is something trivial, which epxlains why I don't see the solution. :) However, my original desktop icons no longer are available.
See my previous message; the fix is in SVN.
===========================================================
- Something is overriding my konsole settings. I run konsole with a
black background. This changes to white when running Trinity. I have seen this behavior before when testing Debian Lenny. Hence I suspect some kind of Debian remnant in Trinity. This happens with both root and non-root.
Weird! Is the black Konsole some kind of system default or did you try to save it that way under your profile?
===========================================================
- Please consider changing the default mouse pointer to "No busy
cursor." The bouncing cursor is annoying and always has been.
Will do.
===========================================================
I hope this information helps.
<snip>
Yes it does. Very few of these issues show up under Debian, so your feedback is essential to getting Trinity working properly.
Tim
On Friday 17 September 2010 00:17:33 Timothy Pearson wrote:
[...]
WARNING: DCOPReply<QString>: cast to 'TQString' error QObject::connect: No such signal ConnectionManager::statusChanged(NetworkStatus::EnumStatus) QObject::connect: (sender name: 'connection_manager') QObject::connect: (receiver name: 'networkstatusindicator') QObject::connect: No such signal ConnectionManager::statusChanged(NetworkStatus::EnumStatus) QObject::connect: (sender name: 'connection_manager') QObject::connect: (receiver name: 'networkstatusindicator')
So again, seems there is some kind of Debianization here looking for some kind of network manager that does not exist on Slackware.
That looks more like OpenSUSE code IMHO. I'm not going to spend a lot of time tracking them down right now, as they are pretty much harmless and fall into the irritant category.
[...]
Actually this it a Qt warning, when an inexistent signal (or wrongly defined) is connected to a slot. I think that the code is unfinished or something like this.
===========================================================
- Please consider changing the default mouse pointer to "No busy
cursor." The bouncing cursor is annoying and always has been.
+ 1
WARNING: DCOPReply<QString>: cast to
'TQString' error
QObject::connect: No such signal
ConnectionManager::statusChanged(NetworkStatus::EnumStatus)
QObject::connect: (sender
name: 'connection_manager')
QObject::connect: (receiver name:
'networkstatusindicator')
QObject::connect: No such signal
ConnectionManager::statusChanged(NetworkStatus::EnumStatus)
QObject::connect: (sender
name: 'connection_manager')
QObject::connect: (receiver name:
'networkstatusindicator')
So again, seems there is some kind of
Debianization here looking for some
kind of network manager that does not exist on
Slackware.
That looks more like OpenSUSE code IMHO. I'm not
going to spend a lot of
time tracking them down right now, as they are pretty
much harmless and
fall into the irritant category.
[...]
Actually this it a Qt warning, when an inexistent signal (or wrongly defined) is connected to a slot. I think that the code is unfinished or something like this.
Yet since most/all of the Trinity code has been modified to use the tqtinterface, why would the messages reference QObject rather than TQObject?
The stock Slackware does not provide any network status indicators. Whereever this code is being generated, a test is needed to verify the expected status tool is actually running.
Regarding the following messages I see when I start Trinity and create a new profile:
params.c:OpenConfFile() - Unable to open configuration file "/root/.smb/smb.conf.append": No such file or directory Using netbios name {HOSTNAME}. Using workgroup {WORKGROUP}.
I have been unable to determine what is accessing samba. Here is the strange part, repeatable in both 3.5.10 and Trinity:
Start KDE or Trinity with no profile. A new profile gets created.
Exit and notice the xsession-errors log contains the samba related messages.
Restart KDE/Trinity.
Disable all KDE daemon startup services. Exit KDE/Trinity.
Restart KDE/Trinity. No samba related messages.
Reenable all KDE daemon startup services.
Exit. Restart. No more samba messages. Cannot reproduce the messages.
I tried running strace startx but the smb.conf related messages do not get captured.
The best I can guess is this is related to some kind of First Login code.
Darrell
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.
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. 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.
I wish I knew C++ better, but here are some observations:
In kdelibs/networkstatus/connectionmanager.cpp, there are ConnectionManager::status and ConnectionManager::updateStatus functions, but no ConnectionManager::statusChanged. There is a ConnectionManager::slotStatusChanged function.
In kdelibs/networkstatus/connectionmanager.h: there is a void statusChanged function and void slotStatusChanged function.
Based upon the first message, I'm guessing there is a missing #include <mediaimpl.h> statement somewhere.
I'm curious why the error messages reference QObject and Qstring rather than TQObject and TQString.
Anyway, I hope that information helps!
Darrell
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
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')
Updated kdelibs and kdebase to svn 1177573. Messages do not appear! :)
Also, I think I have fixed the XDG autostart problem, and
No HPLIP messages appear and no $HOME/hplip directory is created. Good job!
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!
I think we are indeed getting close. :)
I am posting some additional items to the list as I continue testing. None are fatal but I think if corrected add polish and professionalism.
I can hardly believe how much work has been done to get Trinity installable on Slackware. I am grateful to have gotten this far. Thank you!
Yet I still have much to do in that respect: building and testing non-core packages and libraries, testing the build scripts with post 12.2 releases, and most important, actually installing Trinity on my office machine (and not a virtual machine) to begin real-world daily testing. That latter is always a huge step of faith. Gulp!
On Sunday 19 September 2010 19:30:10 Darrell Anderson wrote: [...]
I'm curious why the error messages reference QObject and Qstring rather than TQObject and TQString.
If i'm not wrong these warnings come from moc-generated files, and these files will always refer to original Qt classes.
<snip>
- Trinity seems to be ignoring ~/.config/autostart. In that directory I
have a hplip-systray.desktop with the following [Desktop Entry] directive: Hidden=true. That directive should prevent hplip-systray from starting. An hplip-systray.desktop file is found in /etc/xdg/autostart, but the Hidden directive should override starting that app. I don't have this problem on 3.5.10.
This one is more serious and will need to be looked into.
Can you try modifying the startkde script like so: Replace this portion of text (text after the "&&" remains the same as before) XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:/opt/kde3/etc/xdg:/etc/xdg/ &&
With this: XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:/opt/kde3/etc/xdg:/etc/xdg/:$HOME/.config &&
and see if your problem #7 above is resolved?
Thanks!
Tim
Can you try modifying the startkde script like so: Replace this portion of text (text after the "&&" remains the same as before) XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:/opt/kde3/etc/xdg:/etc/xdg/ &&
With this: XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:/opt/kde3/etc/xdg:/etc/xdg/:$HOME/.config &&
and see if your problem #7 above is resolved?
I added the following temporary changes to startkde to help me verify the changes were effective:
echo "startkde: XDG_CONFIG_DIRS is set to $XDG_CONFIG_DIRS." 1>&2 # Temporary mod for testing: XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:$HOME/.config echo "startkde: XDG_CONFIG_DIRS is set to $XDG_CONFIG_DIRS." 1>&2
I still had messages about starting hplip-systray.
On my actual and virtual systems I have a second KDEDIR directory. For many years I have used this location primarily to patch sloppy *.desktop files that the KDE devs were always too lazy to fix. I also used that second location to solve other KDE issues. Using that second directory allowed me to not worry about changes to various KDE configuration files every time I updated KDE.
Of course, I then set KDEDIRLOCAL and KDEDIRS in my startup scripts.
To eliminate one possible variable in our recent troubleshooting, I unset those two variables in my virtual machine running Trinity. When I did that I saw an error message I have not seen in several years because of my local repairs:
xset: bad font path element (#79), possible causes are: Directory does not exist or has wrong permissions Directory missing fonts.dir Incorrect font server address or syntax
The error message is generated when startkde checks the font directories, specifically the override directories.
For many years this error message puzzled and annoyed many KDE users. Just search the web and see that history.
My location solution is not a global fix. My local solution is to copy some font files to $KDEDIRLOCAL/share/fonts/override and create a respective fonts.dir file.
I would like to see this stupid error message fixed in Trinity --- once and for all. :)
On my actual and virtual systems I have a second KDEDIR directory. For many years I have used this location primarily to patch sloppy *.desktop files that the KDE devs were always too lazy to fix. I also used that second location to solve other KDE issues. Using that second directory allowed me to not worry about changes to various KDE configuration files every time I updated KDE.
Of course, I then set KDEDIRLOCAL and KDEDIRS in my startup scripts.
To eliminate one possible variable in our recent troubleshooting, I unset those two variables in my virtual machine running Trinity. When I did that I saw an error message I have not seen in several years because of my local repairs:
xset: bad font path element (#79), possible causes are: Directory does not exist or has wrong permissions Directory missing fonts.dir Incorrect font server address or syntax
The error message is generated when startkde checks the font directories, specifically the override directories.
For many years this error message puzzled and annoyed many KDE users. Just search the web and see that history.
My location solution is not a global fix. My local solution is to copy some font files to $KDEDIRLOCAL/share/fonts/override and create a respective fonts.dir file.
I would like to see this stupid error message fixed in Trinity --- once and for all. :)
Should now be fixed in revision 1176204.
Tim
xset: bad font path element (#79), possible
causes are:
Directory does not exist or
has wrong permissions
Directory missing fonts.dir Incorrect font server address
or syntax
The error message is generated when startkde checks
the font directories,
specifically the override directories.
For many years this error message puzzled and annoyed
many KDE users. Just
search the web and see that history.
My location solution is not a global fix. My local
solution is to copy
some font files to $KDEDIRLOCAL/share/fonts/override
and create a
respective fonts.dir file.
I would like to see this stupid error message fixed in
Trinity --- once
and for all. :)
Should now be fixed in revision 1176204.
If I unset my KDEDIRLOCAL and KDEDIRS variables before starting X, I still see this error message. :(
<snip>
I am looking into this one, which fortunately I am still able to replicate on the older machine I mentioned earlier. Something is messed up with the XDG desktop paths; on my system "kde-config --userpath desktop" returns "/".
Confirmed here.
On my virtual machine running Trinity I get "/" for both root and normal user.
On my 3.5.10 machine I get the correct location for the Desktop directory for both root and normal user.
That probably confirms why the original desktop icons are missing.
That bug probably exlains why a new .directory files is being created in the root level of the files system when I run as root, and why I receive the error message trying to create that same file when running as normal user.
<snip>
I am looking into this one, which fortunately I am still able to replicate on the older machine I mentioned earlier. Something is messed up with the XDG desktop paths; on my system "kde-config --userpath desktop" returns "/".
Confirmed here.
On my virtual machine running Trinity I get "/" for both root and normal user.
On my 3.5.10 machine I get the correct location for the Desktop directory for both root and normal user.
That probably confirms why the original desktop icons are missing.
That bug probably exlains why a new .directory files is being created in the root level of the files system when I run as root, and why I receive the error message trying to create that same file when running as normal user.
OK, try kdelibs and kdebase with SVN revision 1176194 or later. Most of the issues you posted earlier should be resolved, with the exception of the Qt connection error messages. I have also incorporated the majority of your startkde script changes as they should not interfere with Debian and add significant functionality.
Thanks!
Tim
-
Darrell Anderson -
Serghei Amelian -
Timothy Pearson