Blog: The Road to KDE Frameworks 5 and Plasma 2

[menotu]

It's a long blog.................  

http://vizzzion.org/blog/2013/01/the-road-to-kde-frameworks-5-and-plasma-2/
==================

By Sebastian Kügler - 22 Jan 2013

The Road to KDE Frameworks 5 and Plasma 2

KDE’s Next Generation user interfaces will run on top of Qt5, on Linux, they will run atop Wayland or Xorg as display server. The user interfaces move away from widget-based X11 rendering to OpenGL. Monolithic libraries are being split up, interdependencies removed and portability and dependencies cut by stronger modularization.

For users, this means higher quality graphics, more organic user interfaces and availability of applications on a wider range of devices.
Developers will find an extensive archive of high-quality, libraries and solutions on top of Qt. Complex problems and a high-level of integration between apps and the workspace allow easy creation of portable, high-quality applications.

The projects to achieve this goal are KDE Frameworks 5 and Plasma 2. In this article, you’ll learn about the reasons for this migration and the status of the individual steps to be taken.

As this article is going to be a bit long, due to its level of detail, you can just skip to the end of every subsection to get the executive summary. Also, I would like to thank Blue Systems for their sponsoring of a lot of the work that is going into the future of KDE’s products, among which, mine.
Status Frameworks 5

Development of KDE’s Frameworks5, which focuses on modularization of APIs currently contained in kdelibs and kde-runtime, loosening its internal structure and making it possible to only use specific parts by splitting it into individual libraries and solutions.

The entire work to be done for Frameworks 5.0 is split into 7 topics. Three of these “Epics” are done:

    Initial communication and documentation (Kevin Ottens),
    Merging of code into Qt 5.0 (David Faure)
    Reduction of duplication with Qt by removing classes and using their Qt alternatives (Stephen Kelly)

Four Epics are currently work in progress, three of them are monstrous:

    Build system (Alex Neundorf, Stephen Kelly)

        CMake (upstreaming some stuff, modularization, porting)
        Modularization of CMake KDE settings (work in progress)
        Modularization of macros
        Review and inventarize Find* CMake modules
    kdelibs cleanups (David Faure)

    This is a large Epic, containing many bite-sized tasks. Roughly 50% of them are done, 37 tasks remain open and 7 are being worked on, an extensive list is on the wiki.

    Qt 5.1 merging (David Faure)

    This is the list of things that we haven’t been able to merge upstream into Qt 5.0, so we hope we can upstream as much as possible into Qt 5.1. This can potentially cause timing problems, if we can’t get all the necessary things we need into Qt 5.1. 9 tasks are work in progress by David Faure, Thiago Maciera, Richard Moore and others. 52 tasks are on the todo list, most of them currently unclaimed.

    Splitting kdelibs (blocked) (Kevin Ottens)

    Another large Epic, in bigger chunks, meaning going through all libraries one by one, porting their build system to the changes in Frameworks5, cut out certain library dependencies and changing the translation system. 13 tasks are done, 12 work in progress and 8 on the todo list, not all of them assigned.

    An extensive list of libraries and their status can be found on the wiki.

Frameworks 5 currently compiles on top of Qt 5.0 and basic system services run (kdeinit5), although not all of its dependencies have been ported to Qt 5. Work on Frameworks5 is ongoing, so it is currently quite a moving target, and will remain so for a while.
Plasma and KWin Direction

An architecture based on Qt5 and Wayland makes it possible to use a more modern graphics stack, which means moving from X11-based rendering to OpenGL graphics rendering. QtQuick2 (which is the QtQuick shipped with Qt5) makes it possible to offer a very nice and extensible development API, while using the full power of the graphics hardware to produce excellent visual possibilites. Plasma offers development APIs that make it easy to create well-integrated applications as well as workspaces that are flexible, extensible and fully featured on top of QtQuick, and in the future QtQuick2.

As KDE moves forward towards Frameworks5, Plasma is taking the opportunity of the source and binary compatibility break of Qt5 to do necessary updates to its architecture. The goal is to have a leaner Plasma Development API and depdendency chain and achieve a better user- and developer experience by moving the UI fully to Plasma Quick, which is QtQuick plus a number of integration components for theming, compositor interaction, internationalization, data access and sharing, configuration, hardware, etc..

This constitutes a major refactoring of the Plasma libraries and components. First, their UI needs to be done in QML. This effort of porting workspace components to QML is already well underway. Second, the Plasma library and runtime components need to be ported from the QGraphicsView-based canvas to QML. This means cutting out dependencies on classes such as QGraphicsItem and QGraphicsWidget to their equivalent in QML. In the case of painting and layouting code, it means porting this code to QML.
Detailed Status Plasma Framework

The first bigger set of tasks is done:

    API changes have been made in libplasma2 (done)
    De-QGraphicsViewification of libplasma2 (done)

The open tasks are:

    Remaining libplasma2 design tasks
        Out-of-process dataengines
        Dataengines as models
        More fine-grained data retention in dataengines
        Improved remote widgets
        Change libplasma2 directory structure to reflect Frameworks5 policies
    Create a scenegraph-based shell, make it load a QtQuick2Corona, Containments and Applets
    Port QML Scriptengine to QtQuick2
    Port scriptengine from QScriptEngine to QDeclarativeEngine
    Remove dependency on graphics backend (QGraphicsView, or scenegraph) (Marco Martin)
  
 Port imports to QtQuick2
        Plasma Core (containing Theme, FrameSvg, DataSource, etc.)

        Plasma Components (containing a basic QtQuick widget set)

        QtExtras (containing components missing in Qt, such as MouseEventListener)

        PlasmaExtras (containing additional UI widgets for better integration, such as animations, text layout helpers, Share-like-connect integration, etc.)

    Making scriptengines (such as the Python scriptengine) only export QObject-deriven classes to the QML runtime (needs investigation right now)

    Port of widgets away from QGraphics*, also necessary for some QML code

Plans for KWin Plasma Compositor

Plasma Compositor refers, in a Wayland world, to the compositor used for Plasma workspaces, which is essentially KWin in disguise as Wayland compositor.
In KWin, we benefit from an ongoing effort to modularize and clean it up architecturally. For most of its UI, KWin already supports QML (Window decorations, tabswitcher, etc.). Some mechanisms which currenty work through XAtoms will need to be ported, the API impact of that will likely be quite limited for application developers.

The strategy for KWin is to port KWin to Qt 5, then make it possible to run KWin outside of an X server on top of KMS, using the graphics hardware more directly. The next step is to use KWin as compositor for Wayland display servers. The dependency of X11 can be removed once it is not needed anymore to provide compatibility with X11 applications, or can possibly be made optional.
Milestones for KWin (Martin Graesslin) (updated with further clarifications, thanks Martin):

    KWin on Qt5 (work in progress, planned for 4.11): KWin will not depend on Qt 5 as of 4.11. The idea is to have KWin in a state that we could compile KWin with Qt 5/KF 5. But as it is unlikely that KF 5 will be allowed dependency for 4.11, we will not see a KWin on top of Qt 5 even if we achieve that goal. It’s a weak goal as we cannot release on it anyway.

    on top of KMS (planned for 4.11): KWin in 4.11 will still run on top of the X-Server. This is mostly about adding a proof-of-concept. Whether that will be merged into 4.11 and compilation enabled will be seen once the code has been written. So in this case it will at most be an additional very hidden (env variable) mode for testing.

    KWin as Wayland compositor (planned for 4.12): Again only as addition. As of 4.12 we will still be targetting X-Server as default. If we succeed we might add an option. But this pretty much depends on the state of Qt 5/KF 5 and QtCompositor. If any of those dependencies is not ready to depend on, the code might exist, but will not be released.

    no X11 dependency (planned for the distant future): There are no plans to drop X11 support. But we want to have the possibility to build a KWin without X for new targets like Plasma Active. For the desktop there are no such plans.

Plasma Workspaces

