tde-devels

devels@trinitydesktop.org

9 participants
3819 discussions

Decade Old KDE Bug Fixed
by Slávek Banko 21 Jan '13

21 Jan '13

Hi everyone, FYI - an interesting bug and one-line fix: http://paritynews.com/software/item/569-decade-old-kde-bug-fixed ...patch I have already backported into TDE. Slavek --

2 3

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

FOSDEM CrossDesktop DevRoom 2013 - Call for Talks
by Pau Garcia i Quiles 21 Dec '12

21 Dec '12

Hello, The deadline has been extended to December 21st. There will be no more extensions. --8<--- * FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the CrossDesktop DevRoom, which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperativity amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2012 schedule might give you some inspiration: https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html <https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html> Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) - Short abstract of one or two paragraphs - Short bio - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. The deadline for submissions is December 14th 2012. FOSDEM will be held on the weekend of 2-3 February 2013. Please submit your proposals to crossdesktop-devroom(a)lists.fosdem.org (subscribtion page for the mailing list: https://lists.fosdem.org/listinfo/crossdesktop-devroom ) -- The CrossDesktop DevRoom 2013 Organization Team* --8<--- -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels