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
On 23 December 2012 06:38, Martin Gräßlin mgraesslin@kde.org wrote:
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].
Excellent,
I will be looking into this over the break, with time off from university. Our team is taking a bit of a holiday break, so I don't expect much progress or response from them ;) Hopefully I can start looking at this post - christmas.
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].
KCM's from KDE4, how different are they from those of KDE3? I wonder how difficult it would be to tailor a version of kwin to work with trinity, or alternatively, write a kcm module for kde3 (how much has it changed? My guess is not much).
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.
Will this be changing in the future? I don't really mind either way but overall it'd be nice to reduce the library overhead required for some of our smaller flash based storage desktops (have several mini-pc's and such).
*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.
What is the reasoning for the Xlib seperation? Is it just because it is the most god-abhorred awful api in the world, or will development be more suitable with Qt5?
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.
How is the performance of QML? I'm assuming that it wouldn't really cause an impact because it is only responsible for the UI.
*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.
Thank you, I realize you are putting in a personal effort. Thank you again.
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.
Happy Holidays from Philadelphia!
Calvin Morrison
On Sunday 23 December 2012 13:35:31 Calvin Morrison wrote:
On 23 December 2012 06:38, Martin Gräßlin mgraesslin@kde.org wrote:
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].
Excellent,
I will be looking into this over the break, with time off from university. Our team is taking a bit of a holiday break, so I don't expect much progress or response from them ;) Hopefully I can start looking at this post - christmas.
yeah same here - also off for a few days.
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].
KCM's from KDE4, how different are they from those of KDE3? I wonder how difficult it would be to tailor a version of kwin to work with trinity, or alternatively, write a kcm module for kde3 (how much has it changed? My guess is not much).
KCM's in general or the KCM's of KWin? For KWin there is hardly any difference as they had been hardcoded (older than the invention of ui files). So the main difference would be that KDE 3 used dcop to inform KWin while KDE 4's use DBus. And some options got removed, some got added, some got moved around. Overall probably more new options added than things removed.
From API point of view I don't think that much has changed. Mostly probably the class names of used widgets.
For KWin I want to completely change to KConfigXT and ui files. That allows to mostly autogenerate the KCMs. We have now in 4.10 the ui files so it's just creating the KConfigXT files.
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.
Will this be changing in the future? I don't really mind either way but overall it'd be nice to reduce the library overhead required for some of our smaller flash based storage desktops (have several mini-pc's and such).
Well with KF 5 we will of course only link what we use and that's actually a rather small part of kdelibs and some things got upstreamed into Qt. In general it doesn't really matter as the libs are shared memory.
*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.
What is the reasoning for the Xlib seperation? Is it just because it is the most god-abhorred awful api in the world, or will development be more suitable with Qt5?
Qt 5 uses xcb instead of XLib which means that at least event filtering needs to be done with xcb. Xcb has more advantages most important it is an async API in opposite to XLib which blocks. It basically means that KWin will get lots faster as we don't need to wait for the X-Server that often.
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.
How is the performance of QML? I'm assuming that it wouldn't really cause an impact because it is only responsible for the UI.
performance of QML compared to "what"? You are aware that QML is a technology primarily developed for the now abandonded smart phone strategy at Nokia? If performance is good enough for mobile phones and embedded devices it's probably good enough for more performant desktop systems ;-) But my personal feeling is that the UIs switched to QML perform better than what we used to had before - at least on raster system.
*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.
Thank you, I realize you are putting in a personal effort. Thank you again.
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.
Happy Holidays from Philadelphia!
Calvin Morrison
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Sunday 23 December 2012 13:35:31 Calvin Morrison wrote:
On 23 December 2012 06:38, Martin GräÃlin mgraesslin@kde.org wrote:
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].
Excellent,
<snip>
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.
Martin, thank you for you work on stripping out the kde-workspace components; this opens up the possibility of TDE using kwin for the first time!
Tim
-
Calvin Morrison -
Martin Gräßlin -
Timothy Pearson