tde-devels January 2013

devels@trinitydesktop.org

10 participants
18 discussions

Re: Re: [trinity-devel] Standalone build of KWin
by Darrell Anderson 20 Jan '13

20 Jan '13

>I recently took some time to evaluate kwin on a TDE system. The >kwin developers have done excellent work; kwin itself operates well and >the configuration dialogs are relatively sane compared to most modern >offerings. At this point I agree with Martin that TDE should be >looking at using kwin as a default instead of our old twin fork as soon as >possible. > >I have put together an Etherpad >(http://trinity.etherpad.trinitydesktop.org/61) detailing the >changes that need to occur before this can be done. Both TDE and kwin will >need some modification to ensure that TDE doesn't lose features after the >migration is complete. Based on the etherpad notes, this sounds like a post R14 goal. As twin->kwin is a significant transition, I'm guessing R15? Darrell

2 1

Standalone build of KWin
by Martin Gräßlin 19 Jan '13

19 Jan '13

Hi Trinity developers, finally I can announce the availability of a patch [1] to build KWin standalone. That is without building other parts of kde-workspace. The patch is on top of KDE/4.10 branch [2] as of Friday and available in git branch "kwin/standalone" of my kde-workspace clone [3]. I hope this patch can help you to provide a tailored version of KWin. Most of the functionality which is required for this is already part of KWin master and also used in some KDE projects. E.g. for Plasma Active we use an adjusted KWin version without window decorations, without KCMs, with a different binary name and different configuration files. To make it easier to build KWin for new developers we introduced a build option to disable the Oxygen window decoration which required to build most parts of kde-workspace. All available build options are documented in [4]. *Build Options* For the usage in your project I would suggest the following build options: * adjust the "KWIN_NAME" variable in CMakeLists.txt * disable KWIN_BUILD_OXYGEN * disable KWIN_BUILD_KCMS * disable KWIN_BUILD_KAPPMENU * disable KWIN_BUILD_ACTIVITIES The steps on how to build KWin are probably well known given that it is a cmake project. If not there is a beginners guide available in [5]. The patch does not reduce the dependency on kdelibs and kde-runtime. We still have a dependency on kdelibs and that cannot change in the lifetime of KWin on Qt 4 due to part of KWin being implemented in kdelibs. *Styling* Also KWin has a pretty standard Plasma look'n'feel. But this can be easily changed: * window decorations can be written in QML since 4.10 - with disabled Oxygen the default decoration is in fact on QML. Documentation for this is still missing, but is on my TODO list ;-) * Alt+Tab window switchers can be written in QML. Documentation for this is available in [6] and this feature is e.g. used by Plasma Active to have a customized switcher * QML scripts can be loaded - e.g. our "Desktop Change OSD" is written in QML. It would be easy to replace it with one that does not use Plasma Components. Documentation is available in [7] for the general JavaScript API. *What are the next steps?* Development focus is currently on porting KWin to Qt5. Given the strong usage of XLib this is more work than for most projects. But I hope that this will soon be finished. With Qt5 and KDE Frameworks 5 the dependencies will go down to what is really needed and quite some for KWin important functionality from kdelibs has been upstreamed into Qt. Other plans are to use KConfigXT for the complete configuration of KWin. This is already used (since 4.10) for KWin effects and would allow to easily integrate our configuration interfaces in your available configuration module. With KConfigXT the configuration modules basically consist of .ui files and an xml description of the config values. (Note: the KCMs belonging to KWin do not support a changed binary name.) Apart from that I want to have everything which is UI to be done in QML. *Final Remarks* This patch is a personal service provided by me and is not officially supported by KDE. I will not update the patch on a regular basis, though I intend to update it for each release cycle once a new version has been branched. This also means that I cannot guarantee that everything works correctly. If you hit a bug related to this patch let me know, but please don't open a report on bugs.kde.org. I hope this patch is helpful for you. If you need improvements you are of course more than welcome to contribute to KWin :-) A Merry Christmas to you and a happy and successful new year 2013. Kind Regards Martin Gräßlin KWin Maintainer [1] http://quickgit.kde.org/?p=clones%2Fkde-workspace%2Fgraesslin%2Fkde- workspace.git&a=commitdiff&h=2f23192fe2658b9ecde005db40b2ec366b3e18d4&hp=60844a5744b04483e86bff299713e1e56df52a4a [2] http://quickgit.kde.org/?p=kde- workspace.git&a=shortlog&h=60844a5744b04483e86bff299713e1e56df52a4a [3] http://quickgit.kde.org/?p=clones%2Fkde-workspace%2Fgraesslin%2Fkde- workspace.git [4] http://techbase.kde.org/Projects/KWin/Build_Options [5] http://community.kde.org/KWin/Building [6] http://techbase.kde.org/Development/Tutorials/KWin/WindowSwitcher [7] http://techbase.kde.org/Development/Tutorials/KWin/Scripting

