23 Dec
2012
23 Dec
'12
11:38 a.m.
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
23 Dec
23 Dec
6:35 p.m.
New subject: [trinity-devel] Standalone build of KWin
On 23 December 2012 06:38, Martin Gräßlin <mgraesslin(a)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
11:02 p.m.
New subject: [trinity-devel] Standalone build of KWin
On Sunday 23 December 2012 13:35:31 Calvin Morrison wrote:
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.
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.
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.
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.
On 23 December 2012 06:38, Martin Gräßlin
<mgraesslin(a)kde.org> wrote:
yeah same here - also off for a few days.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)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 
20 Jan
20 Jan
6:51 a.m.
New subject: [trinity-devel] Standalone build of KWin
On Sunday 23 December 2012 13:35:31 Calvin Morrison
wrote:
> On 23 December 2012 06:38, Martin GräÃlin <mgraesslin(a)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
4116
days inactive
4144
days old
3 comments
3 participants
participants (3)
-
Calvin Morrison -
Martin Gräßlin -
Timothy Pearson