On Sunday 23 December 2012 13:35:31 Calvin Morrison wrote:
> 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.
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@...
> For additional commands, e-mail:
> trinity-devel-help@... 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
Attachments: