tde-devels

devels@trinitydesktop.org

2 participants
3811 discussions

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 08 Dec '13

08 Dec '13

>Just as a word of warning, this would push R14 to January 2014 at >the earliest due to the time required to rebuild the entire package >set for Debian/Ubuntu. I had already filed bug report 1759: http://bugs.trinitydesktop.org/show_bug.cgi?id=1759 cmake_policy(SET CMP0022 OLD) seems like a temporary work-around --- cmake 2.8.12 is here to stay and we might as well adapt sooner rather than later. :-) I just love how upstream changes keep breaking things for everybody downstream.... C'est la vie. Darrell

4 3

Re: [trinity-devel] tqt FTBFS: something about TQAssistantClient
by Darrell Anderson 07 Dec '13

07 Dec '13

>tqt FTBFS with next message: > >x86_64-pc-linux-gnu-g++ -luuid -fno-exceptions -Wl,-O1 -Wl,--as- >needed -o >../../../bin/tqdesigner .obj/release-shared-mt/main.o -L/usr/lib64 >-L/var/tmp/portage/dev-qt/tqt-3.9999/work/tqt-3.9999/lib - >L/usr/X11R6/lib64 >-L/var/tmp/portage/dev-qt/tqt-3.9999/work/tqt-3.9999/lib - >L/usr/lib64 >-ltqtdesignercore -ltqui -ltqassistantclient -luuid -ltqt-mt -lmng >-ljpeg >-lpng -lz -lXi -lXrender -lXrandr -lXcursor -lXinerama -lXft - >lfreetype >-lfontconfig -lXext -lX11 -lm -lSM -lICE -ldl -lpthread >/var/tmp/portage/dev-qt/tqt-3.9999/work/tqt- >3.9999/lib/libtqtdesignercore.a(mainwindow.o): >In function `MainWindow::MainWindow(bool, bool, TQString const&)': >mainwindow.cpp:(.text+0x15bd5): undefined reference to >`TQAssistantClient::TQAssistantClient(TQString const&, TQObject*, >char >const*)' > > >Full Build log is in the attach. There was a bug report the past couple of days and related patch committed. Probably need to update your local source tree? Darrell

2 1

Amarok (x86) fails scanning files whose inode value exceeds "uint32 max value" (XFS/inode64)
by Nicolas Bercher 06 Dec '13

06 Dec '13

Hi, I just submitted a bug report regarding this issue: http://bugs.pearsoncomputing.net/show_bug.cgi?id=1758 Any clue on this? I'm not yet involved in TDE development, but I'd be willing to try to fix this if some people could give me few advices and directions. And basically, I don't want to dig in it if it's a well known fact that such inode64 issues on x86 platforms are not not fixable (in the context of TDE code only). I think I have to start analyzing the scanning code of course and check C types used to handle inode values, if such things occur within Amarok code. Another option might be that the bug lives in an external library that open the files for Amarok. (People might ask me "Why I don't you swich to amd64 distro?" But that is not the question here.) Nicolas

1 0

Re: [trinity-devel] Trinity on older hardware
by Darrell Anderson 05 Dec '13

05 Dec '13

>as further thing to consider, have 3.5.10 and R14 been compiled in >the same configuration (either release-release or debug-debug)? On >some intensive programs I noticed a speed difference ratio or 3-to- >1 between the two. 3-to-1 ratio --- which one was faster? Speaking of debugging, does including the debugging symbols affect run-time operation? I would not think so but on old hardware might that be true? I wonder because now in hindsight I remember I never built or installed the debugging symbols for the 3.5.10 or TDE 3.5.x packages. (I'm still not letting newer versions of X and the kernel off the hook. Just wondering out loud.) Darrell

3 2

Re: [trinity-devel] Trinity on older hardware
by Darrell Anderson 05 Dec '13

05 Dec '13

>Well, you are very much correct on the watts/performance issue, I >look at >it this way. Your average PII/PIII is about as powerful as some >of the >ultra-efficient Arm-based SBC devices now available for Linux >users. If >TDE can run well on PII/PIII hardware, then it will likely run >well on >those very efficient Arm-based systems as well. I don't run the PI and PII all day. I use them because they provide a nice way for corner case testing. For example, a while back I noted problems with the logout status dialog because only the PI or PII would show them. Darrell

1 0

Re: [trinity-devel] Trinity on older hardware
by Darrell Anderson 05 Dec '13

05 Dec '13

>> That said what kinds of system or usability tests would be >> representative? >You bring up a long-standing problem here. :-) Without an >automated >performance test suite, all we can go in is the system "feel" and >"snappiness" when trying to use it. > >I would still like to put together a test suite (ideally generic >enough >that we can also benchmark Qt4/Qt5 for comparison purposes), but >don't >have time at the moment with trying to get R14 out the door and >all. Sounds like a great post-R14 project. Until then I'll have to settle for a stopwatch and the time command. :-) Darrell

