tde-devels August 2012

devels@trinitydesktop.org

19 participants
88 discussions

by Sanne

Hi all, I was listening in on the last irc meeting and caught an aftermeeting mentioning about bad Qt4 performance. I offered an article and a possible workaround I found recently, in case people are not aware of it, and was asked to bring it to attention to other developers also, so here goes: I'm suffering bad graphical performance in Qt4 and PyQt4 applications and searched for solutions. I found a post on nokia.com [1] that mentions a command line switch that might help. In short: adding "-graphicssystem raster" to my Qt4 applications' command line improved performance drastically for me. There's also a method to set it programmatically, and an environment variable [2]. [1] http://labs.qt.nokia.com/2008/10/22/so-long-and-thanks-for-the-blit/ [2] http://doc.qt.nokia.com/4.7/qapplication.html#setGraphicsSystem Thanks and much regards, Sanne

11 years, 10 months

New backend for the media:/ kioslave

by Timothy Pearson

All, I recently pushed a new (alpha quality) backend for the media:/ kioslave which uses udev/pmount and therefore does not rely on HAL. I encourage developers here to try it out! Please report failures to this list, not to the bugtracker, as it has not been tested much beyond mounting simple flash drives. Encryption support is buggy, but repairing it is my next task. Rhis will NOT be made default for R14.0 due to the vast array of hardware that it still needs to be tested on, but if your distribution no longer works with HAL it may be better than nothing even in this alpha form. To enable it, pass the -DWITH_TDEHWLIB="on" option to tdebase CMake. Enjoy! Tim

12 years

Why not standardize kde_htmldir='\${datadir}/doc/HTML' ??

by David C. Rankin

Tim, Darrell, All, In the process of attempting to get the khelpcenter documents all collected in one spot in 3513-sru, I have found a simple setting that will allow both R14 and 3513-sru to standardize their document locations. The primary issue is that the base document path is hardcoded in tdelibs/kdecore/kstandarddirs.cpp on lines 1041-1042: 1041 if (!strcmp(type, "html")) 1042 return "share/doc/kde/HTML/"; All autotools build packages, on the other hand, set the equivalent path to: return "share/doc/HTML/"; During April (10 & 11), Darrell fixed the R14 document locations. At that time there was no focus on 3513-sru as a branch. Instead of changing the hardcoded location in tdelibs to remove ../kde/.. to match all autotools package locations and changing the CMake files as originally envisioned, hundreds of individual patches were submitted to change all autotools acinclude.m4 files to move helpcenter docs from: kde_htmldir='\${datadir}/doc/HTML' to kde_htmldir='\${datadir}/doc/tde/HTML' That works fine for R14, but interjects incompatibility between R14 and 3513 essentially requiring 2-sets of hundreds of patches just to change the kde_htmldir to '\${datadir}/doc/tde/HTML' (in the case of R14) and to '\${datadir}/doc/kde/HTML' (for 3513). Why not fix this once and for all, fix tdelibs, and just set: kde_htmldir='\${datadir}/doc/HTML' for all?? That way, instead of patching hundreds of autotools packages, the original location in tdelibs is standardized where it should be in 'kstandarddirs.cpp', the CMake files are corrected to match the original kde_htmldir locations in their sources, and all future CMake migration can go forward without every set of files having to set kde_htmldir and reset it for 3513 in another set of patches... (this stuff should be standard anyway -- there is absolutely no need to have 'kde' or 'tde' in the middle of kde_htmldir) This would eliminate hundreds of patches required to change to 'tde' for R14 and to 'kde' for 3513 and move all sources back closer to their pristine state. This couldn't have been envisioned in April, but if we are serious about providing a 3513-sru branch and R14, then I think this is the right way to do it. See: http://www.trinitydesktop.org/patches/ The set of commits at issue are between the following: 398ef116 2012-04-10 4e430ec6 2012-04-11 Thoughts? -- David C. Rankin, J.D.,P.E.

12 years, 2 months

kpdf/xpdf

by Darrell Anderson

