trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: December 2012

Re: [trinity-devel] Standalone build of KWin

From: Calvin Morrison <mutantturkey@...>
Date: Sun, 23 Dec 2012 13:35:31 -0500
On 23 December 2012 06:38, Martin Gräßlin <mgraesslin@...> 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