2 1

Trinity on older hardware
by Darrell Anderson 05 Dec '13

05 Dec '13

All, Do you have experience with running Trinity on older hardware? I have a PI and a PII. For years I ran KDE 3.5.10 on both. While hardly the fastest hardware, and 3.5.10 hardly the snappiest desktop environment, the system was usable. Trinity R14 on both systems is almost unusable. Starting Trinity takes a minute or two. Opening konsole takes 7-10 seconds. Opening a preloaded konqueror takes 20-25 seconds. I realize free/libre software never truly supported older hardware despite claims otherwise and developers instead move relentlessly onward with bleeding edge hardware. Still, because of the many improvements I would think Trinity R14 would fare better, at least as good as 3.5.10. Any ideas? Any help? Darrell

4 4

Re: [trinity-devel] Trinity on older hardware
by Darrell Anderson 04 Dec '13

04 Dec '13

>Please note that this might not be all TDE's fault. I have >noticed that >the X server (and possibly the kernel itself) tends to get slower >and >slower from release to release on old hardware. In general, >locking >myself to an old version of the kernel and Xorg on old hardware, >then >compiling new software on top of those old versions, seems to give >halfway >decent results. I agree the problem is not TDE per se. I too seem to believe that Linux based systems get slower with each new release. >However, if you are noticing that TDE is running slower than KDE >3.5.10 on >the same X/kernel versions, then we have a problem. ;-) I haven't tried such a test on my older systems. On newer Linux systems, compiling 3.5.10 now is all but impossible with all of the various upstream software changes that require patching. I experienced that compiling R14 on older Linux systems is impossible without modifying or updating several distro packages. That limits any 3.5.10->R14 comparison to a specific period of Linux OSs. Fortunately, I have a candidate here (I can compile 3.5.10 and R14 on Slackware 13.1) and will give this a test a go. That said what kinds of system or usability tests would be representative? Darrell

2 1

Re: [trinity-devel] Desktop environment agnostic notification popups
by Darrell Anderson 04 Dec '13

04 Dec '13

>Notify-send seems to be the most generic of them all, but does >depend >on dbus. Most applets I've seen (mostly gtk applets though), do >use >notify send for their notifications. Can we hack kdbusnotification, knotify, or notify-send to work correctly? >You could also use a basic scriptable widget like xdialog which is >like cdialog or just dialog I want a system tray popup. (Nikolaus) Likewise for xmessage or xosd. :-) I already can create message windows with kdialog, KDED kwrited, or dcop. But such a script is then not desktop-agnostic. I don't want to waste time with a bunch of if-then tests. :-) I want a message that does not timeout, which is broken in notify- send when used in non-GTK environments. (Or possibly is broken only in Qt/TQt environments because the -t0 option does not work in KDE either.) Besides the broken -t0 option in non-GTK environments, the notification popup does not use knotify or kdbusnotification. Seems like notify-send is an obvious option, but not integrated into TDE at all. Either notify-send or knotify/kdbusnotification need patching. If notify-send supports/requires dbus, then patching kdbusnotifcation would be the most straightforward option? Ideas? Darrell

1 0

Desktop environment agnostic notification popups
by Darrell Anderson 04 Dec '13

04 Dec '13

All, Are there any notification popup tools to use with Trinity? Especially to run in scripts. kdialog is TDE-specific, as is dcop. There is rwall and KDED kwrited, but that is not a small system tray popup. libnotify provides notify-send, but notify-send is GNOME-centric. For example, the infinite timeout option, -t0, does not work with either TDE or KDE4 (works fine in Xfce). There is dbus, but that requires installing an optional Trinity package, kdbusnotification. Ideas? Recommendations? Darrell

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels