Category: plasma (Page 2 of 2)

Discover in Plasma 5.7

31 May 2016 / apol / 7 Comments

I haven’t talked about what’s going on in the Discover front for a while, here’s a small heads up on what you’ll get in the next Plasma 5.7 release.

Back Ends

PackageKit (and AppStream): This one has received most of the care. It has been rearranged to instant load. Also we made it possible to integrate this backend with KNS/OCS, to show when there’s add-ons ready for an application.
KNSBackend: It’s being polished and adapted for new use-cases. First it used to focus on Plasma-centered assets, but we’ve worked towards making it possible to become a viable solution for Application add-ons as well. Furthermore it has been trimmed down to also provide fast startup while keeping its features.
QApt: The traditional QApt backend used in Kubuntu is now considered deprecated in favor of PackageKit, which I understand should be available properly on every GNU/Linux distribution, including Kubuntu. We kept it around because there’s been longstanding issues with PackageKit on Ubuntu, but I’m confident these will be solved soon.

Front End

We used to have many of them, they have now been reduced to two: Discover and the Notifier Plasmoid. This allows us to focus one GUI. Of course, you can still use Muon, Apper and Synaptic together with it, for more precise package management.

Regarding Discover, the main focus this year has been: performance, stability and Add-ons.

Performance: Mostly back-end work, and it has also benefited from improvements in KF5 and upstream Qt. Updating the dependencies will improve your Discover experience as well as that of other similar applications. Better usage of some model classes was also a nice improvement in some places.
Stability: We worked on making sure that things not only are sturdy but that the development process doesn’t get in the way of stability. To that end, I set up a testing framework so that changes are automatically tested, additionally to the manual tests the developers will do at some point.
Add-ons: One of the important parts of Discover, is to make sure the user is aware of the nice resources he has available. KNewStuff resources (mostly coming from kde-look and kde-files so far) have been available for a while, albeit mostly for Plasma enhancements. In this next release we allow these to extend applications themselves as well.

Future

Discover‘s future is Kirigami. We have already some work lined up (see the kirigami branch), we are pending some design work so that it shines, but the approach is already quite promising!

Also I’d like to start working on the Flatpak backend, if nobody beats me to it. 😀

Stay tuned!

Plasma Mobile SDK

27 July 2015 / apol / 5 Comments

Where are the giants?

When approaching this issue I had been thinking about the issue for a while. I had mainly 2 problems: I was rather frustrated with previous Linux-based systems so far and the one I liked didn’t really scale for us. One thing was clear: We had to stand on the shoulder of giants.

The first one to think about was the N9 SDK (and by extension N900). It used to have a scratchbox-based system that emulated the one on the phone. It was useful for testing the applications locally on the device (although I actually never used that), I think that this one had both cross-compilation toolchain and base system, as well as the host and it used QEmu if a host executable was run. It felt weird because it shoved you in a weird system and you had to pull your code in weird ways to fetch it. Otherwise it worked great. Afterwards, madde came. It’s what I was looking for really and played quite well with cmake, actually when I published the steps on how to develop for the N9 it’s what I used back then, but it probably was too late for it to become a thing I guess. Also many people weren’t too fond of it, as I learned after some time.
The Android NDK is the other I took into account. I don’t think it would be fair to compare anything we could do with the actual Android SDK, so I’ll limit myself to this one. This one ships the complete cross-compilation toolchain and runs native (similar to the BBX SDK, IIRC).

For the N9 approach, I would have had to concentrate on figuring out technologies that were long dead (and probably should remain). For the Android approach I found 2 big problems: We have to actually work on generating the actual binaries (which means, from any platform to a specific ubuntu-vivid-arm target) plus all the dependencies. This meant, creating a new distro, and we already had debian/ubuntu for that, let’s use debootstrap! Oh, wait…

Old school

For a start, I took what sebas already started, in fact. Using debootstrap to create a chroot jail that could cross-compile the projects into our platform. This started to prove feasible really soon, as 2 or 3 days after working on it (and after fixing some issues that kept arising, mostly on KF5 itself and packaging), I already started to output binaries that could be deployed on the device.

Problems:

My IDE is outside of the jail, so there isn’t much we can do to integrate at all (we can’t access the build directory, and most of the data in it isn’t too meaningful for the outside anyway). A solution would be to ship and run the IDE from within the SDK though.
You need to be root. Not only to generate the system, but also to run it.

New school

An idea I wanted to approach was docker. Everyone on the web world is shit-crazy about it and it’s deeply based on traditional Linux, so there’s quite in common already. Doing something similar to the deboostrap there was a piece of cake, and I managed to re-use the set up code I already had for the previous version.

Problems:

Also everything is inaccessible from the IDE
I’m less aware of the limitations I’ll find.

Still, this second approach feels lighter and it’s quite fun to investigate something new like that.

Tooling

It seems that the jailed systems are the way to go, at least for now, so the tools I’ve created so far assume that they live in the jail as well. So, what do we have?

createpkg: Makes it possible to create a deb package that can be sent to the device for testing. It’s much simpler than the simplest deb package ever, but it works. Much better than sending executables over, much better than learning how to package for Debian.
deploypkg: sends the deb file, installs it and starts the application.
click-get: Downloads a click file from the Ubuntu Store, it’s harder than you’d think.
kdev-debdeploy: Does it all, inside your good ol’ IDE.

To be done

Workflow: Figure out a way to deploy KDevelop within either jail, but then we’ll also be able to use kde-debdeploy, that does mostly the same as these tools, integrated on the IDE.
Emulation: Testing: QEmu + docker anyone?

Identities, I usually don’t stop being myself

23 April 2015 / apol / 1 Comment

One of the most interesting developments I’ve seen recently inside KDE is KAccounts (or Web Accounts, as it used to be called). It’s not even a KDE project, but a project Nokia started some years ago, I’m guessing that on MeeGo days.

Why do I care?

As a developer it’s always very important to know what resources you have available. The more you have, the richer the users’ experience will be. Resources are not only hardware but often just semantically-structured information. For example, KPeople helps us tell apart the contact list and offers us people instead or Solid, that turns the different ways of exposing the hardware information into something easily consumable by front-end applications.

Now we’re talking about identities. We don’t exclusively rely on local data anymore, I think that’s a fact nowadays (and even 5 years ago). Our disks are just another place where we store some of our data. KDE projects must be prepared to easily offer such workflows. One of the important parts to do it properly is authentication:

We need a list of available services we can use.
We don’t want our users requested identity authentication all the time.
We don’t want each application to implement the N authentications algorithms of the N different providers our users will eventually have.

Why do you care? (as a KDE software user)

First of all, you want your developers to have the best tools (GOTO: “Why do I care?”).

board meeting of @kdecommunity in progress pic.twitter.com/rIVojmuyFB

— Lydia Pintscher (@nightrose) April 12, 2015

There’s a more important issue to figure out, more ideological than technical: We ask service and software providers to use standard specifications to improve interoperability, but then in practice we are seldom leveraging it. The case-by-case set up burden makes it hard for users to have everything configured properly. An example for this is ownCloud integration. I know a couple of people running an instance, but they seldom integrate it in Dolphin, but even if they did they’d still need to integrate the rest of provided services, such as calendar, contacts, etc.
We want to tell our software what providers we have available, those providers will provide different services. The software should integrate as much as possible with those services.

How can I help?

Testing: There’s a lot going on, thorough testing and ideas is important. Both when it comes to making sure everything works as expected as well as what software should adopt KAccounts. It will already be available with KDE Applications 15.04.
Developing: Make sure your application of choice uses KAccounts to figure out the configured services. Here’s a good place to find documentation: API, and an example use-case.
Promotion: It’s important to reach out to service providers, make sure they know there’s such possibility and hopefully they can help us work better with their services (hey! by the book example of a win-win situation!).

Nowadays our computation experience is spread among different services and we need to be smart enough to understand how our users will adopt them and make it as transparent as possible.
AccountsSSO and KAccounts are a solid step forward in this direction, let’s get back in control of our data!

Communicating from Plasma 5

28 October 2014 / apol / 9 Comments

Porting KDE Telepathy to Qt 5 and Plasma 5

I started working on that port back in the last KDE Telepathy sprint in Barcelona last April. Back then, I started to work on it because I have been doing heavy usage of the KTp plasmoids back when using the KDE 4 Plasma series and I didn’t want to live without them. Back then, I only ported the minimum parts of ktp-common-internals so it would work with KF5, as well as the plasmoids. It was quite some work, but definitely worth it since I’ve been using them ever since, and it’s worked wonderfully.

