FreeSoftware to the fullest!

Category: Discover (Page 1 of 2)

What should the FOSS desktop systems feel like?

It’s always tempting to look outside at what people say about what you create. Beyond KDE’s community, the Linux community is diverse and, more noticeably, surrounded with loud voices who observe what we create and comment on it. This is a good thing, it means that we are making relevant things and that people care. It also means that there needs to be a shared understanding of what is at stake.

It’s a bit of a meme how any change breaks your workflow and, while there is a certain amount of truth about it, it might pose a challenge. In this blog post I’d like to explain some aspects of what it looks like from the creator point of view.

Workflow

I started thinking about how to have this discussion more in the open after having seen certain reactions to KDE Neon’s offline updates announcement.

Before proceeding, let me offer you some context on the offline updates front. We have allowed our desktops to roll updates at runtime since forever. That doesn’t mean it has always worked for everyone. There are certain corner cases that would choke an application or maybe even the Desktop Environment. Since it’s not fatal we’d let it pass. I only started looking into offline updates more closely when I saw that the PinePhone KDE edition (or rather the dev image we were running to develop it) would fail consistently every time as we updated due to changes internal within KWin.

Neon Offline updating

To have this discussion I’ll summon another meme of the Linux lands: “The year of the Linux Desktop“. It’s been a around for a while since, it vastly predates my involvement in free software but it seems to still be a thing. We have seen Linux being adopted in many spaces but it’s seemingly never been enough to silence the dreamers among us. Now allow me to be a bit blunt.

I’m not sure if that year will ever happen. Or it will be 2054 or 2022. Now, I’m sure of one thing: The day where billions (as in 10^9) of people wake up and start their work day, it won’t be the case that the first thing they do is to open a terminal and run sudo apt update, sudo pacman -Syu, sudo zypper dup or sudo dnf upgrade. Users will need to run a system where dependency problems are never an issue, where they can install applications easily and where they can’t break their systems.

When I, and I think most of us in KDE, put together a feature, it’s towards making it possible for the world to adopt Free Software. We need to have as a goal a future where people can use our systems. Our “Simple by default, powerful when needed” goes beyond “I can easily change to a dark widget theme”.

Now I understand we are not there yet. I understand that many of us have some habits that are hard to change. But when we tell the world that we expect the linux usage to go beyond the current user-base, you need to be open to things changing. Your personal systems should become more “unbreakable” even if you generally “break it” (as in taint the integrity) in small ways to make your life easier.

In the end, we the hackers, will always have ways to achieve what we need be it by using more DIY distros, using fancy tools or by patching the system call table and forcing an unexpected reboot.

Learning about our users

In a product like Plasma, knowing the kind of things our existing users care about and use sheds light on what needs polishing or improving. At the moment, the input we have is either the one from the loudest most involved people or outright bug reports, which lead to a confirmation bias.

What do our users like about Plasma? On which hardware do people use Plasma? Are we testing Plasma on the same kind of hardware Plasma is being used for?

Some time ago, Volker Krause started up the KUserFeedback framework with two main features. First, allowing to send information about application’s usage depending on certain users’ preferences and include mechanisms to ask users for feedback explicitly. This has been deployed into several products already, like GammaRay and Qt Creator, but we never adopted it in KDE software.

The first step has been to allow our users to tune how much information Plasma products should be telling KDE about the systems they run on.

This mechanism is only integrated into Plasma and Discover right now, but I’d like to extend this to others like System Settings and KWin in the future too.

Privacy

We very well understand how this is related to privacy. As you can see, we have been careful about only requesting information that is important for improving the software, and we are doing so while making sure this information is as unidentifiable and anonymous as possible.

In the end, I’d say we all want to see Free Software which is respectful of its users and that responds to people rather than the few of us working from a dark (or bright!) office.

In case you have any doubts, you can see KDE’s Applications Privacy Policy and specifically the Telemetry Policy.

Plasma 5.18

This will be coming in really soon in the next Plasma release early next February 2020. This is all opt-in, you will have to enable it. And please do so, let it be another way how you get to contribute to Free Software. 🙂

