Skip to content

Wednesday, 14 August 2024

After a long wait, Plasma Dialer 24.08 is finally out. This released is based on Qt6 and contains 17 months of bug fixing as well as small improvements all other the place.

Screenshot of the dialer page

Screenshot of the empty call history

Packager Section

You can find the package on download.kde.org and it has been signed with my Carl's GPG key.

Tuesday, 13 August 2024

This post is written on behalf of the LabPlot team. It’s different compared to what we usually publish on our homepage but we feel we need to share this story with our community.

Introduction

You might already know this, but finalizing a release for a project with the complexity and scope like that of LabPlot can be hard and exhausting. After our latest recent 2.11 release, we decided to take a short break and distance ourselves from coding and take care of other non-coding related tasks, like discussions around the NLnet grant for LabPlot, our ongoing GSoC projects, the roadmap for the next release, improving our documentation, the gallery on the homepage and the article about LabPlot on Wikipedia. Don’t worry, we’re already back to coding and working on new features for the next release 🙂

The article about LabPlot on Wikipedia (we are talking about the ‘EN’ version here, but the situation is similar for other languages) was completely outdated and still containing the information about LabPlot1 from Qt3/KDE3 times. The article became largely wrong with the introduction of LabPlot2 and with further developments in recent years. Among other things, the feature set described on Wikipedia was very far from being correct and complete in comparison to the description for other applications of its type.

The current situation was clear for us and it was also evident what needed to be done. Let’s go ahead and improve the article, we thought. Hey! Being able to contribute and to share your knowledge with everybody is the advantage of Wikipedia, right? Easier said than done…

Key Takeaways

But before we begin:

  • Wikipedia itself points out that the purpose of Wikipedia is to benefit readers by acting as a comprehensive compendium that contains information on all branches of knowledge. For this purpose, as it is clearly stated on Wikipedia, “Wikipedia has many policies or what many consider “rules”. Instead of following every rule, it is acceptable to use common sense as you go about editing. Being too wrapped up in rules can cause a loss of perspective, so there are times when it is better to ignore a rule. Even if a contribution “violates” the precise wording of a rule, it might still be a good contribution.” Link: Use common sense.
  • According to Wikipedia there is no need to read any policy or guideline pages to start editing. The five pillars of Wikipedia are a popular summary of the most important principles. And the three of the pillars are formulated as follows: 1. Wikipedia is free content that anyone can use, edit, and distribute. 2. Wikipedia’s editors should treat each other with respect and civility. 3. Wikipedia has no firm rules. And If a rule prevents you from improving or maintaining Wikipedia, ignore it.
  • In this Wikipedia’s article on https://en.wikipedia.org/wiki/Wikipedia:Dispute_resolution it is stated that once sustained discussion begins, productively participating in it is a priority. Editors should focus on article content during discussions; comment on content, not the contributor. And when an editor finds a passage in an article that is biased, inaccurate, or unsourced the best practice is to improve it rather than deleting salvageable text.
  • I fully acknowledge these common-sense principles. I accept the fact that some phrases of the original version of the new content added by Dariusz, another core member of the LabPlot team, might have possibly infringed a less general rule on Wikipedia, and that’s why he asked for a constructive assistance, to no effect.
  • I can also accept the reality and the existence of different users with the various amount of expertise, goodwill and power. The worst case are people contributing in a subversive manner over long time to such an open project to achieve more power and authority and completely different and evil goals later, and this can also be related to users with granted power. See the recent XZ Utils backdoor. I also accept the fact that the amount of work behind the scenes on Wikipedia requires the usage of automated mechanisms and bots (“Meet the ‘bots’ that edit Wikipedia”).
  • However, I cannot accept the fact that the quality of knowledge on Wikipedia can be seriously undermined by power users heavily using algorithms and blindly enforcing some subjectively selected, narrow rules against the general principles outlined above, and at the same time not being open to any constructive discussion. The fact that complete content and comments are censored and removed by users with granted power or by their (semi-)automated tools, which deceives the reader and distorts the history of the discussion, is definitely not acceptable. And this is apparently not an exception, see the links here, here and here and many other similar discussions on the internet.

Keep the above in mind while you read what happened.

The incident I want to share with you is certainly not about LabPlot and its team. It’s about the negative impact of blindly invoking algorithms or quoting a single rule by Wikipedia’s users with granted power on the overall quality of the information stored on Wikipedia. As Dariusz noticed, in economics there is the observation that “bad money” drives out the “good money” from the market (Gresham’s Law “bad money drives out good”). We wonder whether the actions of the entities like MrOllie, some of which are described in the next parts of the article, are enough to justify the introduction of a new law for Wikipedia “bad information drives out good”?

Chain of events

In order to make the content correct and to provide an up-to-date description of the project, similar to the articles for other projects mentioned e.g. on https://en.wikipedia.org/wiki/List_of_information_graphics_software, Dariusz did multiple edits of the article over the course of two days using his Wikipedia account ‘Dlaska’. Very soon after that, the entity MrOllie became aware of his changes and reverted them completely with the suggestion that it was a promotional rewrite. Then, a “user talk” with Dariusz was initiated by MrOllie:

We are all volunteers, having no benefit other than satisfaction from developing LabPlot. But sticking to the principle of intellectual honesty, Dariusz himself fully disclosed to MrOllie that he is a LabPlot team member that felt obliged to step in to correct misleading information in the article and to make the content more complete and up-to-date, because no one has done it for a long time. Unable to get any suggestions from MrOllie despite Dariusz’ requests, Dariusz removed any phrases that could even potentially have promotional qualities (e.g. rename “strongly support” to “support”). Unfortunately, even this had no effect on the actions of MrOllie, resulting in the revert of the new content.

In parallel, I joined these activities and reverted the revert done by MrOllie and provided some explanations for this step. Another “user talk” with me (I don’t have any account, you see my IP address here) was initiated by MrOllie:

After multiple back-and-forth reverts, my IP was blocked and a “Conflict of Interest on the Noticeboard” was raised by MrOllie where he quickly got the support from his peers on Wikipedia. Dariusz’ comment didn’t change anything in the overall situation:

In parallel, more seasoned Wikipedia users jumped on the bandwagon and started ‘editing’ the article by first blindly reverting the article to the version containing potentially promotional content and then removing even more and more content and references with arguments that, in our perception, didn’t make sense arguing with anymore. Any discussion seemed completely ineffective. After most of the content had been removed from the article, to the point that the new version was more deprived of content than the old version, the user Smartse added a notability tag which was later turned into a notification box to the article stating this article “may not meet Wikipedia’s general notability guideline.”. Notability is a test used by editors to decide whether a given topic warrants its own article. So in our perception this could be interpreted as a threat of removing the article completely. The size and severity of the problem we were confronted with was already obvious at this point.

After my IP was unblocked (or maybe because I just got a new IP from my ISP), I was able to reply on this noticeboard. Since I was already foreseeing it’s going to be deleted, I took a screenshot (this is also the reason why I did screenshots for all other events):

Practically immediately my reply, red-highlighted above, was deleted without any comment or note and this is how this thread looks like afterwards:

Fortunately, Dariusz, who has an account in Wikipedia, got the notification about my added reply via email:

and after clicking within seconds on the link in the email he was informed that the comment might have been deleted, and it sure was, right after it had been added.

Immediately after this, another notification box with “A major contributor to this article appears to have a close connection with its subject.” was added to the article:

and my new IP was blocked for “abusing multiple accounts” and using them for “illegitimate reasons”:

After all these deletions, see the full history of changes

This is how the article looks like in its “final version”:

In retrospect

What seems to have happened here looks like a well coordinated or even (semi-) automated chain of events with a pre-defined replies, arguments and actions. MrOllie stands out for the incredible diligence and regularity of his activity. The chart below shows the number of edits he has made by day of the week and hour (in local time), from 2008 to the present (source of the chart: https://xtools.wmcloud.org):

Also, over 75% of MrOllie’s edits are done in a semi-automated way with the help of tools on Wikipedia like Twinkle. So, this account functions like a programmed algorithm or somebody who is heavily relying on them.

Seeing no reasonable chance of correcting this situation in the context of being deprived of the right to effectively discuss the matters with entities like MrOllie, we gave up on our initial idea to improve the article.

What’s next?

After reading more on this subject we realized that this problem is not new, but apparently it is not common knowledge either. Completely independent of who or what censored us – AI bots (is AI already winning over us?), good or bad editors etc. – trusting Wikipedia now is much harder than before. Still, the question remains about what to do next.

We can completely give up the idea of contributing to this platform and rather focus on other channels like our homepage and other online resources in the KDE and free world (Mastodon, etc) and provide more and more useful information.

Alternatively, we can ask for support from other people with more experience in editing and maybe even with more authority on Wikipedia to help us to get a reasonable description of the project on Wikipedia to the benefit of Wikipedia’s readers and LabPlot’s users.

Thoughts?

Links

For the sake of completeness and of easier usage, here are the links mentioned in my reply that were deleted:

Note, for the first two links above, the original posts in the Wikipedia related channels on Reddit about the same MrOllie account on Wikipedia were deleted, shame on those who think evil of this. The comments are still available, though, and the reader can get at least an idea about the original content of those posts.

Edit

We added a short post about the article to r/wikipedia on Reddit, but it was removed by the moderators just 2 hours later, without any comment.

If, after reading this article, you think MrOllie and his counterparts are capable of correcting their own actions, take a look at the exchange below. It’s also an indication of what the future may hold for the LabPlot article on Wikipedia… Source: https://en.wikipedia.org/w/index.php?title=User_talk:MrOllie&oldid=1240636433


Update (20.08.2024)

We’ve been informed that a Wikipedia’s editor (Smartse) has today nominated the article about LabPlot for deletion, so before making any hasty, not to say retaliative, decisions, we encourage Wikipedia editors to reach a sensible “consensus” in the context of information published on these websites:

The last three links refer to Wikipedia’s articles about other applications similar to LabPlot. As far as we know, none of them have been nominated for deletion. In the meantime the article has been given a “protected” status.

Update (21.08.2024)

So far we have provided a list of nearly 50 research papers from various scientific fields that show that LabPlot has been used for research and teaching purposes. It would be unreasonable to expect researchers dealing with domain problems to devote a significant part of their research papers to describing LabPlot. In contrast, the following article is devoted entirely to LabPlot. The professors Williams Morales González and Jesús Eleuterio Hernández-Ruíz described the program’s functionality and usage in detail [1]. This fits into the Wikipedia’s General notability guideline:

  • “A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject.”
  • “Sources do not have to be written in English” and “there is no fixed number of sources required.”
  • “Notability is based on the existence of suitable sources, not on the state of sourcing in an article.”

Below is a (semi-)automatic translation of the authors’ conclusions:

The experiences of the professors of the Experimental Physics group of the UCLV Physics program in the use of LabPlot as a tool for the analytical and graphical processing of experimental data were presented.

LabPlot is a free, open source, multiplatform software with KDE desktop design and similar characteristics to Origin. It is intended for interactive analysis of experimental data and includes a wide variety of operations for analytical and graphical data processing, including linear and nonlinear fitting and data extraction from external plots, without the need for licensed software.

LabPlot can be used as a tool for experimental data processing, not only in Experimental Physics, but also in the scientific work developed by students from the second year of the course and culminating with the diploma work.

Does this information have any real relevance to Wikipedia editors? Time will tell.

[1] Williams Morales González. Jesús Eleuterio Hernández-Ruíz. 2022. Experiencias en el uso del software LabPlot en el procesamiento analítico y gráfico de datos experimentales. Conference: VII Taller de Enseñanza de la Física At: Universidad de Oriente, Santiago de Cuba. https://www.researchgate.net/publication/361586279_Experiencias_en_el_uso_del_software_LabPlot_en_el_procesamiento_analitico_y_grafico_de_datos_experimentales.

I want to thank you Dariusz for his contributions to this article.

Sunday, 11 August 2024

I’ve realized that it’s been nearly a month since the last update about my GSoC project, so it’s time to publish a new one.

I’ve been upstreaming the Python bindings to their corresponding repositories and addressing the comments. Many thanks to Nico, Christophe, Volker, Ben and Carl (my mentor) for their comments! The CMake part has improved a lot and it’s almost ready to be merged. CI support should be ready for FreeBSD and Linux. We can add support for Windows if people are interested.

I’ll probably write a tutorial on how to add Python bindings to a library next week.

Saturday, 10 August 2024

Most of the time programmers do not write new code. Instead, they read, try to understand,  extend, and fix bugs in existing code. While some parts of KDE are pretty new and follow modern standards, many parts are more then two decades old -- following obsolete coding principles, using outdated ways of solving problems, and having additions from several persons with different styles. Often when we read code, we immediately spot things we could improve.

Kent Beck's approach is applying a series of small tidyings that leads to structural change and an overall better software design. In his new book Tidy First? he describes his idea in three parts: Tidyings, how to manage tidyings, and software design theory.

In the first part the author introduces generic tidyings like dead code removal, moving declaration and initialization together, introducing new interfaces, or explicit parameters. Most proposals are not new, but it is a good reminder to follow them and fix these things wherever you come across them in code you are working with. After reading the first part, I felt motivated to create some tidying commits right away. For KDE more specific tidying could be added: Fix deprecation warnings from Qt and KF, replace C-style code by C++, use modern C++ (range-base for loop, initialization lists), fix compiler warnings.

The second part gives hints on how to organize and commit tidyings. Separate tidyings from new features or behavioral changes. Find a balance between asking for review of your tidyings too often or with too extensive reviews.

In the third part Kent Beck offers some basic ideas from software design, especially future options and code coupling.

The book is worth reading for both commercial and open-source developers. Both are facing similar issues. Open-source developers are not worrying about costs, but precious spare time dedicated to coding for their pet project. Every projects has bit rot and profits from regular tidyings by their developers.

People interested in software design will recognize the ideas from classic books like Structured Design or Refactoring: Improving the Design of Existing Code. Nevertheless, Tidy First? makes the knowledge easily accessible. Most chapters are only one to three pages long and the book stays below a hundred pages.

This is the first book of a planned series of small books. Kent Beck develops his ideas in his blog (partially pay-walled) and discusses his views with his readers. Some blog post make it into Kevin's weekly web reviews.

Friday, 9 August 2024

Let’s go for my web review for the week 2024-32.


A New Type of Neural Network Is More Interpretable - IEEE Spectrum

Tags: tech, ai, machine-learning, neural-networks, physics

Exciting new type of neural networks. There are limits to use them at large scale for now. Still, they have very interesting properties like the interpretability. And also, they tend to give similar performance to traditional neural networks for a smaller size.

https://spectrum.ieee.org/kan-neural-network


What do people really ask chatbots? It’s a lot of sex and homework

Tags: tech, ai, gpt

If you’re wondering what people do with chat bots, there are some clues here.

https://www.washingtonpost.com/technology/2024/08/04/chatgpt-use-real-ai-chatbot-conversations/


Judge rules that Google ‘is a monopolist’ in US antitrust case - The Verge

Tags: tech, monopoly, law

Looks like the US Department of Justice is back pushing for antitrust trials. This is likely a good thing, will it go all the way to breaking down some of the big tech companies? I doubt it but it’d probably be welcome.

https://www.theverge.com/2024/8/5/24155520/judge-rules-on-us-doj-v-google-antitrust-search-suit


Google Search speculation

Tags: tech, google, mozilla, law

Interesting guesses at what could change with the Google ruling. It doesn’t look too good for Mozilla.

https://micro.webology.dev/2024/08/06/google-search-speculation.html


Y’all are sleeping on HTTP/3

Tags: tech, quic, http, networking

Clearly there’s a silent transition going on. It’s not necessarily bad that it’s on-going without making too much noise.

https://kmcd.dev/posts/yall-are-sleeping-on-http3/


How to Get or Create in PostgreSQL

Tags: tech, databases, postgresql

Definitely not as simple as it sounds. The devil is once again in the details.

https://hakibenita.com/postgresql-get-or-create


Go debug your core dumps somewhere else

Tags: tech, debugging

You need to understand how core dumps work? This article is for you.

https://trace.yshui.dev/2024-08-copy-core-dumps.html


Code auditing productivity multiplier.

Tags: tech, c++, tools

Looks like an interesting tool for indexing and querying C++ code.

https://github.com/trailofbits/multiplier?tab=readme-ov-file


The difference between undefined behavior and ill-formed C++ programs

Tags: tech, programming, c++, safety

This is a very important distinction to keep in mind. It’s one of those source of bad mistakes in C++.

https://devblogs.microsoft.com/oldnewthing/20240802-00/?p=110091


Enum class improvements for C++17, C++20 and C++23

Tags: tech, c++

Enum classes keep being improved. Nice features are already available, more might be coming through reflection in C++26.

https://www.cppstories.com/2024/enum-improvements/


[JDK-8303099] Null-Restricted and Nullable Types (Preview) - Java Bug System

Tags: tech, programming, java, safety

This would definitely be a nice change to the Java language.

https://bugs.openjdk.org/browse/JDK-8303099


What the heck are reverse mapped types?

Tags: tech, typescript, type-systems

The TypeScript type system is really a beast. There are little known features in this, looks definitely like one of them.

https://andreasimonecosta.dev/posts/what-the-heck-are-reverse-mapped-types/


Reliable JavaScript benchmarking with Tachometer

Tags: tech, javascript, benchmarking, tools

Looks like a nice tool for benchmarking Javascript in the browser.

https://nolanlawson.com/2024/08/05/reliable-javascript-benchmarking-with-tachometer/


GM Shaders Guest: Radiance Cascades

Tags: tech, 3d, shader

Very neat technique for global illumination. Very effective but still has some issues.

https://mini.gmshaders.com/p/radiance-cascades


Store Code Discussions in Git using Git Notes

Tags: tech, tools, git, version-control, codereview

I like the idea of getting all the review comments back into Git once things are merged. This works offline, makes you less dependent on the forge for historical data etc. Now we’d probably need to have the notes feature easier to use somehow.

https://wouterj.nl/2024/08/git-notes


Build metrics and budgets with git-metrics

Tags: tech, tools, git, version-control, quality

Maybe we could store metrics about the code in the history as well? This would indeed reduce vendor lock-in. This tool makes it easy. Unsurprisingly seems built upon git notes.

https://dev.to/jdrouet/build-metrics-and-budgets-with-git-metrics-4pb4


Humans >> Data - by Kent Beck

Tags: tech, engineering, productivity, metrics

Aren’t we loosing something if we focus on productivity numbers too much? A good reminder that intrinsic motivation is an important driver in people behavior. I wouldn’t throw all the metrics out of the door but they’d better be a limited amount and they’d better be informative rather than objectives.

https://tidyfirst.substack.com/p/humans-data



Bye for now!

Thursday, 8 August 2024

Qt and Trivial Relocation (Part 5)

In the previous posts of this series (if you've missed them: parts 1, 2, 3, and 4), we have learned about relocation and trivial relocation.

We have explored what relocation means, what trivial relocation means, and how it can be used to optimize the implementation of certain data structures, such as the reallocation of a vector-like container (std::vector, QVector and so on).

Furthermore, we have explored how trivial relocation is connected to move assignments and how some types may be trivially relocatable for move construction but not for assignments. This property can be used to further optimize other operations, such as swaps, erasure, and swap-based algorithms such as std::sort or std::rotate.

In this blog post, we'll have a look at trivial relocation from a "Standard C++" point of view.

Is trivial relocation allowed in Standard C++?

That's probably a question we should have asked as soon as we started this journey. Of course, the answer is no, it is not allowed!

Remember how trivial relocation works: we use memcpy a source object('s representation) into some storage, and claim that operation realizes the equivalent of move-constructing the source into that storage, plus destroying the source.

The problem is that one can't just put data into some storage and pretend that an object exists in there. This is only allowed for a specific set of types, such as trivially copyable types. (Note that if a type is trivially copyable, then Qt automatically considers it trivially relocatable.)

However, as we have discussed, many interesting types (QString, std::vector, std::unique_ptr, ...) are not trivially copyable, but they would still benefit from trivial relocatability.

Qt simply ignores the Standard wording and just uses trivial relocatability because it makes our code faster, reduces template bloat, reduces compilation times, and so on. I call this "Undefined Behavior That Works In Practice": yes, the operation is illegal, but so are many others. Qt is in good company here; many other popular libraries employ the same "illegal" optimization -- to name a few: Folly, EASTL, BSL, and possibly others; a survey is available here.

Towards standardization

A few years ago, P1144 ("std::is_trivially_relocatable") emerged. This proposal (which, by the way, has reached its eleventh revision at the time of this writing) was inspired by the work in many existing libraries (including Qt) and introduced the necessary language and library facilities in order to give well-defined semantics to relocation and trivial relocation. Despite its many iterations, it never made it over the "finish line", voted into C++.

Some time after P1144's initial revision, P2786 ("Trivial Relocatability For C++26") was proposed. This was an alternative design, w.r.t. P1144, with different relocation semantics and a different set of enablers.

P1144 and P2786 "competed" for a little while; then, during the ISO C++ meeting in Tokyo (March 2024), the Evolution Working Group voted to adopt P2786 for C++26.

That's great news, right?

Well, not really. After some analysis, it turned out that P2786's design is limiting and not user-friendly, to the point that there have been serious concerns that existing libraries may not make use of it at all. In particular, P2786's relocation semantics do not match Qt's. With my Qt hat on, it soon became clear that we could not have used P2786 in Qt to replace our own implementation of trivial relocation. This fact raised some serious concerns.

For this reason, I co-authored a "petition paper" (P3236), together with many other library authors, asking EWG to reconsider its decision of going ahead with P2786.

I also have analyzed in detail the problems that I have with P2786's design in a separate paper (P3233). I don't want to go through the complete list of issues in a blog post -- please read the paper and send feedback. :)

In June 2024, during the ISO C++ meeting in St. Louis, I presented P3233 to EWG. If you're interested and/or want a summary of the issues I raised, check out the slides that I used during my presentation.

P3278R0 ("Analysis of interaction between relocation, assignment, and swap") was also presented, making many of the remarks that I've also made in my paper; I consider a good sign that different authors independently reached the same conclusions.

Eventually, EWG voted to take P2786 back, given the issues raised. I consider it a victory in the face of the danger of standardizing something that does not match the current practices. Still, I understand the frustration at pouring a tremendous amount of work into getting a feature into C++, only to get asked to go back to the drawing board.

So what now?

I hope I can find the time in the next few months to work more on trivial relocation, and present more papers at the next ISO C++ meeting in Wrocław. I think the goal to have trivial relocatability in C++26 is doable; we "just" have to iron out the details.

Regarding the two competing proposals (P1144 versus P2786), in P3236 I actually make an argument that they should be "merged": each one has some design characteristics that are missing in the other.

Therefore, the trivial relocation story is anything but over. Stay tuned for more updates, hopefully in not the too distant future. :)

In the meanwhile, thank you for reading so far.

Overview about all installments:

The post Qt and Trivial Relocation (Part 5) appeared first on KDAB.

The KIO Framework has gained support for de-facto standard, cross-desktop thumbnail generators. This means that we have a support for thumbnails from 3rd party applications! On Linux systems, many applications that produce some kind of output, such as a 3D file or text document, ship a thumbnailer file that tells file managers how to create thumbnails of their files. One specific example I've used here in the images are STL files, for which we don't have our own KDE-specific thumbnailer plugin.

Screenshot of various STL file thumbnails

Screenshot of a Xenomorph STL files

These thumbnailer files are currently used by Nautilus and Thunar, so we felt like we were missing out and wanted to join the party! :)