Last week I started working on those ports again, this time trying to start get all of them ready for end-users, first step being starting to port the rest of modules. It’s worth mentioning how good the response has been, given that many people chipped in and gave some modules a go. It’s a bit weird to do this kind of porting in KTp, because there’s tons of little repositories to port rather than a big one, but I guess it’s kind of part of it’s beauty anyway… 😉

KPeople as a KDE Framework

KPeople is a Framework for fetching contacts from different sources (Telepathy, Akonadi, Facebook, etc) and unifying them into a same model,

An important part of making sure all of KTp works is ensuring that its dependencies are up to speed and this time the one I’d like to bring some light to is KPeople. The port is ready really, only depending on having some of its own dependencies from kdepimlibs in a releasable state, but it’s also quite in shape too. It’s a framework I’d really like to see shining in the next months.

Furthermore, I finally managed to find some time and get the automatic contact merging back on. This I started more than a year back and then Franck Arrecot worked to make some GUI interface for it, I think it’s quite interesting. Take a look into it if you think it’s interesting. 🙂

We need you!

Last but not least, there’s still lots to be done. I’d like to aim for a nice and clean release of KTp by the end of the year, ready to be shipped with Plasma 5.3 and the applications, if the maintainers allow so.

So if you’d like to help, you can take a look at this Kanban board we created and take the tasks you’d like.

Taking advantage of OpenGL from Plasma

4 August 2014 / apol / 12 Comments

I’m excited, and I hope you’ll be too.

David Edmundson and I have been working hard the last weeks. It’s not that we don’t usually work hard, but this time I’m really excited about it.

A bit of context: in Plasma an important part of the system drawing is painting frames (others are icons, images and the like). Those are in general the elements that are specified in the Plasma themes. These will be buttons, dialog backgrounds, line edit decorations, etc.

So far, to paint those we were assembling the full image in the CPU and then sending it over to OpenGL as a full texture, then we would do the composing of all the different frames, according to the information provided by QtQuick, through the Qt Scene Graph. There are 2 main problems in the current approach.

We were maintaining huge textures in memory. Every frame was completely stored in memory and gpu memory. Which means that the bigger the dialogs are, the more memory we consume, even though the texture is flat.
Every time we resize the frame, we have to re-assemble the frame in CPU memory and upload it again.

First: The 9-patch approach

First we made it possible to have the frames to be rendered by each different parts and assembled by the GPU. This wasn’t possible, because Plasma themes are quite complex, so now we have 2 different paths. If the theme element can take advantage of the optimization, it will use the new code, otherwise it will stay working beautifully on the former, thorough implementation [1].

Therefore, instead of rendering all the frame now we’ll be uploading 9 textures to the GPU, and let it either tile or stretch depending on the settings in the theme. This way:

we are uploading 9 tiny textures rather than a big texture.
when the frame is resized, we tell the nodes to resize and the GPU does the job [2].

Second: Caching the textures

Now everything was in place, we’d have many times the small 9 elements but we kept uploading them to the GPU over and over. It’s little textures, but it’s still better if we get to re-use what we already have. To do so, we’ve placed a little hash table that keeps track of the already created textures to re-use them. This way, we get to tell the Qt Scene Graph to use a texture that has already been uploaded rather than a new one. We’ve run some tests, here’s the result:

In PlasmaShell we get 342 miss and 126 hits, so roughly 25% of bandwidth and memory improvement
In KRunner we get 108 miss and 369 hits, so roughly 350% improvement on memory and bandwidth improvement.

Future, further work

Sadly enough, raw memory usage is still quite high, when running plasma shell on massif, we are still reported as most of the memory usage being in the GPU graphics card (or rather i965_dri.so), so we’ll have to dig it [3]. We’ve found some ways to improve this, for example by enforcing OpenGLES 2, but this requires Qt 5.4 which is due October. I implemented it nevertheless, and it works fine.

Being more precise, a big offender is using a wallpaper image. We’ve looked into it, the code looks fine, but then it makes a big difference, so big that I still don’t understand how it can be. A good suggestion if you’re testing Plasma 5 on a system low on memory, is to run it with the plain color wallpaper. We can save up to 30% of memory consumption, no kidding (it actually depends on who you ask, either massif, htop or ksysguard; but they all agree it’s a big deal). We’ve investigated a bit and found ways to improve the situation there, but if you are interested, feel free to join!

Finally, another problem with regards to memory consumption is QML. We make heavy usage of it and it shows memory-wise. We should see if we can adopt any optimization to stream-line our usage, but admittedly it’s much better than one would have expected.

Testing

If you want to give it a try, you can already find most of this in master, and it will be available from the next KDE Frameworks 5.1 release which will be available by the second week of August.

Hope you liked it, it was a great exercise to investigate all this! I learned a lot and gained quite some respect for the Qt Scene Graph and QML development teams. Keep rocking!

[1] More precisely, at the day, when there’s no hint-compose-over-border or mask-*-overlay elements

[2] an exception for it being (hint-stretch-borders and hint-tile-center hints, where we’ll have to re-render on resize it).

[3] David, Vishesh and I we all have Intel drivers, but I guess it’s a good card to test-case on, given how mainstream it is, currently.

Plasma Next: All for one, and one for all

30 June 2014 / apol / 3 Comments

I haven’t been directly involved in Plasma development in the past a lot, only since very recently, because of my job at BlueSystems. Ever since I started working on the Plasma Desktop Shell, I’ve had 2 important concepts in mind that I’ve tried to follow:

The desktop is the place people go when they want to be performant.
Let the user focus by offering simple concepts that just work.

So far it’s looking good, I’ve been using it on my system daily and I haven’t had many important problems. Interestingly enough, one of the things I like about Plasma 5 is how it doesn’t try to get you in a spaceship. It does what you expect a shell to do, we’ve focused on making sure this is done properly and that all the tools to extend it are there, in case you want to go crazy. But the Plasma Shell, Plasma is solid.

Going crazyEnhancing Plasma UX

I think we need to, we want to. We thrive on it. The reason we’re developing software is to blow your minds, our mind. On the other hand it’s harmful, it’s much easier to go crazy than to provide a meaningful set of polished features. And we want polished.

But we want features, I want to take advantage of our frameworks and integrate the technologies that drive our lives, everyday, more and more. That’s why I think we want to start working on the services and applications that will complete that Plasma experience that, in the end, will be slightly different for many of us. Because we’re not all the same.

Now let me list some technologies that I’d like to see grow and hopefully help push in the following months.

KPeople

If you think about it, the ways we communicate over the Internet today and the ways we did 10 or even 15 years ago are essentially the same: we still chat through test, audio and video; we still send e-mails and we still exchange files in unreasonably broken ways. On the other hand it feels different, I think mostly because of using many devices with different sizes.
We want our software to understand these concepts. Different people and even groups of people offer us very rich and colorful semantics we want to be able to embrace both from Plasma and applications.

Having the people around us easily accessible is very important to be performant while still remaining as a simple concept we all understand, we don’t talk to an e-mail account, we talk to a person; only in many different ways.

KDE Connect

If talking to others is important, talking to us is even more important. Everybody I know, works with his phone on the desk and some of them with a tablet in the bag. I don’t think it’s easy getting to be performant if we have to keep checking what’s up on different devices. Furthermore, there’s no technical reason for that, we have KDE Connect. It needs polishing, it needs love but it has huge potential.
One of the things I like the most about KDE Connect is that it’s really easy to adopt. You have it available today on Android (and therefore BBX, Jolla, Ubuntu Phone and a couple others that support android apps), it’s in the way to be on iOS and we have a library you can re-use to take it to your favorite platform, that is obviously supported by Qt 5.

There’s lots of barriers to break there, we want a cloud-based client so you don’t need to have all devices in the same room; we want to break the barrier and see it developed in those new platforms we would never expect to find them. Also we want you to explore with us and find the synchronization nirvana.

My Conclusion

Finding a balance between making something simple and solid, KISS style, and going creative doesn’t go well together, on the other hand Qt and Plasma offers us lots of flexibility, so we have ways to do so.

I decided to go with this Musketeers (or I thought) slogan because it depicts quite well how I see myself using my laptop in some time. Every time less about those little windows and more about aggregating my people and my self, through the different gadgets I carry.

Corollary

Last, but not least, as usual I’d like to remind you that want to help ensure all this happens in the best of the conditions, you can consider donating to the Randa fundraiser, where KDE will gather and come up with many tools that will render this possible, in the best of the conditions.