If you can’t find the module, please tell your distribution. The feature is very new and if the KUserFeedback framework isn’t present it won’t be built.

Reaching out

One of the activities that we have been promoting is joining conferences on topics that we’re interested in. Last September I joined two of them: the Libre Application Summit and EduCode.

Reaching out within the community

In the Linux community we’re portrayed as tribalistic quite often, there’s good reasons of that. Having been part of KDE day to day for years, I also must say that it’s clearly been blown out of proportion. There’s collaboration all over the place and we should celebrate when it happens. Sitting together and sharing visions is useful, which we did in the last Libre Application Summit in Denver.

Among others, we learned about Flatpak’s internals, elementary’s software distribution approach, fancy new ways of distributing linux operating systems and how some free software we have available on linux can be used by graphics designers and how they reach them. Of course, there were the KDE bits that Albert and I brought.

I would say that the ultimate goal for all this wasn’t exclusively to learn about it but to actually sit together and talk. Which we did and I’m looking forward to do so again next year, hopefully with the rest of communities working on desktop, applications and distribution.

Reaching out to users

It’s a completely different story, for sure, but it needs doing too. In this occasion we joined a conference full of Belgian and French teachers who are interested both in Free Software and having the best educational tools available for their students.

This is especially important for two main reasons: we get to explain to some of our most prominent stakeholders what our software does and why it’s great but also we get to see how they react and what they miss. Caring and listening to users is crucial to the health of any project.

I was tempted to upload another picture of the crew up there (Adriaan, Paul and myself) but it’s rather unflattering to say the least, so we’ll stick with Paul looking all smart. 🙂

Of course, these were only the conferences I attended the last few months, but there’s been several other conferences where KDE has joined, join the planet KDE to know more!

Tracking a QObject’s life

Why?

One of the interesting things about QML is that it leverages OOP property semantics of QObject to drive its declarative workflow.

How?

We attach into any QObject the developer requests and monitor it (and optionally all it’s children).

To gather the information we need, we will collect information for every property and connect to the property’s notification signal to see when it changes.

What?

This is the repository:https://phabricator.kde.org/source/kobjecttracking/.

This allows us to see:

  • Spurious property change notifications
  • Property changing bursts (i.e. same property changing values repeatedly in a short amount of time)
  • How a change in a value can have an effect on other properties

At the moment we have two ways of inspecting an application:
On one hand we have warnings that allow us know specific things and even add breakpoints to the sore points. The warnings at the moment look like this:
repeated value ScrollView_QMLTYPE_43(0x5648c6d97b50) width QVariant(double, 320) 8 times
repeated value Kirigami::BasicTheme(0x5648c6986ac0) backgroundColor QVariant(QColor, QColor(ARGB 1, 0.988235, 0.988235, 0.988235)) 11 times

Additionally, we have a timeline view output from tracking. You can see an example of plasmashell run here.

Future

An idea would be to integrate automatically ModelTest, so if a QAbstractItemModel is found, a ModelTest instance is attached that makes sure the model is true to its promises.

Another thing that bothers me is that we are forced to compile it into the application. If we could make it possible to have processes attached or start the application somewhat automatically (like GammaRay does, wink-wink) we would ease the adoption of these tools.

What do you think? Do you think it’s useful?
Feedback very welcome.

Snap in Discover and the GNU/Linux Desktop

Last week I attended a sprint with the Snap team and some other members of the community. One of the things we looked into was the Software Center story at depth so I thought it’s a good moment to give you an update.

Discover’s Snap Backend

Long due, some of you have already been using the testing version of it. During this sprint it was refactored to use the snapd-glib library that should simplify a bit the maintainership of this piece of software.
I’m aiming to having a stable snap back-end for Plasma 5.11.

AppStream

One of the reasons holding us back was the lack of AppStream support both in few spaces: getting proper information from the application, leveraging the appstream identifiers. This will allow snap software centers to have rich information ready for users to better choose their software.

My understanding is that the development of these features is well under way and should be available to us soon.

Desktop integration

One of the really cool things about Snap is how well it integrates with cloud/IoT stuff. While this makes it really powerful, us desktop users and developers have seen some things that will need tackling eventually. Things like styling, fonts, icons, etc. need to be properly represented in Snap and it’s good to see this coming together nicely.
These were all subjects that were discussed during the meeting, so do get your hopes high!