3 3

API updates
by Timothy Pearson 19 Jan '13

19 Jan '13

Just a quick heads up that there are some large updates going int GIT right now to rename KApplication; you may want to hold off on building TDE from GIT for a few days while I verify they went in properly. Tim

1 0

Bug 1290 - Kpowersave 100% cpu
by Calvin Morrison 17 Jan '13

17 Jan '13

Hey all, Can anyone pitch in ideas for dealing with bug 1290? Hal is badly outdated and kpowersave is acting up, so debugging it could be very tricky, We also have kpowersave-nohal ready for R14... what should we do? Calvin

3 2

Re: [trinity-devel] GIT change
by Darrell Anderson 11 Jan '13

11 Jan '13

>Developers, please delete and re-download the top-level GIT supermodule. >I have temporarily locked out commit access to that top level supermodule >to prevent accidental merges of the old history. All other GIT modules >continue to have normal read/write permissions for the TDE development >team, so the impact of this should be minimal. Supermodule? Delete exactly what directory in the tree? Darrell

4 4

Workaround for bad Qt4 performance
by Sanne 06 Jan '13

06 Jan '13

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

3 2

Spreading the window sizes while screens changes
by Slávek Banko 02 Jan '13

02 Jan '13

In relation with the recently reported bug #1378 http://bugs.pearsoncomputing.net/show_bug.cgi?id=1378 got my attention thing prepared for KDE4: http://www.h-online.com/open/news/item/KDE-display-management-to-get-a-boos… Often I see spreading window sizes when turn on / off secondary screen or switching from internal laptop screen to external and back. Another problem is that after restoring a maximized window may be restored onto already unavailable screen. When turn on the second screen will also become invisible in the taskbar windows that were open in single-screen mode. Note: I know, I need to add information about these issues to bug message. Slavek

1 0

R14.0.0
by Timothy Pearson 02 Jan '13

02 Jan '13

All, I am now officially back from my holiday vacation away from TDE. I would like to get R14.0.0 squared away and out the door in the next few months if possible; thoughts on the current status of the nightly builds are welcome. I know quite a few bugs remain, however many critical bugs have been repaired and I don't want to hold those fixes (which cannot be ported to the 3.5.13.x series) back much longer. How does a tentative release date of April 15, 2013 sound? This means that the remaining blocker bugs need to be resolved by February 2013 in order to get the R14 release candidate into the hands of our QA team with sufficient time for them to find and resolve quality problems before release. A tentative final source release date would be March 15; this would allow 2 weeks for the binary build maintainers to update their packages before release, and a week or two for the mirrors to sync with the new packages. For me the biggest blocker bug remaining is the XDG icon naming issue (http://bugs.pearsoncomputing.net/show_bug.cgi?id=1313), as this causes a very bad (inconsistent) user experience with most non-TDE software packages. I will be working hard to resolve that issue; if each developer here could find a large blocker bug and work on fixing it over the next few weeks that would be great! Tim

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels January 2013