Thumbnailer files

Thumbnailer files are simple text files that tell the system what program we should run to generate a thumbnail. You can check what thumbnailers you have installed by running ls /usr/share/thumbnailers

For example, the STL thumbnailer file looks like this:

[Thumbnailer Entry]
TryExec=stl-thumb
Exec=xvfb-run --auto-servernum -w 0 stl-thumb -f png -s %s %i %o
MimeType=model/stl;model/x.stl-ascii;model/x.stl-binary;application/sla;

It tells the software running the thumbnailer what commands to use to generate the thumbnail, and what mimetypes it supports.

KDE Thumbnailer Plugins

On KDE side, we have used plugins for KIO, that reside in the kio-extras repository. They work just fine for our usecase in KDE apps, but nobody should need to write a KIO specific plugin for their application.

The changes to KIO

You can check the merge request for more in-depth details, but here's a summary of how I made it work side-by-side with our plugin system:

We utilize the KIO plugins always first if possible, since we know for sure they work. This is to avoid any possible regressions and oddities, and to keep the change as unintrusive as possible. When we encounter a mimetype that is not supported by our plugins, like STL files, we utilize a thumbnailer file instead.

This also means that it's transparent to users. Users do not have to worry which one they have installed.

Why make support for thumbnailer files then?

As mentioned earlier, no application should need to create a plugin for KIO just to make their thumbnails show up in our applications.

