Language Selection

English French German Italian Portuguese Spanish

Shaping the Future of KDE Frameworks

Filed under
Development
KDE

Already during this year’s Akademy we started discussing our strategies for a Qt 6 transition and created a giant work board of tasks for our next major release of Frameworks. Overall our goal is to keep API breakages to a minimum while still cleaning up some cruft that might have built up over the years. We kicked off the sprint Friday morning with discussions mostly around policies and guidelines.

First of all, we acknowledged that our current release model with monthly feature updates works well but found that we need to be more conscious about merging large changes too close to a release. Furthermore, the fact that there’s actually a “string freeze” before each release to give translators a chance to catch up seems not widely known. In general, the categorization of Frameworks into 3-4 tiers worked but we realized a more fine-grained set of tiers might be necessary.

When Frameworks 5 came out QML was still relatively new and its future unclear; now that it has proven itself, a key goal of Frameworks 6 is making its features more easily used in a widget-less environment. This means for instance removing and splitting out widget dependencies. Moreover, we want to apply a hacksaw to KDeclarative which has a lot of declarative wrappers for other Frameworks which are better supplied by the individual Frameworks themselves. Also, we want to have better separation between API classes and runtime services, so external users of an API don’t have to pay a build dependency price for something they then just talk to at runtime.

Read more

More in Tux Machines

XFS - 2019 Development Retrospective

We frequently hear two complaints lodged against XFS -- memory reclamation runs very slowly because XFS inode reclamation sometimes has to flush dirty inodes to disk; and deletions are slow because we charge all costs of freeing all the file's resources to the process deleting files. Dave Chinner and I have been collaborating this year and last on making those problems go away. Dave has been working on replacing the current inode memory reclaim code with a simpler LRU list and reorganizing the dirty inode flushing code so that inodes aren't handed to memory reclaim until the metadata log has finished flushing the inodes to disk. This should eliminate the complaints that slow IO gets in the way of reclaiming memory in other parts of the system. Meanwhile, I have been working on the deletion side of the equation by adding new states to the inode lifecycle. When a file is deleted, we can tag it as needing to have its resources freed, and move on. A background thread can free all those resources in bulk. Even better, on systems with a lot of IOPs available, these bulk frees can be done on a per-AG basis with multiple threads. Read more Also: Oracle Talks Up Recent Features For XFS + Some File-System Improvements On The Horizon

Review: OpenIndiana 2019.10 Hipster

For me, the conclusion after battling with OpenIndiana for a few weeks is quite simple: the operating system's aim is to "ensure the continued availability of an openly developed distribution based on OpenSolaris" and it clearly achieves that goal. However, it does very little beyond that modest aim, and the lack of documentation makes it difficult to use OpenIndiana for people unfamiliar with OpenSolaris and/or Solaris. My advice for Linux users like me is to take plenty of time to get familiar with the operating system. At times I found using OpenIndiana hugely frustrating but that was largely because things weren't working as I expected. I am fairly confident that I would have solved most of the issues I encountered if I had spent more time with OpenIndiana. Some issues may be show-stoppers, including OpenIndiana's struggle with connecting to wireless networks and the limited amount of applications that are available. Many of these issues can be solved though. One of the main struggles I faced was finding documentation. The best place to look for information appears to be Oracle's Solaris documentation. Unfortunately, OpenIndiana's Hipster Handbook is not much use. It is mostly populated with content placeholders and the section on web servers counts exactly two words: "Apache" and "nginx". Even new features, such as the "native and metadata encryption" for ZFS and an option to disable hyper-treading are not mentioned in the handbook. At times OpenIndiana felt like an operating system that belongs in a museum. The set-up is quite old-school, the theme looks very dated and everything felt sluggish; the system is slow to boot and launching applications always took just a little too long for my liking. OpenIndiana's stand-out features are also nothing new - they are what made OpenSolaris a powerful operating system a decade years ago. Yet, in the Linux world there aren't many distros - if any - that have something like the Time Slider. openSUSE comes close but, in my humble opinion, OpenIndiana's Time Slider is more advanced and easier to use than OpenSUSE's Snapper. I am hoping Linux will catch up when it comes to OpenIndiana's ZFS goodness. Ubuntu is working on integrating ZFS, and I for one hope that in time there will be a Time Slider in file managers such as GNOME Files and Dolphin. Read more

OpenWiFi Open-Source Linux-compatible WiFi Stack Runs on FPGA Hardware

WiFi is omnipresent on most connected hardware, and when it works it’s great, but when there are issues oftentimes they can not be solved because the firmware is a closed-source binary. Read more

Analyzing Cinnamon keyboard shortcuts

Hello yet again, once again! For those who are not acquainted with this series, I am in an endeavor to analyze keyboard shortcuts in most major DEs so that we, the KDE community, can decide on the best defaults for KDE Plasma. Last time I analyzed MATE, and before that, XFCE. This time we analyze Cinnamon, a non-keyboard-driven environment that quite surprised me. I didn’t recall it was the case (I’ve used Cinnamon as a replacement for Windows 7 for some time in an old machine), but Cinnamon is actually quite similar to Plasma. It has quite surprised me, but this will stay for another day. One thing of note I will do on my next post in the series will be breaking the order I’ve followed until now for which DE to analyze, which was the list I made on the Phabricator task which is being tracked in this blog series. This is so because we’re close to Plasma 5.18, which is an important milestone to KDE—it will be an LTS version which should likely ship with LTS Kubuntu. Thus, I’ll focus first on keyboard-driven environments and speed things up for quicker decision-making. Oh, and I’ve had my birthday on the 12th of December! As a treat to myself, I tweaked the blog a bit. Weirdly enough, if I schedule my posts correctly, this post should be up three days after my birthday, the next should be three days prior to christmas and the next should be three days prior to New Year’s eve! Read more