23 Dec
2012
23 Dec
'12
11:02 p.m.
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