Discover more in 2017

With 2017 starting, we’re getting ready for the next Plasma 5.9 release and with it a new Discover release.

This will be a special release for two main reasons: further add-ons integration and Kirigami.

New Stuff

One thing pending for a long time was to actually better integrate the different parts of the system that can be integrated. To do so, Discover now will automatically import all knsrc files present on the system and offer them as categories.
We’ll be able to go beyond Plasmoids and Comics (!) and make it possible to explore: Plasma Look and Feel themes, cursors, icon themes, window manager add-ons and different application-specific resources.

This won’t have a big impact on Discover’s performance because the backend code was refactored to be able to have several backends loaded even without knowing all of the resources available. Queries are now asynchronous and parallel.

Discover KNS Addons

Kirigami

Kirigami was adopted in the previous release already, and this release will use Kirigami 2, the port to which did not require much work.

The most significant improvement is the inclusion of keyboard navigation, which was requested by several people and is now finally available. Do you hate it when you’re required to use the mouse? Rejoice!

Extra: Snappy support

It’s 2017, not all of the applications are coming from your distribution anymore. To start getting things in place for different software distribution sources I started working on a Snap backend, which allows us to manage applications coming from this system.
Some work will still be required and it won’t be included by default, since it doesn’t yet support AppStream (although we discussed it and it seems it will happen soon), but if you’re curious feel free to take a look and give your feedback!

GNU/Linux bundled application ramblings

It’s impressive how in the last few months (and especially the last few weeks) the discussion around bundled applications for the GNU/Linux Desktop has sparked.

It’s especially interesting because:

  • The problem is not new.
  • The solutions that have attempted to tackle the problem in the past have been ignored (both by us developers and by distributions).

The TLDR

First, let me try to subjectively summarize the problem: Historically, the resources we get in GNU/Linux come from the distributions. Anything: executables, libraries, icons, wallpapers, etc. There’s been alternatives to all of those, but none has flourished as a globally adopted solution.

This guarantees that everyone using a distribution will have access to the resources the distribution can offer. The more powerful the distribution is, the more we get. There’s limitations nevertheless, so some restrictions have to get in place. The ensemble of limitations and technologies adopted will effectively define the user’s experience.

This works. It has worked for years and, given the technology is in place, it could easily keep working. Like in most engineering solutions there’s drawbacks and properly addressing them can bear some goodness. It seems like now it’s the moment to review this situation. Let’s enumerate some of the problems we have nowadays:

  • We have users using really old versions of our software with issues we’ve solved in versions they can’t use.
  • It’s really hard for GNU/Linux users to get users to test unstable versions of our software.
  • We have users who want to use fresh versions of some software but not in the whole system.

There’s been many solutions to fix those, some easily come to mind: ArchLinux’s AUR (with yaourt), Ubuntu’s PPAs, big-tar application packages, OpenSuse’s OBS, and possibly others.

Far from showing the maturity of the Linux desktop, what this depicts is the deep fragmentation we’re into: we have come up with different solutions that break the established distribution paradigm by lowering the restrictions and considering the resources offered as unsupported (often tainting the whole system).

What has appeared recently is sandboxing. It’s especially interesting because by letting the users execute any binaries we’re increasing the exposition of their systems. Hence, jumping from our distributions’ nest into the lions. As always, sandboxing creates new challenges: It requires changes in applications (or frameworks) to adapt, often creating a user interaction fence (e.g. a popup asking if you let Kamoso access the webcam). For what it’s worth, that’s not new: Android does it, OS X does it, Windows does it (from the Store), Chrome OS does it, etc.

Now where are we?

We need to decide about GNU/Linux’s future. Or at least, we need to understand what Plasma users will have available. So far, most of the noise comes from the big players in the business trying to differentiate their products, meaning incompatible versions.

Without an agreed unified solution, we’ll have to assume we’ll end up having installed snappies, flatpaks, AppImages as well as applications from the distribution. Then it’s just a matter of:

  • Presenting it properly so that the user knows the risks taken by executing an application (!)
  • Make sure we don’t lose many features by sandboxing.