If I understand correctly, kpdf uses xpdf as a base rendering engine. The xpdf code in the Trinity source tree uses 3.02 from February 2007, which has been patched for security reasons several times since then. There also is a patch to improve a scrolling speed bug that is caused by more recent gcc versions. The most recent version of xpdf is 3.03. Many distros have these patches applied or use 3.03. * Does compiling kpdf use an existing installed xpdf from the distro or does the build process only use the xpdf code that is in the kpdf source tree? * If the latter, then should we be patching the Trinity version of xpdf? Or updating to the latest release of xpdf? * If the latter, what is needed to change the build process to use an existing installed xpdf rather than the stale version in the Trinity sources? Darrell

12 years, 2 months

R14.0.0 Branding issues

by Darrell Anderson

Considering the original volume of changes needed, we're about as okay as we can expect, but --- we still find branding issues. For example, today I found some more and I am pushing patches. To resolve remaining branding issues we need the following: * Some really smart person to grep the system properly looking for corrupt image files (png, xcf, jpg/jpeg, whatever else might be out there). We can't inspect those images for branding issues. For whatever reason, seems many of the images got corrupted with CR/LF issues. We have found most of the corrupt files (walch.martin found most of them --- I only pushed clean files), but I don't know of a good way to search the sources for corrupt image files. (Note: Corrupt image files do not block building packages, but they cause usability issues that reflect badly on us). * Some really smart person to grep the system looking for text strings containing KDE. I haven't figured out a slick way to search the sources for these branding issues. Again, I think we have found most but we continually find more, albeit a smaller number of these strings appear each time. The challenge is we *cannot* do a blind global search-and-replace. We are at the point where we have to review each potential suspect string in context to ensure we are updating human-viewable text strings and not code strings. * Some really smart person to figure out how the fifteenpieces applet About dialog is sucking in a KDE3 branded image (bug report 1052). I don't know whether the problem is limited to fifteenpieces or whether the image being used is a global default About image. One way or another we need to find that image and update. * Internationalization (tde-i18n) files are beyond me. I nonetheless have patched many of these files. Most of the changes have been in the nature of KDE->TDE, but I suspect that in those patches occasionally I presumed incorrectly and changed something that changed contextual meaning. I don't know how we are going to resolve the differences between the tde-18n files and the parent files in the main source tree (po files, *.desktop files, *.docbook files, etc.) Darrell

12 years, 2 months

Accelerator hiding option?

by Darrell Anderson

What are these latest accelerator hiding options? Darrell

12 years, 2 months

build kdebase 3.5.12 - configure: error: libhpi.so not found

by David C. Rankin

All, I was trying to do a quick backport of the sftp kio fix to TDE 3.5.12, however, it looks like libhpi.so from jre has changed names or disappeared altogether. (It's not in jre or jdk 7.4) Does anyone know if this file has been dropped from jre? Is there a patch that will fix configure? -- David C. Rankin, J.D.,P.E.

12 years, 2 months

3.5.13-sru Test [print] -> ksnapshot gesture (didn't work on last build)

by David C. Rankin

Slavek, All, On my last 3.5.13-sru build, the input gesture pressing print-screen for ksnapshot stopped working similar to what happened with R14. Please test the latest 3.5.13-sru build and see if it still works for you. The entire issue might be a simple 'k' 't' rename issue and 3.5.13-sru may have pulled in that commit. I'll have more time this weekend to dig into it, but having confirmation on if other see it as well will help :) -- David C. Rankin, J.D.,P.E.

12 years, 2 months

Tim: TDEHWLIB

by Darrell Anderson

Tim, 1. Does TDEHWLIB require pmount? Although available as a third-party package --- something similar to PPAs --- pmount is not a stock package in Slackware. Slackware 14.0 no longer supports HAL but supports udisks, udisks2, and upower. 2. If -DWITH_HAL=ON and -DWITH_TDEHWLIB=ON, does TDEHWLIB override during run-time? If yes, can TDEHWLIB be disabled at run-time, or only during compiling? Darrell

12 years, 2 months

KMix broken?

by Darrell Anderson

Today I tried to adjust the volume in kmix. I am unable to open the kmix mixer window. I deleted the kmix rc files and started kmix. The window opens empty, only a window frame. This is a recent GIT build, short version 7877. Not the most recent but recent. Would somebody please confirm? Darrell

12 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels August 2012