Hello,
I need some opinions about features provided by Power Management System.
So far I implemented a battery monitor and backlight control. Now, I want to
debate about:
1) Governors. KPowersave come with governor controller, but a guy from #udev
irc channel adviced me that is actually is not necessary to implement it in a
gui interface, because actually we don't want to change governors but we need
to burn less energy.
Check this "good practices" guide:
http://www.codon.org.uk/~mjg59/power/good_practices.html
2) DPMS and screensavers. In my opinion, DPMS control should be passed to
screensaver, not to be controlled by power manager.
Why? I think that Power Manager should react only to events related to power
supplies (like AC adapter plugged in, AC unplugged, battery low, etc) or ACPI
events like "lid closed", "power button pressed", etc.
Shutting down the monitor when the user is away from keyboard is not exactly
related to power management, seem natural to be a part of screensaver.
Opinions? Ideas?
--
Serghei
I am having mucho trouble compiling TDE-3.5.13 non cmake packages
I am getting things like the following (from kdemultimedia for example)
I think I have a path incorrect or something so....
How do you "lookup" where these references are found (like which library file
etc) ?
.libs/kmixapplet.o: In function `KMixApplet::reportBug()':
kmixapplet.cpp:(.text+0x21c): undefined reference to `QDialog::exec()'
.libs/kmixapplet.o: In function `KMixApplet::resizeEvent(QResizeEvent*)':
kmixapplet.cpp:(.text+0x312): undefined reference to
`QWidget::updateGeometry()'
.libs/kmixapplet.o: In function `KMixApplet::staticMetaObject()':
kmixapplet.cpp:(.text+0x465): undefined reference to
`QMetaObject::new_metaobject(char const*, QMetaObject*, QMetaData const*,
int, QMetaData const*, int, QMetaProperty const*, int, QMetaEnum const*, int,
QClassInfo const*, int)'
kmixapplet.cpp:(.text+0x479): undefined reference to
`QMetaObjectCleanUp::setMetaObject(QMetaObject*&)'
.libs/kmixapplet.o: In function `AppletConfigDialog::staticMetaObject()':
kmixapplet.cpp:(.text+0x527): undefined reference to
`QMetaObject::new_metaobject(char const*, QMetaObject*, QMetaData const*,
int, QMetaData const*, int, QMetaProperty const*, int, QMetaEnum const*, int,
QClassInfo const*, int)'
kmixapplet.cpp:(.text+0x53b): undefined reference to
`QMetaObjectCleanUp::setMetaObject(QMetaObject*&)'
.libs/kmixapplet.o: In function `KMixApplet::about()':
kmixapplet.cpp:(.text+0x647): undefined reference to `QDialog::exec()'
.libs/kmixapplet.o: In function `AppletConfigDialog::activeColors(QColor&,
QColor&, QColor&) const':
kmixapplet.cpp:(.text+0x81b): undefined reference to `QColor::QColor(QColor
const&)'
kmixapplet.cpp:(.text+0x82f): undefined reference to `QColor::operator=(QColor
const&)'
kmixapplet.cpp:(.text+0x84c): undefined reference to `QColor::QColor(QColor
const&)'
kmixapplet.cpp:(.text+0x85c): undefined reference to `QColor::operator=(QColor
const&)'
kmixapplet.cpp:(.text+0x87a): undefined reference to `QColor::QColor(QColor
const&)'
kmixapplet.cpp:(.text+0x88a): undefined reference to `QColor::operator=(QColor
const&)'
.libs/kmixapplet.o: In function `AppletConfigDialog::mutedColors(QColor&,
QColor&, QColor&) const':
kmixapplet.cpp:(.text+0x95b): undefined reference to `QColor::QColor(QColor
const&)'
kmixapplet.cpp:(.text+0x96f): undefined reference to `QColor::operator=(QColor
const&)'
kmixapplet.cpp:(.text+0x98c): undefined reference to `QColor::QColor(QColor
const&)'
kmixapplet.cpp:(.text+0x99c): undefined reference to `QColor::operator=(QColor
const&)'
kmixapplet.cpp:(.text+0x9bd): undefined reference to `QColor::QColor(QColor
const&)'
kmixapplet.cpp:(.text+0x9cd): undefined reference to `QColor::operator=(QColor
const&)'
.libs/kmixapplet.o: In function
`AppletConfigDialog::AppletConfigDialog(QWidget*, char const*)':
kmixapplet.cpp:(.text+0xa9f): undefined reference to `QString::shared_null'
kmixapplet.cpp:(.text+0xb23): undefined reference to `QString::shared_null'
kmixapplet.cpp:(.text+0xb2f): undefined reference to
`QStringData::deleteSelf()'
kmixapplet.cpp:(.text+0xb74): undefined reference to `i18n(char const*)'
Thanks
Hello!
I have trouble compiling tdelibs:
[ 42%] Building CXX object
kio/misc/kwalletd/CMakeFiles/kded_kwalletd-module.dir/kwalletd.cpp.o
/home/midenok/src/kde/tdelibs/kio/misc/kwalletd/kwalletd.cpp: In member
function ‘bool KWalletD::isAuthorizedApp(const QCString&, const QString&,
WId)’:
/home/midenok/src/kde/tdelibs/kio/misc/kwalletd/kwalletd.cpp:556:12: error:
‘class KBetterThanKDialogBase’ has no member named ‘setLabel’
/home/midenok/src/kde/tdelibs/kio/misc/kwalletd/kwalletd.cpp:558:12: error:
‘class KBetterThanKDialogBase’ has no member named ‘setLabel’
I looked at KBetterThanKDialogBase. It is descendant of QDialog. And there
is no method setLabel().
Tried to compile from master branch and from tag v3.5.13 -- same result.
I compile with tqtinterface and qt3 modules from git.
Just my observations with Slackware 13.1. YMMV. Please feel free to add, edit, qualify, add a workaround, etc.
Should we fine tune this information and post to our wiki?
===================================
Whereas the Trinity developers have worked hard to support KDE 4 compatibility, there are several challenges with running Trinity, KDE 4, and KDE 3 installed on the same multiple user system.
1. Many of the apps use the same file name. The scripts in /etc/profile.d produce conflicting file search paths. Without the appropriate file search path, the file search path highest in the path hierarchy will launch the app, which might not be the correct app.
2. On multiple user systems, the profile.d scripts can’t be arbitrarily disabled because any of the desktop environments might be used.
3. The profile.d scripts cause conflicts with XDG paths, which create the desktop menus. Normally this is not a problem with other desktops such as Xfce, but that is not the case with these three desktops because many apps have the same name. With each profile.d script being sourced, each desktop system menu will show every app from all other desktops. The Trinity developers have hacked a neat trick to tag the KDE 4 apps in the menu, but there is no such support for KDE 3 apps. The hack does not exist for KDE 4 or KDE 3.
4. User-defined menu changes are stored in $HOME/.config/menus and $HOME/.local/applications. As those directories are global to anything the user does, menu changes in one desktop affects the other desktops if a user wants to change desktops. That means conflicts with starting apps.
5. The KDE 3 and Trinity KDM login manager will conflict unless one or the other is disabled (chmod -x). Neither can be used to support the other desktops because of the underlying dependency on each desktop’s respective kdelibs package.
6. The file search path conflicts will introduce multiple autostart directories. Apps in those directories will start for the other desktops too.
A possible work-around to most of these conflicts is to disable all affected profile.d scripts and then modify the xinitrc scripts to source the appropriate profile.d scripts. That might suffice for run level 3, but not run level 4. Run level 4 would require some detailed scripting in the KDM Xsession script to look at the user’s dmrc config file and then source the appropriate profile.d scripts. Yet these work-around won’t resolve any user-defined menu changes.
On single user systems or systems where all users want to use the same desktop, all of this can be avoided by uninstalling the other desktop environments.
===================================
Darrell
[ 91%] Building CXX object
kdevdesigner/designer/CMakeFiles/libkdevdesignerpart-module.dir/listeditor.cpp.o
In file included
from /build/src/BUILD/kdevdesigner/designer/listeditor.cpp:22:0:
/build/src/BUILD/kdevdesigner/designer/listeditor.ui.h: In member
function 'virtual void ListEditor::addItem()':
/build/src/BUILD/kdevdesigner/designer/listeditor.ui.h:33:5: error: 'App' was
not declared in this scope
make[2]: ***
[kdevdesigner/designer/CMakeFiles/libkdevdesignerpart-module.dir/listeditor.cpp.o]
Error 1
make[1]: ***
[kdevdesigner/designer/CMakeFiles/libkdevdesignerpart-module.dir/all] Error 2
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
I was looking at bug report 343 and decided to test Kaffeine 3.5.13 to see whether I could duplicate the DVB problem with Slackware 13.1.
Seems DVB works fine with 13.1. So I might recommend closing the bug.
Yet one thing I notice with TDE is the DVB OSD is different.
In KDE3 with Kaffeine 0.8.8, I have an OSD that is grayish in color, with cyan text, and a magenta rule line. Easy on my eyes.
In TDE I have an OSD that is flourescent green, with reddish text and a yellow/gold rule line. I have been trying to compare the sources, but I can't find anything that explains the color changes.
I am running KDE3 and TDE on the same machine, same video card, same Kaffeine config files, etc.
I find the flourescent green hard on my eyes and prefer the old colors. Does anybody know when the color changes occured and which sources need to be patched?
Or is this a bug?
As far as I know, Kaffeine 3.5.13 is fundamentally Kaffeine 0.8.8. Other than the TQT layer, I don't see anything in the patches lists identifying other changes.
Thanks.
Darrell
This was causing some apt-get weirdness in Debian Squeeze with TDE 3.5.13.
I don't think it's a good idea to have two packages with the same version
but different dependencies and different content.
There may be others. It took me a while to track this one down. I think
libxxf86misc1 is also a likely candidate.
I'm probably going to have to figure out a way of purging trinity builddeps
from our systems.
--Mike
.../trinity-builddeps-v3.5.13/pool/main/e/eggdbus/libeggdbus-1-0_0.6-1_i386.deb
new debian package, version 2.0.
size 92028 bytes: control archive= 3103 bytes.
548 bytes, 13 lines control
432 bytes, 6 lines md5sums
135 bytes, 7 lines * postinst #!/bin/sh
132 bytes, 7 lines * postrm #!/bin/sh
30 bytes, 1 lines shlibs
17801 bytes, 403 lines symbols
Package: libeggdbus-1-0
Source: eggdbus
Version: 0.6-1
Architecture: i386
Maintainer: Utopia Maintenance Team
<pkg-utopia-maintainers(a)lists.alioth.debian.org>
Installed-Size: 312
Depends: libc6 (>= 2.7-1), libdbus-1-3 (>= 1.0.2), libdbus-glib-1-2 (>=
0.71), libglib2.0-0 (>= 2.23.5)
Section: libs
Priority: optional
Homepage: http://cgit.freedesktop.org/~david/eggdbus
Description: D-Bus bindings for GObject
EggDBus is a D-Bus binding for GObject. It uses an "IDL language" (XML) to
describe the D-Bus interfaces and generates C code from that.
.../debian/pool/main/e/eggdbus/libeggdbus-1-0_0.6-1_i386.deb
new debian package, version 2.0.
size 91502 bytes: control archive= 3119 bytes.
551 bytes, 13 lines control
432 bytes, 6 lines md5sums
135 bytes, 7 lines * postinst #!/bin/sh
132 bytes, 7 lines * postrm #!/bin/sh
30 bytes, 1 lines shlibs
17801 bytes, 403 lines symbols
Package: libeggdbus-1-0
Source: eggdbus
Version: 0.6-1
Architecture: i386
Maintainer: Utopia Maintenance Team
<pkg-utopia-maintainers(a)lists.alioth.debian.org>
Installed-Size: 332
Depends: libc6 (>= 2.3.6-6~), libdbus-1-3 (>= 1.0.2), libdbus-glib-1-2 (>=
0.78), libglib2.0-0 (>= 2.19.0)
Section: libs
Priority: optional
Homepage: http://cgit.freedesktop.org/~david/eggdbus
Description: D-Bus bindings for GObject
EggDBus is a D-Bus binding for GObject. It uses an "IDL language" (XML) to
describe the D-Bus interfaces and generates C code from that.
I submitted a patch to bug report 388 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=388). The patch restores the visibility of the kdesu "Keep password" check box. In TDE, the check box is hard-coded invisible rather than being a function of the kdesu -t parameter as in 3.5.10.
The patch (kdebase/kdesu/kdesu/kdesu.cpp):
================================================
// Try to exec the command with kdesud.
bool keep = !args->isSet("n") && have_daemon;
- bool terminal = true;
+ bool terminal = args->isSet("t");
bool new_dcop = args->isSet("newdcop");
bool withIgnoreButton = args->isSet("ignorebutton");
================================================
Although I suspect many will welcome the patch, there likely will be just as many who will fear being eaten in the dark by grues if this check box is visible.
I dislike the idea of those who want this check box visible to have to always patch the TDE sources in their build scripts.
Is there a way to test who wants this check box visible and those who don't so no build-time patching is required and everybody is happy?
I think the 'buntu family of distros don't use kdesu and instead use kdesudo. Perhaps this patch does not affect those distros. If that is the case then the discussion falls on everybody else.
Ideas?
Darrell
I'm in shock folks. Really. Yet I'm smiling from ear to ear and giggling like a little kid.
Last week when I was looking in the old KDE SVN for the original patches to Kate --- to restore the ability to specify the number of files to list in the Most Recently Used (MRU) list, I decided to look for the patches that ripped the Konqueror web link context menu.
Long, long ago, in KDE 3.1.3, the web link context menu contained two options: Open in Background Tab and Open in New Tab. The latter option opened links in Tabs in the foreground. Like this:
Open in Background Tab
Open in New Tab
In 3.1.4 the former menu option was ripped from the context menu, much to the dislike of many people. The same function could be achieved by using the Shift key to toggle the function of the Konqueror setting, but that idea never sat well with me. Or others.
Some time back I filed an enhancement request to restore that feature in bug report 245 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=245).
I use that double option all the time in the Firefox context menu, enabled through the TabMix Plus plugin (other plugins provide that feature too). I can't predict when I want a link to open in the foreground or background. That decision depends upon what I am reading. I was using that type of double menu option in Opera (version 5? 6?) before Firefox was born as Phoenix. Opera still supports both menu options as do other web browsers.
Yeah, I'm quite accustomed to those two menu options. Both make sense to me. Pressing the Shift key does not.
I found the original Konqueror patches that removed those options. That developer steadfastly refused to restore the options despite many complaints. Classic KDE developer egotism. At least that developer did not name the patch "useless crap."
Much like my Kate effort last week, with a little trial and effort I succeeded in restoring the old context menu. And the two options just plain work as intended.
Two for two. Not quite the same as hitting two home runs in a single baseball game, but I'm feeling mighty doggone good right now. :)
Woo-hoo!
Darrell
P.S.
I suspect there might be some people who do not want this patch and prefer the current behavior. I've uploaded the patch in the bug report. I hope an overwhelming number of people rejoice and the patch gets merged into R14. :)
I would be grateful if somebody would share any scripts to convert KDE3 code to TDE. Basically something that quickly adds the tqt layer.
Thanks.
Darrell
