This blog will be used by the Release Team for communally maintained projects which need a release announcement.
KDE Frameworks, Plasma and KDE Gear will remain on kde.org. But individual releases of apps and libraries which get their own releases can be announced here.
If you have not been following this blog series, I made a wrapper for Firefox to be able to run different tabs (and more) in different KDE Plasma Activities.
Often a hurdle to using a piece of software is that it is not packaged for Linux distros.
Kudos to Aurélien Couderc (coucouf), who packaged already 0.4.1 for Debian and provided the patch to make it easier to package to different distros.
But while large, Debian- and Arch-based distros are just a subset of all available FOSS operating systems that KDE Plasma and Firefox run on. If someone were to put it on Open Build Service to cover also RPM-based and other distros, that would be a great boon!
Contributions welcome, as I am reaching the limit of my skills here.
hook out → server migration successful – more on that some other day
on: # run automatically every 24 hours schedule: -cron:"0 */24 * * *" # allows to manually run the job at any time workflow_dispatch: # run on every push on the master branch push: branches: -main
jobs: generate: runs-on:ubuntu-latest timeout-minutes:10 steps: # generates a snake game from a github user (<github_user_name>) contributions graph, output a svg animation at <svg_out_path> -name:generategithub-contribution-grid-snake.svg uses:Platane/snk/svg-only@v3 with: github_user_name:${{github.repository_owner}} outputs:| dist/github-contribution-grid-snake.svg dist/github-contribution-grid-snake-dark.svg?palette=github-dark env: GITHUB_TOKEN:${{secrets.GITHUB_TOKEN}} # push the content of <build_dir> to a branch # the content will be available at https://raw.githubusercontent.com/<github_user>/<repository>/<target_branch>/<file> , or as github page -name:pushgithub-contribution-grid-snake.svgtotheoutputbranch uses:crazy-max/ghaction-github-pages@v3.1.0 with: target_branch:output build_dir:dist env: GITHUB_TOKEN:${{secrets.GITHUB_TOKEN}}
classPerson { public: //Person(int a,int b,int c) //{ //m_A=a;m_B=b;m_C=c; //} Person(int a,int b,int c):m_A(a),m_B(b),m_C(c) { } int m_A; int m_B; int m_C; } void test { Person p; }
Person p3=p1.operator+(p2); 简化为 Person p3=p1+p2; classPerson { public: // Person operator+(Person &p) // { // Person temp; // temp.m_A=this->m_A+p.m_A; // temp.m_B=this->m_B+p.m_B; // return temp; // } //本质上的调用是 Person p3=p1.operator+(p2); int m_A; int m_B; };
Person operator+(Person &p1,Person &p2)//本质上调用是Person p3=operator+(p2,p1); { Person temp; temp.m_A=p1.m_A+p2.m_A; temp.m_B=p1.m_B+p2.m_B; return temp; }
#include<dirent.h> DIR * opendir(constchar * dirpath); Returns directory stream handlc,or NULL on error
readdir
readdir()函数从一个目录流中读取连续的条目.
1 2 3
#include<dirent.h> struct dirent *readdir(DIR * dirp); Returns pointer to a statically allocated structure describing next directory entry,or NULL on end-of-directory or error
KDE got accepted as a mentoring organization for Google Summer of Code 2024! Are you thinking about getting involved into KDE development? Check out the cool ideas KDE devs came up, they showcase what can be achieved by taking part as a student in GSoC. How to start? How to get involved? How to make an impression that will help your application?
Prerequisites
You like KDE, you like us as a community, you can follow our philosophy, you like our product (a desktop or at least an specific application), and you resonate with our tech stack (C++, Qt, CMake).
Grab some code from our GitLab, clone a repository and build it locally. This sounds easy. For first-timers it is not easy. Reach out for help in case you struggle.
Run your self-built software. Now you can explore the joy of developing KDE.
You do not need an idea, at least not yet. Give it some time.
Get involved
Try getting involved. Usually it is not easy to fix bugs of implement a feature request from KDE bugtracking system. Some are hard to fix. Others need debates of future directions or best ways to get things done.
I propose you start looking for other opportunities:
Fix compiler warnings. Compilers analyze the code and as a result they might warn you. This can have various reasons like bad coding practice, code that is difficult to read and might easily be misread by humans, code with bad performance, bug-prone constructs.
Fix deprecation warnings. KDE, Qt, and every software evolves. Old interfaces are replaced by newer ones. The old ones are not directly thrown away, but deprecated. The deprecation warning reminds the developer to migrate from the old to the new interface. Some deprecations are trivial to fix, others require ample code changes.
Fix findings of static analyzers and linters. These are tools that analyze code more thorough compared to a compiler for the price of a longer runtime. They offer great hints for but are prone to false-positives (wrong warnings). Good tools for KDE are Cppcheck, Clazy and qmllint.
Fix crash bugs. Crashes often occur when the code contains memory issues. Examples are using objects that were deleted, accessing arrays out of bounds, de-referencing null pointers. Tools like a good debugger, Valgrind, and AddressSanitizer (and its cousins MemorySanitizer and UndefinedBehaviorSanitizer) help to localize the problem. Crashes are more difficult to understand and fix compared to warnings for tools.
Try to work for fixes of one to ten cases. More makes reviewing harder. Create a pull request and wait for feedback.
Rationale
Why do I think these areas are good to start working? The maintainer might reject your pull request. This can always happen. Compared to implementing a whole new feature, the amount of work you invested is limited.
Once you have an idea for GSoC and write your application, you can point to your pull requests as proof of work. Maintainers see your involvement, they see how you interact, and you get an early sense whether you like the contributing experience or not.
Even in the case that you do not want to become an GSoC student, you improved KDE a tiny little bit. Great feeling, isn't it?
Word of warning
Not everybody deem warnings worth to be fixed -- in general or in specific cases. You will learn what kind of warnings getting fixed are welcome. I already wrote a blog post about my experiences with fixing some Cppcheck in Kile.
It’s February already, and as expected I didn’t have too much time on my hands this month. I have some exciting related news though:
KDE Megarelease 6
If you somehow haven’t heard, a bunch of KDE 6-related stuff released yesterday! I highly recommend looking at the very nice announcement Carl and the rest of the KDE Promo team put together, it looks so good. Some of my changes in KCMs, Kiten, UnifiedPush support in Tokodon & NeoChat, PlasmaTube, and Tokodon are showcased there 🤩 One of my favorite changes is probably in KWin and the Wayland session, it’s near-perfect on my machine now.
NLnet Grant
For a while now, people have been asking about funding work on important Wayland features for artists and people who depend on accessibility features. We have been turning down offers from individual fundraisers, because behind the scenes my employer arranged a grant us to work on this task from NLnet! “Us” here means me and Nicolas Fella. I hope to begin in early April.
Tokodon
[Feature]
I changed the thread visuals to improve the readability of replies. Note that it’s only one level deep, but even with that limitation I find it to be way better than it was before!
[24.05]
[Feature]
Tokodon now warns if replies may be hidden from your server and suggests to open the original post in your web browser. This isn’t the greatest solution yet, eventually I want a way to load the post on the original server within Tokodon. This is a good start though, instead of showing nothing.
[24.05]