The porting strategy of the workspaces is to port plasmoids and containments to QML, in order to make them ready to run on top of the new infrastructure. In the case of C++ and Python, Ruby, JavaScript and “Web API” applets, it means rewriting them in QML. For portability and maintainability reasons, pure QML widgets are preferred. For some complex use cases, that can not be easily done in QML, we ship a combined C++ QML applet. For Plasma2, the only way to do the UI is using QML. QGraphicsWidget based Uis will not be supported anymore.

Once we have a working libplasma2 and a useful set of QML Plasmoids, we can think of running an entire workspace in QML and on top of QtQuick2, either on top of X11, or with KWin’s plans in mind, on Wayland.

Porting status of important widgets to QML / Plasma Quick needed for the workspace:

    Taskbar (close to first review, target: 4.11) (Eike Hein)
    Folderview (work in progress) (Ignat Semenov)
    Desktop containment (second revision close to review, target: 4.11) (Sebastian Kügler)
    Calendar (work in progress, target: 4.11) (Davide Bettio, Sebastian Kügler)
    Kickoff (about to be merged into master, target: 4.11)
    KRunner (work in progress, target: 4.11) Aaron Seigo, Aleix Pol
    Done: System tray, pager, notifications, device notifier, battery, lock/logout, weather, Wallpaper, Containment support
    Open:

        Digital Clock
        Icon
        Picture Frame
        others from kdeplasma-addons
        and more (see wiki)

Conclusion

KDE’s Framework 5 project is well underway. It will allow us to move to a more modern graphics rendering engine, make our development platform more portable, and make it easier to reuse solutions KDE has built. The work does not happen by itself, however, yet it is time-critical. With Qt5.0 being released, 3rd parties are porting their code already. These people will only consider using KDE’s technologies if they are actually available — and that means we need a Frameworks 5 release.

So is this going to be KDE 5? The answer to this question is still “No!”, for a number of reasons:

    KDE is the community, not the software

    Frameworks 5, apps and the Plasma workspaces are not one singular entity. These parts are only released together (which might change in the future), and cobbling them up under one name really is really not helpful. (3rd party developers will think we’re only targeting Plasma workspaces, Plasma users will think you’ll only be able to run “KDE apps”, potential users of applications will assume that you can only use them inside Plasma workspaces — all of them untrue, all of them taken right out of my daily experience)

    Within the Plasma team, we tend to use the abbreviation PW2 to refer to the next generation of Plasma workspaces. It stands for Plasma Workspaces 2, and it will probably be named differently in the future.

So, now you’re fully up to date on the status, isn’t it time to get cracking?

[menotu]

Not as long as  the previous blog but it includes a Youtube video
========================================

By Sebastian Kügler - 29-Jan 2013

Desktop Containment moving to Plasma Quick

As many other components of the Plasma Workspaces, Plasma Desktop’s default Containment is being ported to QML. A technology preview of the containment is being demoed and can be tested by a wider audience now. While the port is mainly replicating the current desktop containment in QML, its interaction scheme to position and manipulate widgets on the desktop has been improved.

First of all, a note: The code presented in this article is not part of the upcoming Plasma Desktop 4.10. It can easily be installed on top of it, it might see inclusion in the summer 2013 release, however

In our Roadmap, you learn that KDE is currently porting many aspects of its workspaces to QML, with the goal to create a more modern user experience on top of state-of-the-art technologies such as Qt5, OpenGL scenegraph and Wayland. The move to QML is a gradual process, made possible by the componentized architecture of Plasma.

Widgets and other components that make up the workspace are replaced with QML ports one by one. The premise is to not introduce regressions by shipping each component “when it’s ready”. Ultimately, we need a complete set of QML components to run the whole desktop (and at some point also apps) directly on top of the graphics hardware, leading to higher graphics performance and more available resources on the CPU.

