tde-devels December 2011

devels@trinitydesktop.org

32 participants
74 discussions

ideas for new power management system
by Serghei Amelian 08 Dec '11

08 Dec '11

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

4 3

Building tde 3.5.13
by Baho Utot 08 Dec '11

08 Dec '11

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

3 2

tdelibs compilation stuck on KBetterThanKDialogBase
by Aleksey Midenkov 08 Dec '11

08 Dec '11

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.

1 0

Running Trinity, KDE 4, and KDE 3 Concurrently
by Darrell Anderson 07 Dec '11

07 Dec '11

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

5 22

kdevelop-3.5.13 build error
by Baho Utot 07 Dec '11

07 Dec '11

[ 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().

2 1

Kaffeine DVB OSD Colors
by Darrell Anderson 07 Dec '11

07 Dec '11

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

3 14

Different packages with same version: libeggdbus-1-0_0.6-1_i386
by Mike Bird 04 Dec '11

04 Dec '11

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.

1 0

"Keep password" check box restored to kdesu dialog box
by Darrell Anderson 04 Dec '11

04 Dec '11

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

5 12

Open in Background Tab
by Darrell Anderson 04 Dec '11

04 Dec '11

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. :)

2 1

Converting KDE3 Code to TDE
by Darrell Anderson 03 Dec '11

03 Dec '11

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

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels December 2011