Thumbnailer files offer other benefits too, such as easing future transitions, (like from KF6 to KF7); working nicely with sandboxing, and being distributable in Flatpak bundles.

I am also working on moving our own plugins into thumbnailers, so we get the benefits from that too.

How can I test it out?

Currently it's only in the master branch of KIO, so if you really want to try it out, you will have to set up KDE Plasma development environment: https://develop.kde.org/docs/getting-started/building/kdesrc-build-setup/

When inside in the development environment, open Dolphin and enable the thumbnailers from preview settings.

Any help testing it would be very welcome! :) Let me know of any possible improvements and bugs!

Sunday, 4 August 2024

The Freedesktop.org Specifications directory contains a list of common specifications that have accumulated over the decades and define how common desktop environment functionality works. The specifications are designed to increase interoperability between desktops. Common specifications make the life of both desktop-environment developers and especially application developers (who will almost always want to maximize the amount of Linux DEs their app can run on and behave as expected, to increase their apps target audience) a lot easier.

Unfortunately, building the HTML specifications and maintaining the directory of available specs has become a bit of a difficult chore, as the pipeline for building the site has become fairly old and unmaintained (parts of it still depended on Python 2). In order to make my life of maintaining this part of Freedesktop easier, I aimed to carefully modernize the website. I do have bigger plans to maybe eventually restructure the site to make it easier to navigate and not just a plain alphabetical list of specifications, and to integrate it with the Wiki, but in the interest of backwards compatibility and to get anything done in time (rather than taking on a mega-project that can’t be finished), I decided to just do the minimum modernization first to get a viable website, and do the rest later.

