If you're looking for an isolated and straightforward way to start contributing to KDE, you're in the right place. At KDE, we use fuzzing via oss-fuzz to try to ensure our libraries are robust against broken inputs. Here's how you can help us in this essential task.
What is Fuzzing?
Fuzzing involves feeding "random" [1] data into our code to check its robustness against invalid or unexpected inputs. This is crucial for ensuring the security and stability of applications that process data without direct user control.
Why is Fuzzing Important?
Imagine receiving an image via email, saving it to your disk, and opening it in Dolphin. This will make Dolphin create a thumbnail of the image. If the image is corrupted and our image plugin code isn't robust, the best-case scenario is that Dolphin crashes. In the worst case, it could lead to a security breach. Hence, fuzzing helps prevent such vulnerabilities.
How You Can Help:
We need to update the build of KDE libraries in oss-fuzz to use Qt6. This task could be challenging because it involves static compilation and ensuring the correct flags are passed for all compilation units.
Update the Dockerfile to download Qt from the dev branch and KDE Frameworks from the master branch.
Update build.sh Script:
Modify the build.sh script to compile Qt6 (this will be harder since it involves moving from qmake to cmake) and KDE Frameworks 6.
Check karchive_fuzzer.cc:
This file might need updates, but they should be relatively easy.
At the top of karchive_fuzzer.cc, you'll find a comment with the three commands that oss-fuzz runs. Use these to test the image building, fuzzer building, and running processes.
Need Help?
If you have questions or need assistance, please contact me at aacid@kde.org or ping me on Matrix at @tsdgeos:kde.org
Note:
[1] Smart fuzzing engines don't generate purely random data. They use semi-random and semi-smart techniques to efficiently find issues in the code.
Stopmotion
is a Free Open Source application to create stop-motion animations. It
helps you capture and edit the frames of your animation and export them
as a single file.
Direct
capture from webcams, MiniDV cameras, and DSLR cameras. It offers
onion-skinning, import images from disk, and time lapse photography.
Stopmotion supports multiple scenes, frame editing, basic sound track,
animation playback at different frame rates, and GIMP integration for
image. Movies can be exported to a file and to Cinelerra frame lists.
Technically, it is a C++ / Qt application with optional dependencies to camera capture libraries.
Changes in release 0.8.7
This release comes with no new features, but improvements to the project itself.
Changes
The project is now officially called to KDE Stopmotion. The former name Linux Stopmotion is no longer used.
Support for qmake has been removed. Use CMake instead.
Features
Port serialization to libarchive. libtar is abandoned. (thanks to Bastian Germann)
Bugfixes
The .sto files miss the tar trailer. (#16, thanks to Bastian Germann for providing a fix)
Improvements
Use pkg-config to find dependencies vorbisfile and xml2 (thanks to Barak Pearlmutter)
Remove code that relies on deprecations in Qt 5; this is a preparation to move to Qt 6.
Future plans
Transition from Qt 5 to version 6. I am stuck with my port asQAudioDeviceInfothat was dropped in Qt 6. I need some help to port Stopmotion to the new way to handle audio with Qt 6 / Qt Mulimedia.
We should integrate better to KDE's tech stack: Internationalization, using KDE libraries, update and reformat documentation.
Get involved!
If you are interested, give Stopmotion a try. Reach out to our mailing list stopmotion@kde.org or have a look into our project. Share your ideas or get involved!
I’m a heavy user of Firefox profiles. Apart from using different
profiles for different activities, I also have a few extra profiles that
all run in the Default activity.
This means that I need to have different icons shown in Plasma’s
panel in order to be able to easily differentiate which profile a window
belongs to.
Sure, I use the tasks applet which shows the window title instead of
the icon-only one (I prefer usability to minimalism), but still, it
isn’t enough as sometimes the active tab in a Firefox window might not
have the most informative title.
Plasma seems to rely on the application name and the window class
when choosing the icon it will show in the panel. Which means that, by
default, all Firefox instances end up having the same icon.
Librewolf with a custom profile icon
Fortunately, Firefox allows you to specify the window class it should
use through command line arguments.
firefox -P ProfileName --class WindowClassName
And, to connect a launcher to a specific window class, you just need
to add the following line to the .desktop file:
StartupWMClass=WindowClassName
So, in order to have a nicely supported Firefox profile, you can
create a launcher with a desktop file similar to the following:
It also works with Firefox derivatives such as Librewolf (which can
be seen in the screenshot above) and others.
Wayland
For Wayland users, a comment by John Kizer might be useful:
On Wayland, I’ve ended up just using KWin Window Rules (based on a
substring of the window title, and setting the desktop file name) in
combination with .desktop files that launch Firefox to the site in
question and have the desired icon associated.
EDIT: And another approach for Wayland by Christoph Martin:
There’s no need for messing around with window rules - at least not
for Firefox.
If you use the –main flag instead of the –class flag for the Firefox
invocation in your .desktop file, you should get the desired effect - at
least in the Icons-Only Task Manager. Note that StartupWMClass still
needs to match the value of the –main flag.
The above works on my machine, that is under Plasma 6.0.5 on the
Fedora 40 KDE spin.
Every 2 to 3 years KDE selects 3 goals that the whole community can focus on for the coming years. For the past 2 years we have focused on improving the accessibility of our applications, worked to make our software more sustainable and automated and improved a lot of processes to make developing software in KDE smoother. To learn more about these goals check out the KDE Goals page. We will wrap up these goals at Akademy in Würzburg later this year.
It is now time to figure out what the next goals should be. We are starting this today by opening the floor for proposals. This means you (yes you!) can campaign for something you and others want to work on over the next 2 years and rally the KDE community behind it. To give you some inspiration you can have a look at the complete list of goals we’ve had in previous years.
How does it work?
You (and a small group of others) can submit a proposal by opening a ticket on this Phabricator board. Copy the template into a new ticket and explain your idea. The template gives you a few hints to help you create a meaningful proposal. This process is open until July 5th. (On July 5th we will start the refinement stage, where others can further help you improve the proposal.)
Some things to keep in mind
The process is explicitly open to proposals from people who are not yet KDE contributors.
The process is explicitly open to everyone, not just developers.
We expect the champions of the goal to be the champions, not the only ones working on the goal. At the same time they will need to put in significant work to rally people around their goal.
What is different compared to previous editions?
We are tweaking the process a bit this time. If you’re familiar with the process from previous years here are the most important changes:
We are moving from an individual champion to a small team of champions. Each goal should have someone who can carry the vision of the goal forward, someone who can technically steer it and someone to promote it. Other setups are possible where it makes sense for the particular goal but a goal needs a small team. Don’t have a team yet? That’s ok. Submit a proposal and say what you need. We will try to help find others to join.
We are focusing the champion role more on driving the goal forward through others and less by doing all the work themselves.
We will work with the goal champions on fundraising for specific projects that support their goal.
What’s the timeline?
Starting today until July 5th: Propose goals and find team
July 5th to August 15th: Refine proposals together with the community (identify issues, remove blockers, sharpen the proposal, …)
August 15th to 31st: Voting on the proposed goals by active KDE contributors
September 6/7th: Selected goals are announced at Akademy
Still got questions?
If you still have questions you can ask them in various places:
In the office hour on June 14th at 7PM Berlin time. You can find the time in your timezone here. The meeting will happen on BigBlueButton.
I was keeping myself on Plasma 5.x until recently. I got so
accustomed to the Bismuth window tiling script for KWin that I couldn’t
imagine myself updating to Plasma 6.x where Bismuth doesn’t work.
Unfortunately (?), one of the recent Debian updates broke Bismuth in
Plasma 5.x as well, so I had nothing keeping me on the old version
anymore. I’m now (again) running the development version of (most) KDE
software.
Since the update, I managed to make the Qtile tiling window manager
work with Plasma to some extent. But the integration between Qtile and
Plasma I hacked was less than ideal, and I kept switching between KWin
which worked perfectly, as KWin does, but without tiling, and my
Frankenstein Qtile which didn’t work that well, but it had tiling.
Maybe I’ll write about it if I get back to hacking Qtile, but that
might not happen any time soon because…
Huge kudos to all who are involved in the rebirth, the script works
as well as it did with KWin 5.
Window decoration
The only thing missing was the simple ‘just a line around the window’
window decoration that Bismuth had.
KWin 6 and Krohnkite + Bismuth decoration
Now we have that as well, I’ve ported the original Bismuth window
decoration to KWin 6 (nothing huge, just a few tiny changes to make it
compile). The code, and the installation instructions are available on
github.
In addition to my larger projects in KDE and elsewhere,
I’ve been working on a number of small projects over the years.
Since these naturally are hard to find, I want to present each one here briefly.
Maybe you’ll find some of them useful.
MatePay
MatePay is a small payment system developed for the student hackerspace I’m part of, Spline.
It has a small built-in shop that we have been mostly using for the beverages that we provide in the space.
However it also features an API that applications can use to process payments with. We use that to run public printers in the University.
MatePay is based on a simple SQLite database, it only makes sense to use when trusting the party hosting it.
Mateprint
Mateprint is a printing web interface with a payment feature.
It can also print multiple copies and double-sided pages.
It is just a simple static executable written in Rust.
All the hard work is done by CUPS.
Rawqueued
Originally the public printers were all connected over the network, using HP network add-on cards.
Unfortunately just like the printers these are becoming really old (~30 years), and started dying regularly lately.
Since for some reason these cards are expensive I instead decided to replace them with Raspberry Pis. I wrote a small IPP server that just forwards the payload it receives to the printer, which is pretty much what the network cards did as well.
This setup is a bit simpler than maintaining cups filters on multiple devices, so the more complicated parts can all run on a central virtual machine.
In the University we have a departure board in one of the student managed rooms.
It is powered by the same code that also powers KDE Itinerary (KPublicTransport).
For the Spline room, we of course needed a SpaceAPI endpoint.
There is a small server that provides the SpaceAPI endpoint and an API to update whether the door is open or not.
The updates are sent by a daemon running on a Raspberry Pi.
classAA { public: virtualvoidprint(){ cout << "in class AA" << endl; }; };
classBB :public AA { public: voidprint(){ cout << "in class BB" << endl; }; };
voidtestDynamicCast(){ AA* a1 = new BB; // a1是A类型的指针指向一个B类型的对象 AA* a2 = new AA; // a2是A类型的指针指向一个A类型的对象
BB* b1, * b2, * b3, * b4;
b1 = dynamic_cast<BB*>(a1);// not null,向下转换成功,a1 之前指向的就是 B 类型的对象,所以可以转换成 B 类型的指针。 if (b1 == nullptr) cout << "b1 is null" << endl; else cout << "b1 is not null" << endl;
b2 = dynamic_cast<BB*>(a2);// null,向下转换失败 if (b2 == nullptr) cout << "b2 is null" << endl; else cout << "b2 is not null" << endl;
// 用 static_cast,Resharper C++ 会提示修改为 dynamic_cast b3 = static_cast<BB*>(a1);// not null if (b3 == nullptr) cout << "b3 is null" << endl; else cout << "b3 is not null" << endl;
b4 = static_cast<BB*>(a2);// not null if (b4 == nullptr) cout << "b4 is null" << endl; else cout << "b4 is not null" << endl;
a1->print();// in class BB a2->print();// in class AA
b1->print();// in class BB //b2->print(); // null 引发异常 b3->print();// in class BB b4->print();// in class AA }