Tag Archives: Razor Qt

Linux

Spooning, not forking

Leave a comment

One thing that strikes me here during Akademy is the sense of community convergence one gets.

While other Free software projects drift apart, splitting up in multiple forks that stop talking to each other, differentiate based on the wrong reasons, what we see here during Akademy is projects growing closer to each other. This is a good development, so let’s look at it a bit more detailed.

KDE is continually evolving, becoming more diverse by the day. As an organisation, we realised that, and many see KDE as an umbrella organisation for Free software, rather than a “project doing a desktop environment”. When we published the KDE Manifesto, we set the tone for this to happen, and now we see it unfold. The KDE manifesto defines KDE as a community of like-minded Free software people. One of the most important adjectives to describe KDE is inclusive, that means that we define ourselves in terms of commonalities, rather than trying to differentiate ourselves from our peers.

Also, as an organisation that is in the business for 17 years, we have gathered a large body of expertise, best practises, knowledge how to run a community. We have also proven to be a sustainable and stable organisation.

At Akademy, the KDE community is joined by a wide variety of people not directly involved with KDE. We have VLC here, Razor Qt, Mer and of course our long-time friends from Qt present. This, on the one hand provides excellent opportunities for cross-pollination and solving common problems (or even just sharing pain!), on the other hand it makes us think if we’re at the right level of collaboration right now. Is there more to share among these distinct organisation, does it make sense to merge some of them and share the overhead?

This surely is food for thought, and I expect this class of discussions to last until long after Akademy, but it is very refreshing to see. It also increases the value of all our communities. Synergy through convergence.

It’s also an excellent way to make new friends, and look outside our own frame of reference.

…read more

Source: FULL ARTICLE at Planet KDE

Linux

The relationship between Plasma and KWin in Workspaces 2

Leave a comment

Yesterday during the Tokamak 6 sprint in Nuremberg we discussed the role of KWin in Plasma Workspaces 2. At the moment in Plasma Workspaces 1 KWin is of course the recommended window manager and compositor, but it’s also possible to use a different window manager. Back in the days there were quite a lot of users who run Plasma with Compiz. In theory that shouldn’t matter because everything is standardized with EWMH and ICCCM. Over the years we added more and more extensions to EWMH. It’s all open source so anyone can implement these extensions (Compiz used to do so), nevertheless right now there is probably no other window manager available to offer the full experience except KWin.

Plasma Workspaces 2 will be released at an interesting point of time. We don’t want to do the transition to Qt 5 and Wayland at the same time, so it will still be X based. But we all agree that our future will be on Wayland and even if we use X as the windowing system our primary focus is on Wayland. With Wayland quite a few things will change. KWin will play a more important role as it will be the Wayland compositor – we do not plan to use Weston.

Given that we know that the Wayland shell interface only covers part of what Plasma needs and some of our needs are extremely Plasma specific (for example Activities) it would be tempting to say that we tie KWin to Plasma. Let’s face it: which other compositor will be there to replace KWin? The reference compositor will probably never accept Plasma specific patches for things like Activities, Compiz won’t be ported to Wayland and GNOME Shell will probably never be a solution for Plasma. For the small window managers we do not know whether they will go to Wayland at all, but I expect rather not, though I expect that we will see Weston forks/extensions for substitutions of tiling window managers.

We decided to resist the temptation to go the easy road, but instead will develop all our integration bits in a way that one could replace KWin by a different Wayland compositor, even if that is just a theoretical option. Of course we will not do any fallback modes for the case that one is using e.g. Weston without Plasma integration bits. So the features which we need might then just be disabled. Adding fallback modes would most likely just result in bit rotting code as nobody would use it.

Of course to make it possible that others can provide compatibility features we need to properly document our extensions and additional interfaces. Luckily Wayland implicitly forces us to do so. The general plan is to publish our extensions and also try to standardize what makes sense to be standardized and we hope that this would also benefit other projects. What we especially had in mind is of course Razor-Qt which already supports using KWin. By properly documenting all our Plasma-KWin communication channel, they can

From: http://blog.martin-graesslin.com/blog/2013/04/the-relationship-between-plasma-and-kwin-in-workspaces-2/

Linux

An update on KWin on 5

Leave a comment

I realized I haven’t written a blog post to highlight the latest changes in KWin for quite some time. The reason for this is that we currently are mostly focused on getting KWin to work on Qt 5/KDE Frameworks 5. As I have mentioned already in the past KWin is a little bit special in the transition to Qt 5 as we used the low level native, non-portable functions provided by Qt (last week I found one usage of a native function which is not even documented). For us it mostly means that we transit from XLib to XCB and remove code which uses methods which got removed or replaced.

Although that means that we hardly have any new features there are quite some improvements all over KWin. Having to touch the code anyway allows us to also rethink how we tackle a problem.

For example we use Plasma functionality at a few places. The code got added before QtQuick existed so it uses QGraphicsView. With libplasma2 the QGraphicsView support is going to be removed which means we need to adjust our code. Over the last years some areas in KWin already made the transition from Plasma styled QGraphicsView to QtQuick, such as our Window Switcher or the Desktop Change OSD. But some areas remained: the close button in Present Windows and the add/remove desktop button in Desktop Grid. Here we have now a nice improvement ready for 4.11: these elements got rewritten in QML and they look way better now.

Aus KWin

For comparison just do Ctrl+F8 or Click here.

This was AFAIK the last bits of UI in KWin which hasn’t done the transition to QML yet. By using QML for all of our UIs the code becomes much easier to maintain, easier for users to improve it, easier to style it. The last point is really important for KWin adjustments for non-Plasma environments like Razor-Qt. Though they use a fair bit of Plasma styling already and with KF5 libplasma2 will be so small that it hardly matters