So, long story short: Most Freedesktop specs are written in DocBook XML. Some were plain HTML documents, some were DocBook SGML, a few were plaintext files. To make things easier to maintain, almost every specification is written in DocBook now. This also simplifies the review process and we may be able to switch to something else like AsciiDoc later if we want to. Of course, one could have switched to something else than DocBook, but that would have been a much bigger chore with a lot more broken links, and I did not want this to become an even bigger project than it already was and keep its scope somewhat narrow.

DocBook is a markup language for documentation which has been around for a very long time, and therefore has older tooling around it. But fortunately our friends at openSUSE created DAPS (DocBook Authoring and Publishing Suite) as a modern way to render DocBook documents to HTML and other file formats. DAPS is now used to generate all Freedesktop specifications on our website. The website index and the specification revisions are also now defined in structured TOML files, to make them easier to read and to extend. A bunch of specifications that had been missing from the original website are also added to the index and rendered on the website now.

Originally, I wanted to put the website live in a temporary location and solicit feedback, especially since some links have changed and not everything may have redirects. However, due to how GitLab Pages worked (and due to me not knowing GitLab CI well enough…) the changes went live before their MR was actually merged. Rather than reverting the change, I decided to keep it (as the old website did not build properly anymore) and to see if anything breaks. So far, no dead links or bad side effects have been observed, but:

If you notice any broken link to specifications.fd.o or anything else weird, please file a bug so that we can fix it!

Thank you, and I hope you enjoy reading the specifications in better rendering and more coherent look! 😃

I like to call myself git “expert”, but I failed pretty badly few weeks ago I needed to bisect the kernel source code to figure out one bug.

General git bisect process is, You have two known commits, one is good and one is bad, and you keep searching for bad commit by splitting history in two. Lets say you have following changelog (not the actual changelog I was debugging, but example):

Saturday, 3 August 2024

KStars v3.7.2 is released on 2024.08.03 for Windows, MacOS & Linux. It's a bi-monthly bug-fix release with a couple of exciting features.

A few members of the KStars development team were enjoying their summer holidays over the past few weeks, but we still have a couple of exciting features in this release!

Multi-Camera Support

Wolfgang Reissenberger devoted countless hours to bring this complex feature that required lots of architectural changes in Ekos. If you have double rigs (or even more), we have a new great feature: multi camera support! If you have more than one optical train on your mount, you now will be able to run capture sequences for each of your optical trains in parallel from the same KStars instance. You simply need to create an optical train for each of your telescopes on your mount, create camera tabs for each optical train, create their own sequence and let them run in parallel.



This new feature may also be used in combination with the scheduler: in this release, the scheduler itself will control the first camera. On top of that, you could configure additional cameras in the capture tab which could execute their own capture sequences. Enhancing the scheduler such that it could control multiple optical trains in parallel is already under development and will be part of one of the next releases. So stay tuned!

Focus Advisor v4


John Evans refactored the Focus Advisor to make it simpler while still offering a lot of insight on parameters tuning. It is now more accessible to new users and has added functionality to optimize values for 2 of the more difficult Focus parameters: Step Size and Backlash (or AF Overscan).




In addition, Focus Advisor contains a convenience tool to locate stars by searching the range of motion of the focuser and another convenience tool to highlight differences between current Focus parameter settings and those recommended by Focus Advisor.