One of the important pieces is the Desktop containment. This is the component in Plasma that is responsible for managing and laying out widgets on the desktop and creating the toolbox (which makes some “workspace actions” available to the user. In general, a “Containment” is an area on the screen (a panel, the desktop background, the dashboard, …), and it takes care of managing widgets, their position and sizing within. It also offers access to action specific to widgets, or the containment or workspace.

The currently shipped (also in 4.10) default Desktop containment is written in C++, using QGraphicsWidgets and offers free placing of widgets on the desktop, with a bit of edge and overlap detection and repositioning poured in.

Preview QML Desktop Containment video
https://www.youtube.com/watch?v=GR5UZUtcOGc&feature=player_embedded


full blog and links

[menotu]

Further info from Aaron Seigo
=====================
Tuesday, January 29, 2013

Plasma.next()?

Sebastian wrote a pair of blog entries in the last week about where we are heading with Plasma in the near future. The first was an overview of the pathway to Frameworks 5 and what we're provisionally referring to as Plasma Workspaces 2. The second entry covered his work on making it possible to write widget layouts (aka Containments) in QML.

For me, the key sentence in that entry was this:

    The work that is upcoming in Plasma Desktop is further bridging the gap between Plasma’s interfaces for different devices and formfactors.

 I'd like to share a little bit more about what this means long-term, and share a few more nuggets of where we are headed with the various Plasma workspaces in the process.

One Shell To Bind Them

In the early days of Plasma, the idea was to write one binary per form factor and share components between them. This would allow us to sculpt the overall interaction pattern of the shell while sharing the bulk of actual code, particularly the code that took the most effort such as network management. The shells take care of creating and managing the windows that make up the shell: panels, desktop layers, configuration dialogs and controls.

The desktop shell has around 9,300 lines of code,

the netbook shelll has under 3,000

and plasma-device (used in Plasma Active) has a little under 4000.

Given that the rest of the Plasma code base ends up closer to a quarter million lines, this has been a pretty effective strategy.

lots more here

[menotu]

From Aaron Seigo - Friday, March 15, 2013

logging into Plasma Workspaces 2

Contestant #1: KDM
Contestant #2: LightDM  
Contestent #3: SDDM

You're probably wondering what I was doing at 1am last night. I get asked that all the time. Well, mostly by people I live with, now that I think about it. "What were you doing on your computer at one in the morning?" they ask. The answer is usually quite exciting. Take last night, for instance: I was having a meeting with people to discuss display managers. Yes, the wonderful world of login screens.

We now have a truly amazing spreadsheet that tabulates the current state of three display managers. It has sections from community, "soft" attributes (such as licensing and build system), technology support, features and performance. Unfortunately, this did not lead us to any firm conclusions but it was very useful in helping better understand the landscape here, which is what we were after.

Our Requirements

The question we are trying to answer is this: What display manager will we use in Plasma Workspaces 2? Candidates must match a simple and clear set of needs:

    Must be lightweight. We want to use this on desktops and devices.
    Must be maintainable. (Self explanatory.)
    Must be able to write the user interface in QML.
    Must be able to be a Wayland system compositor.

How hard can that be, right? Bonus points are awarded for things like:

    Used by other projects (co-investment and user consistency)

    Familiar tooling (we can always learn and use another revision control system, but we'd rather not as that raises the bar for participation)

Given that as a starting point we looked at three options and here's what my take-away on each was.

Contestant #1: KDM

This contestant is a deep soul with much complexity who likes things the old-fashioned way. 20 year old scotch is its drink of choice, and it hates walks on the beach (not much of a romantic, you see). It holds advanced degrees in many traditional practices. Let's say hello to .. KDM!
KDM does a lot of things very well. It is highly scalable (10k users in LDAP? No problem.), supports features such as remote log in, can be used with hardware and biometric keys and much more. It is themable, as a Google images search can quickly confirm.

Unfortunately, there has not been much work on it lately and none of the active developers know the codebase very well. And what a codebase it is! 34,000+ lines of code, nearly 14,000 lines of which are C with the rest mostly C++. It is a beast. Interestingly, the KDM settings UI is 6,400+ lines of C++. That makes it's control panel nearly twice as big in terms of code count as the Plasma Active shell.

Work had been started on making a QML front end for it (twice, I believe) but it never came to full fruition, and it is unclear just how best to add a Wayland system comositor to KDM would be. So though it has served us well, KDM actually fails to meet our requirements.

Contestant #2: LightDM

This contestant is a young but accomplished fellow with lots of modern features. An outgoing sort, he strives to be useful to all around him and tries not to make many assumptions about what would make you happy. With lots of friends, he's seen at the entrance to many parties .. say hello to: LightDM!
With just over 20,000 lines of C code (though getting closer to 22,000 with the KDE integration bits), LightDM has a terrific number of features. It has a clear separation between the toolkit-agnostic backend and user interface providing front-ends that communicate via a local socket to get the deed done.

Guest login, auto-login, VNC/RDP/XDMCP, power management, fast user switching .. it's all there. Outside of a few things like biometrics, it has a superset of KDM's features. It also has support for new Linux middleware such as systemd and AccountsService, and does it all with a very small footprint (the daemon takes well under 1MB of RAM). It is also quite extensible and used by a large number of projects including the *buntu family of Linux distributions, RazorQt, Elementary and XBMC.

There are three main contributors to the core LightDM according to the commit logs, all of whome work at Canonical. In addition to their efforts, David Edmundson's has been working on KDE integration for LightDM in KDE's repositories. Thanks to his work, you can write your UI in QML and PowerDevil is used for power management giving us consistency and portability. There is still work to be done, but it works rather well right now. I've been using it on my laptop for a while now, so that's not just theory.

A big piece of work that needs to be done is to add a Wayland system compositor. This is where things get tricky. LightDM is a Canonical project, and as such they will not be working on a Wayland compositor since they decided to part ways with the rest of the Free software ecosystem and create their own display system, Mir. One of our big questions was whether a Wayland compositor would be welcome.

Robert Ancell, the LightDM maintainer, attended last night's meeting which was extremely helpful. According to him, a Wayland backend would be welcome (though they won't write any of it) and there will be no hard dependencies on Mir in LightDM. This is reassuring, but means we need to trust the roadmap of Canonical a bit here and also means we'll be doing all the heavy lifting on the Wayland side. David has stepped up to do that work, however, which is also encouraging.

Due to LightDM being under Canonical's purview, contributing to it requires signing the Canonical CLA which is not acceptable to many developers (including myself) as it allows Canonical to take any and all code written that ends up in a Canonical owned asset and close it. This means that we won't really be able to contribute to core LightDM very effectively as a team. Some individuals may choose to do so, but several have already stated they won't, including those with the most experience with things like Wayland.

The fact that it is already widely used is a plus, however, as it means we may be able to share some efforts with others. This is particularly useful for system integration bits. For instance, Robert noted that Ubuntu will be working on logind support for LightDM. That said, some of our downstream distribution partners seem less than keen on supporting LightDM in their distributions.
So in summary: very featureful, relatively mature after three years of development, we already have a good amount of integration, but it carries risk due to community and commercial dynamics.

Contestent #3: SDDM

This young whipper-snapper is still wet behind the ears, as they say, and is still learning the ropes but she's fast and lean and sports a shiny approach to life. Let's say hello to SDDM!
This project is only three months old and as such is, by far, the youngest of the bunch. It also has the fewest features. However, with less than 2,200 lines of code it already provides the daemon/frontend duality with socket communication much as LightDM does and the user interface is written with QML. In fact, the entire thing is written in C++ using Qt and the code is very clean at this point. As with LightDM, it's memory footprint is more than reasonable.

It is an open, community developed project and has been picked up by the relatively new QML-based Maui desktop project. The use of C++, Qt, CMake and git make this a very familiar feeling to the code base for us Plasma hackers. The QML package structure is actually very similar to our own, and I understand that was not completely by coincidence. There is one main developer with two others who have made some contributions as well. This is fairly similar to the LightDM development profile, except that the contributors are not paid by the same companies to work on it.

As with LightDM and KDM, a Wayland compositor needs to be written for SDDM. It also needs to gain support for a large number of features it is currently missing, such as AccountsServices, guest accounts and a number of others. It does already support systemd and have some power management features.
The biggest concern I have is the youth of the project. Will it continue to be worked on and mantained? Will other projects also adopt it as it matures? Only time can tell.  I am very keen to seen how SDDM develops over the next couple of months.

Conclusions

This is a difficult decision to make. KDM is not going to make the transition into a QML and Wayland world with us, despite it having served us well in the past. We need something to take its place, and we'd prefer not to start from scratch when there are good choices that already exist.

On the one hand we have the feature filled LightDM with three years of track record behind it, but which still needs work to make it do what we want, and which has a relatively large codebase that will be hard to contribute to. That said, David has already put a good amount of effort into the QML support for LightDM.

On the other hand we have a youthful, and thus largely unproven, SDDM which needs even more work than what we'd have to dedicate to LightDM but whose code base is very small, modern and uses familiar tools and which is developed openly. We won't need to do any QML work, but we will need more system integration features. With SDDM, there'd also be very limited (if any) opportunities to work with non-Qt/QML desktop projects.

If more projects interested in Wayland got involved with either LightDM or SDDM, that could tilt the scales as we would be able to share the compositor work with them. Personally, I'm torn between the open community and great code base of SDDM and the utility, maturity and wide usage of LightDM.

http://aseigo.blogspot.co.uk/2013/03/logging-into-plasma-workspaces-2.html

==============
    
David Edmundson's Web Log

The plan for LightDM-0.2

[Just17]

Due to LightDM being under Canonical's purview, contributing to it requires signing the Canonical CLA which is not acceptable to many developers (including myself) as it allows Canonical to take any and all code written that ends up in a Canonical owned asset and close it.

I hope that sways the decision .......

in truth I thought they had dropped that requirement as I have not heard much about it of late ....  apparently I was very much mistaken 

[menotu]

Lots more details on the blog - I've just linked a couple of videos
======================-=================

By Sebastian Kügler - 18-March 2013

What’s going on in Plasma Workspaces 2?

Let’s start with something visual, before we get to the nitty-gritty:

Video showing a basic port of a Plasma Desktop Containment to Plasma 2

https://www.youtube.com/watch?feature=player_embedded&v=mtKwjNdZFt4

Video showing a Plasma 2 OpenGL shader demo widget

https://www.youtube.com/watch?v=IbmcBkERYbU

http://vizzzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/

[menotu]

From Aaron Seigo - Friday, March 22, 2013

Llike an avalanche coming down the mountain When looking over the KDE landscape this week I was felt a similar Spring feeling in the air. There are new maintainers for Qt/KDE integration of PolicyKit and KMix. Sebas updated us recently on the huge progress being made for Plasma Workspaces 2, featuring a working shell on top of libplasma2 and QtQuick2. This itself is just a small part of the larger Frameworks 5 effort, and that is receiving more attention such as the recent sprint in Spain that Albert wrote about. Krita continues to amaze, Ingo has made a breakthrough in taming our web presence continuity and there is even work happening on Akregrator!

There were two other happenings this week that were of personal interest.

Bodega Web Client

irst, was the announcement of the work-in-progress Bodega web client. Bodega is a little node.js server that Zack and I started so we could have a Free software content store. Since then others have pitched in including Marco, Antonis and Giorgos from the Plasma team. We have a C++ client-side library that speaks all the right json for you which we use in the Plasma Active add-ons client and now we have the start of a web client.

This web client is also written using node.js and can be easily run on pretty well any sort of device. Here is a quick screenshot of it running on my laptop:

It currently requires a redis instance in the background to store the session which makes sense for where scalability is required, but this could be made optional fairly easily. Otherwise, it's a simple matter of running `npm update` and starting `node app.js` (or if you prefer: `forever app.js`).

There is a significant implication here: you could pop this simple web app on virtually any sort of device, including ones with no screen attached, connect via your web browser and start browsing and installing content from a given Bodega server. One could also put this on a server to deliver content to machines connecting to it.

Imagine installing add-ons to your wireless router or the media box in the living room via the same interface that you get add-ons for your desktop system or your tablet. That's what we're building, and it's all Free software.

The web client has just begun, and so is not yet feature complete, but it is progressing quickly. The Bodega server is quite functional, but it too could use some feature additions. We're busy working on these things, but always remember that there is a place for you, too! If you have experience with node.js, web development or QML and find this concept exciting, you can find us online in #active on irc.freenode.net and the active at kde.org mailing list.

Plasma Media Center

We also saw the first release of Plasma Media Center, or PMC, this week.

Why does the world need yet another media center? On the one hand, it doesn't: things like XBMC are quite awesome. On the other hand, we have a specific set of requirements that isn't fulfilled by what was available and there was no realistic way to meet them with what existed without significantly altering them. Expecting other projects to suddenly change everything they were doing to meet our rather specific needs was neither realistic nor, I felt, very nice to ask of these other projects.

Our requirements were:


    A simple and clear, scalable user interface. It needs to work as nicely on a tablet sitting in your hands 40cm from your face as it does on a great big television sitting on the other side of the room.

    Integrate with Plasma workspaces: visually, in configuration and in user interaction patterns.
    Use the same technology infrastructure we do, such as using Nepomuk to populate the media
    Be able to integrate with online services
    Be extensible so thing additional features such as T.V. channel listings can be added.

During this time, there has also been the development of applications that hit a couple of these points very nicely, such as Bangarang which uses Nepomuk and KDE's libraries. These are primarily "window optimized" and we still need something focused on full-screen and alternative input methods .. which is where PMC comes in.

We want to be able to provide a consistent, full screen, simple media playback and exploration interface across the device spectrum .. and now we can. This will not replace Amarok, Bangarang, Dragon, JuK, ... nor could it without fundamentally adjusting the goals of PMC, which we obviously can't do while keeping to our goals. PMC is for when you want your device to focus on media consumption .. and that's it.

As is typical, PMC does not roll its own media playback but relies on Qt and underlying technologies such as GStreamer for this and it uses QML extensively throughout. I'll be talking more about PMC tonight in this week's episode of The Luminosity of Free Software, so if you'd like to see it in action and learn about some of the more interesting technical details tune in there.

http://aseigo.blogspot.co.uk/2013/03/like-avalanche-coming-down-mountain.html

[menotu]

From Mart - A tale of a little pixel (notmart.org)

Another Tokamak is over, and a very good one indeed

Many things have been done, many things have been decided this week. The main topic was prevalently about the architecture of our next workspace, and the frameworks needed to make such a vision coming to reality.

As you may already know, the new Plasma workspace we are now working on is based on Qt 5, QML2 and KDE Frameworks 5.

The platform will still run on X11, but down the road Wayland support will be added as well, work is ongoing in KWin for that.

First thing, when the new workspace based on that new technology will be released?

When is ready, where ready means there are no significant regressions left, so there will be a big technology change, but no significant disruption on the user interface.

There will be some small changes however, because the incremental improvement of the UI is a process that never stops. The login screen, the splash screen, the lock screen, the logout dialog and the fast user switching interface will look consistent all across the board, with a single, coherent QML theme for all those elements. As a side effect will make very easy to heavily customize the look and behavior of those components, either by users or vendors.

As the components mentioned before, also the shell itself will be defined by a single package.

This packae will define things such as the behavior of the desktop (icons? what plasmoids? what default wallpaper?), of the panels (how many? where?, what they do contain?), of the run command interface, and so on.

It will be possible to change this shell package at runtime, this means that user experiences such as Plasma Desktop, Plasma Active and Plasma Media Center can be loaded on the fly, on the same device and only when needed.

You have a Plasma Active tablet that comes with a docking station? attach it and you'll have Plasma Desktop on your screen. You attach your laptop to your 40 inch TV, and you get Plasma Media Center.[/b]

One interface does not fit any device, but one technology does, especially when it can give you an user interface always optimized for the device you are using in a particular moment.

http://www.notmart.org/index.php/BlaBla/Tokamak_6

[Just17]

One interface does not fit any device, but one technology does, especially when it can give you an user interface always optimized for the device you are using in a particular moment.

Nice way to say it  +1

[menotu]

A blog about KWin and Wayland

http://www.pclinuxos.com/forum/index.php/topic,113140.msg989480.html#msg989480

[Just17]

I just tried RazorQT on 64 bit KDE .......  it has a lot of promise for a 'light' KDE .......  with all the wobbly windows etc you might need.

Just a couple of small things on initial look .......  like the menus being messed up and such.

Otherwise I liked it!

Impressive improvement over the previous version I tried.