The screenshot also shows another new improvement thanks to the transition to XCB. In the left upper corner a glow is shown when approaching the corner with the mouse cursor. If you use auto-hiding Plasma panels you already know this glow. This change became possible because the screen edge related code was one of our strongest user of XLib and a refactoring was needed anyway to support the world after X. The new design follows an approach which will make it easy to add support for a new windowing system – even if I do not know how exactly that will look like in a Wayland world (currently Qt5 is the highest priority). Also we plan to make KWin take care of the screen edges needed for the Plasma Panel. This removes quite some duplicated functionality from Plasma and solves the general “problem” that Plasma cannot listen to just all mouse events in a Wayland world.

One …read more
Source: FULL ARTICLE at Planet KDE

Linux

Re-post: David Edmundson KDE, LightDM and the Mir Kerfuffle

Leave a comment

KDE Project: 

A re-post of David Edmundson's blog KDE, LightDM and the Mir Kerfuffle for Planet Ubuntu

With Canonical’s decision to make a new display server, there’s been some questions as to how this affects LightDM and the KDE front end I’ve spent a long time working towards.
It’s a perfectly sensible question, LightDM has heavy Canonical sponsorship, and a display server needs to be supported in the display manager.
Canonical (and Ubuntu) have decided not to adopt Wayland as their new display server, but a new in-house system called Mir. We in KDE have already made the decision that Wayland is the future, and work in kwin has already begun on that. Having a Display Manager that supports a Wayland system compositor is essential to our long term strategy.
I’ve been asked to address this a lot, so I’ll put my thoughts in a blog post.
The back story
After a bad experience customising KDM for a really important and scary client I wanted to redo the UI and customisation experience of KDM.
I wanted to rewrite the whole UI and config side, so started looking through KDM code. It was around this time Robert Ancell posted about LightDM, a new display manager that aimed to be greeter agnostic. This was around 2 years ago when everyone was getting excited over Wayland, it was clear it was in LightDMs roadmap.
This seemed like a win, win situation. I get an easier platform to write my new login manager on *and* I get to bring Wayland support to KDE.
I wrote Qt bindings around LightDM upstream, along with a reference QWidget based greeter. I then started working on the KDE greeter in our repository.
The KDE greeter is approaching version 0.4. It is included in many distros, and generally feedback has generally been very positive.
The current state
Whilst LightDM is made by Canonical it is community driven and all patches go through review where anyone can comment. I have an opportunity to argue if anything is greeter specific in the libraries.
LightDM is used by my KDE greeter (used in some distros, not all), XFCE, and Razor Qt and of course Unity.
The Qt library was originally only used by us and Razor Qt, but with Unity’s move to QML this means that Canonical are now dependant on the libraries I made. I am still in charge of the Qt library and still get final say on all reviews, I have rejected some Canonical employee patches as needing a rewrite and them with some of mine, it feels like a real open meritocracy community.
The rant
The golden-egg of using LightDM in KDE was that we wouldn’t have to support all the boring things we need to make a display manager work, we wouldn’t need to support a Wayland system compositor we get it for free. We all write stuff that helps each …read more
Source: FULL ARTICLE at Planet KDE

Linux

KDE, LightDM and the Mir Kerfuffle

Leave a comment

With Canonical’s decision to make a new display server, there’s been some questions as to how this affects LightDM and the KDE front end I’ve spent a long time working towards.

It’s a perfectly sensible question, LightDM has heavy Canonical sponsorship, and a display server needs to be supported in the display manager.

Canonical (and Ubuntu) have decided not to adopt Wayland as their new display server, but a new in-house system called Mir. We in KDE have already made the decision that Wayland is the future, and work in kwin has already begun on that. Having a Display Manager that supports a Wayland system compositor is essential to our long term strategy.

I’ve been asked to address this a lot, so I’ll put my thoughts in a blog post.

The back story

After a bad experience customising KDM for a really important and scary client I wanted to redo the UI and customisation experience of KDM.

I wanted to rewrite the whole UI and config side, so started looking through KDM code. It was around this time Robert Ancell posted about LightDM, a new display manager that aimed to be greeter agnostic. This was around 2 years ago when everyone was getting excited over Wayland, it was clear it was in LightDMs roadmap.

This seemed like a win, win situation. I get an easier platform to write my new login manager on *and* I get to bring Wayland support to KDE.

I wrote Qt bindings around LightDM upstream, along with a reference QWidget based greeter. I then started working on the KDE greeter in our repository.

The KDE greeter is approaching version 0.4. It is included in many distros, and generally feedback has generally been very positive.

The current state

Whilst LightDM is made by Canonical it is community driven and all patches go through review where anyone can comment. I have an opportunity to argue if anything is greeter specific in the libraries.

LightDM is used by my KDE greeter (used in some distros, not all), XFCE, and Razor Qt and of course Unity.

The Qt library was originally only used by us and Razor Qt, but with Unity’s move to QML this means that Canonical are now dependant on the libraries I made. I am still in charge of the Qt library and still get final say on all reviews, I have rejected some Canonical employee patches as needing a rewrite and them with some of mine, it feels like a real open meritocracy community.

The rant

The golden-egg of using LightDM in KDE was that we wouldn’t have to support all the boring things we need to make a display manager work, we wouldn’t need to support a Wayland system compositor we get it for free. We all write stuff that helps each and open source progresses faster.

If I’d known they weren’t going to add Wayland support, I’m not sure I would have invested my time in LightDM. I don’t feel decieved, they thought they would do it at the time and Canonical are perfectly …read more
Source: FULL ARTICLE at Planet KDE