About a year ago I wrote about my gripes with Firefox not playing nicely with KDE Plasma Activities and how I created an Activity-aware Firefox hack/wrapper. While I was pretty happy with it back then and especially the 0.2 version, since then things have improved quite a bit.
First of all, it seems others found my solution useful as well and even started filing issues and contributing code. I am ever so grateful for that, as I was already at the limits of my shell scripting skills with the 0.2 version and Activity-aware Firefox would have never gotten as good as it is now, without the help of Cristian Le and Jarosław Czarniak!
Version 0.4.1 is now the first version I would consider ready for mass use and if you are also a heavy user of both Plasma’s Activities and Firefox, I would warmly recommend you try it out.
So what are the biggest notable changes since my last blog post about it that grew my 30-line “works for me” proof of concept into a much more mature 285-line script?
in general it is rewritten to be distro-agnostic and much safer and reliable to use
it includes interactive elements
dialog (including help) on first launch that assists with starting a new Profile, copying some info from either the default or template Profile, or migrating from the earliest versions (0.1 and 0.2)
dialog to clean up Profiles that are left over from deleted Activities
desktop notifications
dependency check
debug mode (activityfirefox +x)
names of Firefox Profiles now include the names of the respecfive Plasma Activities
In addition to that, we have equipped the repository to resemble a serious project.
It now includes both a very informativeREADME and a well-structuredCHANGELOG. We are using tags and releases to mark important points in the development. And last, but not least, the repository is REUSE-compliant, so licensing and copyright information is as good as it gets.
That said, you are warmly invited to visit Activity-aware Firefox’ GitLab repository, where you can read more about it, install and use it …and of course, help make it even better by contributing code, bug reports or ideas :)
UserBase is a wiki about all things KDE with a goal of presenting our users with helpful and up-to-date information. Sadly, we are some way from achieving this: While KDE developers are moving swiftly forwards producing amazing software our efforts to document this have been stalling.
At the recent Akademy, a week long gathering of KDE community members, we decided to do something about it. It is a big task, however, and we need your help! The team is small, but we hope it will grow and become a vibrant and friendly community.
Join the UserBase Team
If you want to join the effort to get UserBase in shape again, please get in touch. An easy way is to go to the talk page of the team page and introduce yourself. The Wiki Team Page itself is where we plan the task ahead. Currently the plan is very sketchy – feel free to add your ideas.
You can also ping me on IRC (claus_chr in #kde-wiki on Libera Chat) or on Matrix (claus_chr in #kde-www:kde.org), or leave a comment on my UserBase page. Or you can just dive right in: find a page that needs some love and start improving it.
How You Get an Account on UserBase
To edit pages on UserBase you need to make a KDE Identity account. (If you already have an KDE Identity account for some other purpose you don’t need a new account; just reuse the existing one.) Now you can log in to UserBase and start editing.
Calling functions from another thread with signals
When I started to work with multithreading in Qt, I did all thread communication
with signals and slots, because that was the only simple way I knew.
I called functions from another thread using additional signals.
If Manager runs on thread A you can’t just call action() of course when
you’re operating on thread B.
However, you can emit manager->actionRequested(parameter) and Qt will call
the connected slot (action()) on thread A using a
Qt::QueuedConnection.
This approach has two big issues though:
You need to create weird signals for every function you want to call from
another thread.
You can’t handle the results.
Now there are of course solutions to point 2, you can i.e. create another
requested-signal on the calling object and call back, but your code will get
much harder to understand.
It gets even worse if there are multiple places from where a function needs to
be called.
How do you know which callback to execute then?
I also knew about the old-variant of QMetaObject::invokeMethod which
essentially has the same result handling problem, but additionally isn’t even
checked at compile-time.
I always wanted a solution that would allow to execute a lambda with captured
variables as that would solve all of my issues.
At some point I had the idea to create one signal/slot pair with a
std::function<void()> parameter to do that, but it’s even easier.
Since Qt 5.10 there’s a new version of QMetaObject::invokeMethod() that can
do exactly what I needed.
autoparameter=QStringLiteral("Hello");QMetaObject::invokeMethod(otherThreadsObject,[=]{qDebug()<<"Hello from otherThreadsObject's thread"<<parameter;});
Note: You can’t use a QThread object as argument here, because
the QThread object itself lives in the thread where it has been created.
I personally don’t like the name QMetaObject::invokeMethod, so I added an
alias to my projects:
The result handling as a caller also works pretty well:
runOnThread(object,[this,object]{// on object's threadautovalue=object->action();runOnThread(this,[value](){// on caller's thread againqDebug()<<"Calculated result:"<<value;});});
One could only complain that all your code needs to be indented deeper each
time you call runOnThread().
However, that could potentially be solved using C++20 coroutines.
Both Plasma Mobile Gear 22.09 and Plasma 5.26 have now hit Manjaro ARMs unstable branch, so it's time to get some testing in before it gets to stable branch.
New Homescreen in Plasma 5.26
To make testing easier, we have created new images, based on our unstable branch, with these shiny new packages. You can find the links below.
We did have a few hiccups along the way. Namely a long standing bug on our end, prohibited the panels from starting. This was a configuration issue on our end, made visible by the update to Plasma 5.26, which we have now fixed.
New App Drawer in Plasma 5.26
Another small issue was with the Dialer. Functionality is still hit'n'miss, but in 22.09 there wass an issue where the dialer was not quite fullscreen. It started in fulscreen and then resized a little bit. Like below.
Plasma Dialer 22.09 not quite fullscreen
This was also recently fixed with a configuration update!
So please help test out these new packages, so we can have a fairly stable new Beta release soon!
I agree, I don’t get why Wikipedia gets bad reputation in school. I’m dismayed at then whatever bogus argument they have being used to push for using Google instead… it’s like, back in the days, asking pupils to not use the encyclopedia they maybe had at home and walk into the nearby pub to find information.
Very good list. It sets the bar very high! I know most people will fail on a few of those items. It’s fine this gives a good direction and something to aim for.
KDE is now evaluating Sentry, a crash tracking system.
Who can get access? Everyone with a KDE developer account.
But what is it?
Since forever we have used Bugzilla to manage crash reports but this has numerous challenges that haven’t made any improvements in at least 10 years:
Finding duplicates crashes is hard and in our case involves a human finding them
When debug symbols are missing we need to ask the user to recreate the problem, which is not always possible
Users need to worry about debug symbols (this is in part improved by the rise of debuginfod - yay!)
We have no easily consumed graphs on how prevalent a specific crash is, and by extension we have a hard time judging the importance
The user needs to actually write a report for us to learn of the crash (spoiler: most crashes never get this far)
…
All in all it’s a fairly dissatisfactory situation we are in currently. Enter Sentry.
Sentry is a purpose-built crash tracking system. It receives crash reports via API ingestion points and traces missing frames with the help of debuginfod, can detect duplicates automatically and thus show us particularly aggressive crashes, and much more. Best yet, it supports many different programming languages which allows us to not only improve the quality of our software but also our infrastructure services.
The current evaluation instance is already amazing and helped fix numerous problems, and the current setup is not even using all features yet and we have hampered rollout a bit: only git builds currently submit data. If all goes well and we find it to be amazing I hope we’ll eventually be able to roll this out to production releases.
Let’s look at a crash I’ve fixed recently.
Here’s what Sentry received from the user:
Not terribly useful. So with the power of debuginfod it turned it into this:
I then applied some brain power to create a fix and consequently the crash has disappeared, as we can see in this neat graphic here:
Here’s a complete crash information page from a recent infrastructure problem in our bugzilla bot:
This year, I had the amazing opportunity to attend KDE Akademy in person for the first time! The host city was Barcelona. It is my second time visiting the city but it was my first time to attend KDE Akademy. Actually it was my first KDE event.
For KDE friends who don't know me, I mainly contribute to openSUSE, GNOME, Nextcloud, ownCloud and GNU Health. I have fewer contributions to Fedora, Ubuntu and ONLYOFFICE and a few here and there to FOSS projects.
Question. Why did you attend KDE Akademy? Two were the reasons. The first and main reason was to see the organization of the conference from the inside, since my University will host the next KDE Akademy. The second reason was to "introduce" myself to the KDE community, since I contribute to other projects. Actually, I know a person from the KDE board but community is not only one person.
The only familiar person I could meet was openSUSE's community manager. Unfortunately he couldn't attend, so he asked me to represent openSUSE. The duties were to have a booth and present something openSUSE related for 3 minutes. I had an idea to propose my friend George to do his first presentation to an open source conference and start his open source journey. He was very excited and he did it.
Day 0
There was a welcome event on Friday for us, where attendees got to know each other. Unfortunately, my flight was delayed and I arrived too late to attend the event. So I stayed at the hotel and tried to rest for my first Akademy day. I felt like going to school.
Day 1
The first thing we had to do was set up our booth. Well, the only promo material we had was stickers. I think all geeks like stickers so it was the best gift for everyone. I love stickers, not only from openSUSE but from other projects as well.
During setting up the booth, I met the rest of the guys from the sponsors like Ubuntu, Fedora, Qt and Slim Book.
Full Steam ahead! :Seen how Plasma fits into the Steamdeck and what aspects of KDE made us the right choice for their new userbase
Food at the coference wasn't the best for my taste. Maybe it's me. But the most interesting part of the conference was the fact that I had the chance to meet realy important people, developers that changed my point of view on softare developement.
You can see the first day, Room 1 here:
Day 2
After having fun the first day, I was excited for the second day. The first reason was that George and I (actually only George) will have the sponsor talk and the second reason was that the fact that the organizers would announce the place of next year's Akademy. Of cource that place is Thessaloniki and my University.
Unfortunately I didn't have any team to join the next BoFs days. I had a small hope that we could setup the working environment for the next Akademy but that didn't happen.
We didn't join the trip to the mountain. We went to see the city. It was my second time and I skipped some sites.
I really loved my first KDE Akademy. I would like to thank KDE ev that sponsored my trip to attend the Akademy.
I have a lot of stuff to work here with the organizing committee. We are working to host you all next year.
This year, I had the amazing opportunity to attend Akademy in person (@ Barcelona) for the first time!
For context, I first started contributing to Plasma Mobile in 2020, right around when easily testable hardware (ex. PinePhone) was taking shape. I originally started with some contributions to some applications to learn Qt and C++, but have since then taken more responsibility with tasks from all around the software stack.
We first had a welcome event on Friday where attendees got to know each other. It was quite cool to finally be able to match usernames to faces, and finally meet the people I had been working with in-person.
I also met up with amazing people from the postmarketOS team! I had the chance to see a Fairphone 4 with the OS running Plasma Mobile smoothly, which was amazing.
I had a great start… I missed the first two hours of talks on the first day because I slept in.
Luckily, my talk, Plasma Mobile in 2022 with Bhushan was in the afternoon. Unfortunately, Bhushan was unable to come in-person this time around. Hopefully I will be able to meet him next year!
You can see our talk here (at around 5:21:00):
I attended quite a few interesting talks:
Konquering the World: Are We There Yet (Nate Graham) - The state of Plasma shipping with hardware
Full Steam Ahead! (David Edmundson) - Steam Deck with Plasma
Stop Crashing Already! (Harald Sitter) - Integrating Dr. Konqi with powerful tools for developers to find issues
Getting your application ready for KF6 (Nicolas Fella & Alexander Lohnau)
Asahi Linux (Hector Martin) - Information about the Asahi Linux project, how it came about
Push Notifications - Infrastructure (not just) for Plasma Mobile (Volker Krause) - Status of building the framework to have push notifications on Plasma (Mobile!)
Fedora, KDE, Kinoite, and Mobile (Neal Gompa) - Overview of Fedora shipping Plasma
… and there were many other cool shorter talks as well!
There were also people from Pine64 and Manjaro there that I met. It was really cool hearing about Pine64’s future plans for RISC V (coming soon!), as well as seeing some of the devices that Manjaro had running Plasma Mobile on (portable game console, mini tablet/netbook?).
This was my first time attending a BoF, as well as hosting one. We unfortunately had some trouble with audio, which made it hard to communicate with online attendees.
However, we did discuss the following topics:
Helping Bhushan do Plasma Mobile Gear releases since he does them himself at the moment
Moving some Plasma Mobile applications to KDE Gear due to limited changes
How to proceed with QtFeedback (vibrations stack) for Qt 6 as it is unmaintained
Possibility of switching to feedbackd (by Purism) from hfd-service instead
Plan is one last release of Plasma Mobile with KF 5 (5.27), before branches are made for Plasma 6
No large changes anticipated for Plasma Mobile 6
SHIFTphones and Fairphone can run pmOS with Plasma Mobile, perhaps we can open communication channels with them?
Manjaro was working with 2 tablet (?) vendors, they have positive reception and had a few suggestions
KDE PIM (Personal Information Management) refers to the KDE stack for applications like KMail, KOrganizer, Kalendar, etc.
Improving Akonadi for mobile devices was discussed, including the possibility to try using SQLite by default, which may improve resource consumption.
I had started working on a mail application called Raven for Plasma Mobile recently, and so it was also discussed how to better share code between it and other applications that use the Akonadi stack.
I attended a BoF about an upcoming project, Plasma Ink, which brings Plasma to e-ink devices. They can be useful for reading, taking notes, as well as simply being an enjoyable interface to write content.
This platform however needs special consideration for the way content is rendered, since e-ink devices typically have slow-refresh screens, and so animations as well as colours need to be adjusted to be as light as possible.
Pine64 has been developing the PineNote which can run Plasma Ink theoretically, I had the chance to try one and was quite impressed at the responsiveness for pen notetaking.
While I likely will not be very involved with the project since I am preoccupied with Plasma Mobile, I hope it continues forward!
I sat down with Aleix to really focus on trying to fix this issue, since he knows about KWin for more than me, though his PinePhone had not been working and so he couldn’t replicate it previously.
After hours of jumping around git commits of kscreenlocker (compiling it on device is painful), we realized that the issue was elsewhere in the stack. There is some sort of Wayland registry failure that occurs when kscreenlocker is started immediately after waking from suspend, which causes it to crash. We unfortunately did not have enough time to pinpoint the issue, but we do have some ways to move forward with investigating in the future. We suspect it may be related to when KWaylandServer was merged into KWin.
The last BoF I attended was about convergent forms, and how we can design forms that use a single codebase, but have designs that work for both mobile and desktop.
Currently, we have special components in kirigami-addons for mobile, but are not necessarily great on desktop.
What was decided was to create a new “FormLayout” component in Kirigami, which can take a set of instructions to build the form, and generates the necessary components to display properly on whichever platform it is running on.
Over the past two years I tried out a few different keyboards for fun.
I started with common form factors like TKL boards, went over 75% boards like the Q1 and then to a 60% HHKB.
For typing feel, the HHKB is really amazing, but unfortunately the programmable features of a stock HHKB board are very limited.
Now that I went down to 60%, I will give a more extreme keyboard a chance, the 40% Planck ortholinear keyboard.
This one is fully open-source, you can even produce your own PCBs and Co.
You find more or less all stuff freely at GitHub.
Given that the Plank designer funded QMK, too, naturally you can fully customize the Planck boards.
Unlike for my tries with the Q1, this time I just went the plain QMK route, without any UI like the closed VIA or the open VIAL.
The Planck board offers a nice platform for experiments, given the plain grid layer that allows really to freely shuffle all your keys and experiment with extreme layouts.
Yes, the paper on the left of the keyboard is a printout of the lower & raise keyboard layers.
My typing speed is still abysmal on that new layout and I guess I need to build as second one for at work, otherwise I will never get used to the layout if I swap daily between this and a HHKB.
Therefore, if you like to try such a board and are not a lot more experienced with switching between different layouts: you will need some time to get used to this.
Even just the removed row staggering is confusing the first few days.
As many readers of this blog are aware, openSUSE has been offering packages of git snapshots from KDE since quite a while. They are quite useful for those wiling to test, report bugs, and / or hack on the code, but also for those who want to see what’s brewing in KDE land (without touching their existing systems). However, a major drawback for non English speakers was the lack of translations.
What’s the problem with translations?
KDE translations are not hosted on the community’s git repositories, but are instead stored in KDE’s SVN server. The main reason they were not moved to git was to preserve the existing workflows of the translation teams (who might not be as technical as the actual hackers). Translations are then placed in tarballs at the times of betas / RCs / releases.
This unfortunately means that having a git checkout, like what the OBS does when building the unstable packages, will not carry any translations whatsoever. Worse, existing -lang packages for stable versions will raise dependency problems if present (because they require the exact same version of their corresponding binary paclage).
Also, since the KDE team tries to keep the same set of package defintions (spec files) between the stable and unstable OBS projects, this meant some extra complexity to take into account the fact that translations might or might not be there.
As far as I remember, since some time there was some tooling in KDE infrastructure to download translations at build time, but it was a big no-no for the OBS, as there is no network access during building for security reasons.
Two sides of a solution
This proved to be a problem also for KDE’s own release management. On September 2nd, KDE hacker Albert Astals Cid outlined a proposal to have an automated way to copy translations from SVN into their corresponding repository, with a series of scripts that would do so periodically.
After some discussion and once at Akademy, the switch was turned on October 2nd. This means that our git checkouts were getting translations!
Of course, some adjustments were needed: spec files in the KDE Unstable projects were not taking the presence of translations into account, and thus quite a number of builds were failing. krop, KDE team member extraordinaire, stepped in and fixed all the spec files. This in turn made him realize that some upstream KDE projects were not actually handling translations correctly in their CMake code, so he fixed them too.
Within a couple days, all KDE Unstable repositories (Frameworks, Applications and Extra) had translations enabled, where applicable. After many years, it became possible to test the latest KDE software and have it in your own language.
Do I need to do anything?
If you don’t have the language packages installed and you have installation of recommended packages enabled (the default), they should be installed automatically. If you have, like myself, forcibly installed the language packages from the stable repositories, you can force install the new ones (for example with zypper install -f <packagename>), or if you’re on Tumbleweed, accept to swap them when prompted (this occurs when a new stable version of KDE software is published in a snapshot). Or you can install them manually should you prefer to do so.
Should any issues with the packaging arise (e.g., missing dependencies, conflicts), please file a ticket on bugzilla.opensuse.org.
silver_hook
@silverhook:matrix.org
lnj42