Still, one of the good things of this new approach is that it shouldn’t have to be necessary to have several people dedicated to build every single application and component. If the solution is to add 3 more solutions that will need dedicated people, we’re not really moving forward.

Building

As soon as we’ve decided how we want to work, then the interesting stuff needs to appear. If this is properly engineered, it can bring really interesting possibilities that now we hardly ever find:

  • Newer versions of applications on administered systems (e.g. universities).
  • Enabling stable distributions on professional environments.
  • Beta channels.
  • Binary application 3rd party extensions.
  • Provision of debug symbols (some distros don’t offer them).

To finish the fantastic post, a note for the dreamers:
How easier would all that be in a microkernel architecture?

We need you!

Of course this will be a long journey and we need your collaboration. This year in Randa we started working on all these problems in several different angles. It’s important for the KDE Community to have your support, so we can keep providing quality software. Consider donating, doesn’t need to be a lot, everything counts.

Discover in Plasma 5.7

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!

A special sprint at CERN

Plasma

I came to the sprint hoping I could iterate 2 issues I’ve had been trying to get sorted with Plasma for a while:

  1. Integration testing for plasmoids
  2. Discuss how to keep pushing Discover for the next releases both with Plasma and the VDG.

IMG_20160308_112502

The new testing infrastructure is in place and I hope I’ll get to merge soon this week. Feel free to peek: patch1 and patch2.
This is very important because it will allow us to make the testing of plasmoids systematic, to some extent, making it easier to develop plasmoids and containments while maintaining and increasing the delivered quality.

Regarding Discover, there’s lots of ideas. Definitely far more than we can materialize. For now, we’ll be delivering a much more polished experience for 5.6 both on the strictly technical side (better appstream and PackageKit integration, better use of QtQuick in some areas) as well as on the looks side, mainly thanks to Andrew and Thomas who keep pushing me whenever something is not entirely perfect, which is awesome.

Visual Design Group (VDG)

The first special thing was that there was a VDG sprint in parallel. It wasn’t VDG people who joined us, but an actual sprint. This was especially good because it allowed for a fluid back-and-forth of ideas. It’s especially important both to have some designers full of dreams kicking our asses from time to time, as well as some kind of pragmatism back to them so the good ideas can end up being part of our workflows.

Plasma + VDG

WikiToLearn

Another special thing about the sprint was having the WikiToLearn team over. It was their first actual sprint as well as first time we all met together in a KDE event. I think it worked great, despite being different communities in nature, it’s interesting to see how synergies kept happening. I’m sure there’s good space for collaboration and I’m looking forward to keep working together.

IMG_20160307_104326

LHC

Apparently they have a particle accelerator there. What?!

AppStream offers a Cross-Distribution identifier for applications

One of the problems we’ve historically had in the GNU/Linux world (and especially in KDE, since we’re cross-distribution) is that we’ve always had a hard time at explaining how to install our applications. Basically because it’s different on each distribution.

My first approach to this problem was creating Muon Discover but that’s clearly not enough because, in the end, we seldom look for new applications. Often they will be recommended on a blog post or forum and we’ll want to install it. But then, while recommending it, it will either be a vague “you should try KMail” or a “you should ‘apt-get install kmail’ or whatever applies to your distribution.

What I’m proposing today is to embrace AppStream at the level of URL handlers (for web browser integration). AppStream shows GNU/Linux distributions maturity by offering a solution by letting the upstream projects set the identifier in their appdata.xml file (among other things) and then let distributions name the package however they want, rather keeping to push different naming schemes down each other throats.

AppStream has been supported in Discover for over a year now (only for PackageKit so far) and, since introducing this feature is straightforward, I implemented it in master.
If somebody wants to give it a go, test master and click here: KMail

I think this will be beneficial not only for KDE but any project packaged on GNU/Linux distributions that have a presence on the web and need to find their way in users’ installations. This will of course be limited to getting the URL scheme adopted by our peers.

/me winks at Gnome Software and Ubuntu Software Center.

« Older posts

© 2024 TheBlindCow

Theme by Anders NorenUp ↑