>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
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
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
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
>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
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
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
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
