KStars v3.5.9 is released on 2022.05.26 for MacOS, Linux, and Windows. It's a bi-monthly bugfix release with a couple of exciting features.
DSS Offline HiPS
HiPS (Hierarchical Progressive Surveys) is a technology that provides progressive high resolution images of the sky at different zoom levels. KStars fully supports online HiPS where data is downloaded from online servers and cached to display on the Sky Map.
One of the most popular catalogs in KStars is the DSS Colored progressive survey. With v3.5.9, you can now specify directory where the offline DSS catalog is located. You can download the data from various HiPS services online. For best experience, it's recommended to download 3rd, 4th, and 5th (Norder3, Norder4, and Norder5) order directories which would take around 1GB of storage space. You may download further orders (i.e. higher zoom levels) at the expense of more storage space.
The following shows a sample of downloaded order directories, at minimum you need Norder3 folder for this functionality to work.
Revamped Mosaic Planner
New simplified and powerful Mosaic Planner directly integrated in the Sky Map. It greatly benefits from HiPS overlay to make your target framing spot on. Toggle the Mosaic View from the tool bar, and select your equipment and the mosaic configuration. You can also use it as a very simple tool to frame a single 1x1 tile.
Adjust the tile center either by manually specifying the J2000 center or by dragging the tiles across the sky map. Once done, you can command the mount to go to the target and solve. Alternatively, you can proceed to create jobs for the Ekos Scheduler. After the jobs are added, you may start the scheduler at any time to plan the mosaic session accordingly.
Refocus After Meridian Flip
Dušan Poizl added the ability to refocus after a meridian flip is complete. This is very useful for some optical train setups where the focuser might shift duration the flip.
New Index Files
Robert Lancaster added the new 5200 astrometry index files. The difference is just which star surveys were used to build which indexes. The 4200 Series was made from 2MASS and covers all the image scales. The 4100 series was made from Tycho2 but only covers wide image scales. The 5200 series was just recently added, was made by blending Tycho2 and Gaia, and complements the 4100 series to give it the smaller scales.
Internal Plumbing: Introducing Device Adapter
Wolfgang Reissenberger continues his outstanding work refactoring Ekos state machine by introducing the device adapter. Next step extracting state handling from Capture into a dedicated state machine. In this step devices are managed by a dedicated device adapter (successor of the command processor). With this refactoring it is no longer necessary to route device events from Capture through SequenceJob to the state machine, the device adapter sends the events directly to the state machine.
Capture Progress face lift
Wolfgang Reissenberger streamlined the capture progress section of Capture:
Remaining time for frame and sequence displayed as hh:mm:ss
Display of average download time (in calculation, all download times are taken into account and not only those > 1)
New status widget with a color LED displaying the capture status (and no longer using the seconds text for this)
Using the same widget on the Master tab
Greedy Scheduler Speeds up
Fans of Greedy Scheduler rejoice! Hy Murveit made significant speedups to the Greedy Scheduler, especially for very large scheduler.
In the face of a growing feature set in any project, getting started becomes harder and harder for new users. This problem is common for many software applications, and LabPlot is no exception. To overcome this problem we’re investing more resources into creating documentation in general, and introductory articles in particular.
We’re also working on a set of short videos that introduce LabPlot’s wide range of core features and aspects.
Finally, in our effort to make LabPlot more accessible for everybody, in our latest release, we added a set of example projects that are installed together with the application and that will provide you with a way to see how certain things can be implemented in LabPlot, as well as help you explore the available feature set and learn more about it.
You can reach the collection of the example projects from the main menu of the application. The dedicated dialog lets you browse the available projects:
Projects are grouped together into different categories:
General includes various example projects that demo LabPlot’s main features.
Analysis includes example projects that explore LabPlot’s data analysis capabilities, such as smoothing, fitting, etc.
Computing includes projects that leverage a variety of open-source computer algebra systems and programming languages used for scientific computation.
Statistics offers examples of LabPlot’s features used for the statistical analysis of data.
Upon selection and loading, the example project is ready to be explored and modified:
Right now the collection includes 19 projects and we plan to add more examples over time. We also invite you to contribute your ideas and projects so that we can add to this collection in the future.
Get some popcorn and strap in for a long one! I shall delight you with some insights into crash handling and all that unicorn sparkle material.
Since Plasma 5.24 DrKonqi, Plasma’s infamous crash reporter, has gained support to route crashes through coredumpd and it is amazing - albeit a bit unused. That is why I’m telling you about it now because it’s matured a bit and is even more amazing - albeit still unused, I hope that will change.
To explain what any of this does I have to explain some basics first, so we are on the same page…
Most applications made by KDE will generally rely on KCrash, a KDE framework that implements crash handling, to, well, handle crashes. The way this works depends a bit on the operating system but one way or another when an application encounters a fault it first stops to think for a moment, about the meaning of life and whatever else, we call that “catching the crash”, during that time frame we can apply further diagnostics to help later figure out what went wrong. On POSIX systems specifically, we generate a backtrace and send that off to our bugzilla for handling by a developer - that is in essence the job of DrKonqi.
Currently DrKonqi operates in a mode of operation generally dubbed “just-in-time debugging”. When a crash occurs: KCrash immediately starts DrKonqi, DrKonqi attaches GDB to the still running process, GDB creates a backtrace, and then DrKonqi sends the trace along with metadata to bugzilla.
Just-in-time debugging is often useful on developer machines because you can easily switch to interactive debugging and also have a more complete picture of the environmental system state. For user systems it is a bit awkward though. You may not have time to deal with the report right now, you may have no internet connection, indeed the crash may be impossible to trace because of technical complications occurring during just-in-time debugging because of how POSIX signals work (threads continue running :O), etc.
In short: just-in-time really shouldn’t be the default.
Coredumpd is part of systemd and acts as kernel core handler. Ah, that’s a mouthful again. Let’s backtrace (pun intended)… earlier when I was talking about KCrash I only told part of the story. When fault occurs it doesn’t necessarily mean that the application has to crash, it could also neatly exit. It is only when the application takes no further action to alleviate the problem that the Linux kernel will jump in and do some rudimentary crash handling, forcefully. Very rudimentary indeed, it simply takes the memory state of the process and dumps it into a file. This is then aptly called a core dump. It’s kind of like a snapshot of the state of the process when the fault occurred and allows for debugging after the fact. Now things get interesting, don’t they? :)
So… KCrash can simply do nothing and let the Linux kernel do the work, and the Linux kernel can also be lazy and delegate the work to a so called core handler, an application that handles the core dumping. Well, here we are. That core handler can be coredumpd, making it the effective crash handler.
What’s the point you ask? – We get to be lazy!
Also, core dumping has one huge advantage that also is its disadvantage (depending on how you look at it): when a core dumps, the process is no longer running. When backtracing a core dump you are looking at a snapshot of the past, not a still running process. That means you can deal with crashes now or in 5 minutes or in 10 hours. So long as the core dump is available on disk you can trace the cause of the crash. This is further improved by coredumpd also storing a whole lot of metadata in journald. All put together it allows us to run drkonqi after-the-fact, instead of just-in-time. Amazing! I’m sure you will agree.
For the user everything looks the same, but under the hood we’ve gotten rid of various race conditions and gotten crash persistence across reboots for free!
Among other things this gives us the ability to look at past crashes. A GUI for which will be included in Plasma 5.25. Future plans also include the ability to file bug reports long after the fact.
Inner Workings
The way this works behind the scenes is somewhat complicated but should be easy enough to follow:
The application produces a fault
KCrash writes KCrash-specific metadata into a file on disk and doesn’t exit
The kernel issues a core dump via coredumpd
The systemd unit coredump@ starts
At the same time drkonqi-coredump-processor@ starts
The processor@ waits for coredump@ to finishes its task of dumping the core
The processor@ starts drkonqi-coredump-launcher@ in user scope
launcher@ starts DrKonqi with the same arguments as though it had been started just-in-time
DrKonqi assembles all the data to produce a crash report
the user is greeted by a crash notification just like just-in-time debugging
the entire crash reporting procedure is the same
Use It!
If you are using KDE neon unstable edition you are already using coredumpd based crash reporting for months! You haven’t even noticed, have you? ;)
If not, here’s your chance to join the after-the-fact club of cool kids.
KCRASH_DUMP_ONLY=1
in your `/etc/environment` and make sure your distribution has enabled the relevant systemd units accordingly.
Kraft is software for the Linux desktop to handle quotes and invoices in the small business.
This is a version packed with bugfixes and also new features. The most important fixes were in the area of the catalog handling: Based on bug reports from the community the catalog window was completely reworked. Drag and drop of items in the catalog, the sorting and reordering of items are now working properly and as planned.
Another big addition is the support of
. XRechnung is an E-invoicing format more and more mandatory in the governmental area in Germany. We are very proud that Kraft is the first open source office tool that supports that standard in a user friendly way. All invoices can now also exported in the XRechnung-XML format.
Beside these two big improvements, there are lots of others. For example, the user manual was further improved and is available also in Dutch. A lot of other smaller but non the less important improvements and fixes make version 0.98 a valueable release.
We wish a lot of fun with this new improved version of Kraft!
Old, but stable, even more in when it comes to the feature set, and still getting its polishing now and then: your simple editor for the raw data of files, named Okteta.
What started in 2003 as a hex editing widget library for KDE3 (and Qt3), of course named KHexEdit (to be confused with the unrelated hex editor program that was part of KDE at that time), it turned into a first dedicated application by the title Okteta during the years 2006 to 2008 for KDE4 (and Qt4). From there on a small set of features was added once in a while, most impressively Alexander Richardson’s Structures tool in 2010,. Until then in 2013 the port to Qt5/KF5 was done (also to a good degree by Alexander). After that things had settled, the program working properly when needed, otherwise just left in the corner of the storage.
Now, nearly 2 decades after the first lines were written, the next port is to be done, to Qt6 and KF6. And this time the actual port is just amazingly boring: changing a few “Qt5” to “Qt6” in the buildsystem (and later some “KF5” to “KF6” once KF6 is ready), adding Qt6::Core5Compat as helper library for 1-2 classes that had not yet been substituted, adding a “const” to the argument of an overridden virtual method, replacing some forward declarations with includes to have all signal and slot argument types fully declared, adapting some “QStringList” forward declarations, a few more explicit constructor calls for type conversions… and done.
It’s even hard to spot a difference (Qt5 above, Qt6 below), just some margins are done differently by the style code right now:
Okteta 0.26.8 running on Qt5.15 & KF 5.94Okteta (local work branch) running on Qt6.3 and pre-KF6
Well, the story has a dark spot though: the Structures tool is missing from the port for now. Because it uses an old JavaScript engine which is gone in Qt6 finally (QScript), and so far no-one has completed the port to an other JavaScript engine, .like the one part of QML.
So while the good people working on preparing KF6 are taking their time still as needed, there is despite this initial happy result a building block to finish for Okteta as well, to not suffer in this current port. And instead having it get even older and still stable
The thing to highlight here is: how all the preparation work done by the Qt and KF developers, when followed in due time on the consumer side by taking care of all the things marked deprecated in favour of the substitutes, pays out and has been worth the investment IMHO. No deep and wild waters to cross to the new version continent, just a small jump. Hopefully also for your software.
Taking a Break from Social Media Makes you Happier and Less Anxious - Study Hacks - Cal Newport
Tags: tech, social-media, sociology, psychology
Interesting (although unsurprising) study (I advise looking at the actual paper) about the links between social media and well being. Of course it has a couple of weaknesses, we need more such studies to grow the numbers and reduce the biases.
Very good piece about honesty. It’s definitely a core principle to have good communication at work. That being said it covers also all the nuances of difficult situations and how to deal with them.
Sorry everyone, it has been a while. Of course, the lack of updates to my blog doesn’t mean that the KDE Goals were also not progressing. On the contrary! Wayland, Consistency and Apps are looking better than ever before.
Today, I don’t want to talk about the Goals themselves, but rather about the process of selecting new Goals.
You see, Akademy 2022 has been recently announced. And because we have a date of the event, it means we can take a look at the process that is described on the community wiki and determine when the new Goals can be created.
The process says, that 15 weeks before the start of Akademy the submission stage begins. Since this year’s Akademy is held October 1-7, looking at my calendar it means that June 17th should be the start date. That’s soon! But don’t worry, that stage lasts 4 weeks, so if you’d like to submit a new Goal for the KDE community, you still have time to think about it.
After the submission stage, a refinement stage and voting follow. Check the wiki page for details.
I’d like to use the remaining time before mid-June to talk about what makes a good KDE Goal, summarize the current ones, and interview with our Champions about tips for those that would like to take their place. Check the blog for updates on all of that!
Indeed, we loath wires… but going wireless has its own set of issues. It never completely breaks but it can easily degrade for no apparent reason which could be anywhere in the stack.
The tone of the article isn’t exactly to my liking, sounds “too good to be true” at times ignoring important details driving the choices (despite some warnings early on). Still, depending on the amount of data stored in your database, SQLite looks increasingly viable on the server, replication even coming down the road.
Bottled water monopolist admits recycling is bullshit
Tags: ecology, lobbying, plastics
The best waste is the one you didn’t create in the first place. If you still had doubts that recycling plastics is a scam, it’s definitely something to read. It was again a trick to turn into a “personal responsibility” something which was a collective failure.
We’re past the soft feature freeze of the next Plasma release, so it’s a good time to step back and a have look at the work that has been done in KWin during 5.25 development cycle.
Gesture improvements
Credits: Eric Edlund, Marco Martin, Xaver Xugl
A lot of focus has been put into improving gesture integration in the Wayland session. In 5.24, the desktop grid effect got support for real-time gestures. In 5.25, the support for real-time gestures has been expanded. Effects such as slide, window aperture (animates windows when transitioning to the “show desktop” mode), and overview now support animations that “follow fingers.”
The slide effect follows fingers when switching between virtual desktops using gestures
Merge of kwayland-server and kwin
Credits: me
That’s not a user-facing change, but it’s really important to KWin developers. Some history trivia. KWin used to contain Wayland glue code, eventually it was split in a separate KDE Frameworks library called KWayland. The idea was to provide reusable components that can be useful not only to KWin but also other Wayland compositors. The split is better described in https://blog.martin-graesslin.com/blog/2014/10/introducing-kwayland/.
At the beginning, things were good. If you need to implement a Wayland protocol, add corresponding wrappers in KWayland and then implement the protocol in KWin. However, being KDE Frameworks started presenting problems. KDE Frameworks provides strong API and ABI compatibility guarantees, which is very compelling for consumers but it can be a major source of headache for developers. For example, if a few bad design decisions were made, you cannot simply go back and correct the mistakes, you are going to live with that until the next major version release when it’s okay to make breaking changes. That’s what happened in KWin and KWayland, we made a couple of bad design choices that fired back at us and eventually resulted in a period of technical debt.
As a way out of technical debt, we made a hard decision to split the server side out of KWayland in a separate library called KWaylandServer, which provided no API or ABI compatibility guarantees between minor releases, but some between patch releases. Most of the client APIs in KWayland were deprecated too.
The split of the server side from KWayland in a separated library was a huge relief and it massively accelerated KWin development pace, that had user-facing effects too. Plasma on Wayland session started receiving less complaints (around Plasma 5.18 – 5.20 or so) from users because we were free to change KWin and KWaylandServer the way we thought was the best.
However, KWaylandServer also started showing cracks. The first problem is that it didn’t gain a strong user base. Its the only user was KWin and there weren’t any signs of new users. The second problem is that we gradually switched to qtwaylandscanner so we ended up writing wrappers for wrappers. The third problem is that wayland protocol implementations cannot exist in vacuum and they need to communicate with other compositor components, e.g. renderer; because no such components were present in KWaylandServer, we had to add glue code that made things more complicated. Also, perhaps we tried to fix a wrong problem by providing a library with Qt friendly wrappers for libwayland. Things such as the DRM backend or the scene graph are far more challenging to implement and maybe we should put focus onto making them reusable instead of wrappers.
Regardless, a year or so ago we agreed that it’s worth bringing server-side wayland code back into KWin. In 5.25, we were finally able to do the merge. That allows us to simplify many wayland protocol implementations, fix some design issues and a few known bugs.
Present Windows and Desktop Grid effects rewritten in QML
Credits: Marco Martin
We started experimenting with implementing some fullscreen effects in QML in 5.24. In order to continue that effort, the Present Windows and Desktop Grid effects were rewritten in QML. The main advantage of QML is that we will be able to build more complex scenes without significantly sacrificing maintainability, for example blurring the desktop background only takes a couple of QML lines of code, in C++ it would be a lot more! The main focus with the rewrite was put on keeping feature parity between C++ and QML versions of Present Windows and Desktop Grid.
Desktop Grid implemented in QMLPresent Windows (now called “Window View”) effect implemented in QML
Compositing improvements
Credits: Xaver Xugl, me
We continue pushing forward with our ambitious goal to make KWin utilize hardware output planes better and make it more efficient. Significant amount of work in 5.25 has been put into refactoring the DRM backend and compositing abstractions. Unfortunately, we won’t be able to get everything we wanted in 5.25, but hopefully Plasma/Wayland users will start benefiting from this work in the next Plasma release, i.e. 5.26.
As a part of the scene redesign goal, we made handling of invisible windows more efficient on Wayland. For example, if an invisible window wants to be repainted for whatever reason, KWin is going to ignore that request. It’s not an issue on X11, but it was challenging to implement that behavior on Wayland the “right way.” Also, if painting code in a Wayland application is driven by frame callbacks, KWin won’t send frame callbacks anymore if the window is invisible, e.g. minimized or on a virtual desktop that is not current, thus no precious CPU or GPU resources will be wasted.
Screencasting improvements
Credits: Aleix Pol Gonzalez
KWin/Wayland got a new screencasting mode that allows capturing a rectangular region on the screen. For example, this can be useful for building screen recording tools, etc.
New blend effect
Credits: David Edmundson
The blend effect provides an eye-candy animation when switching between dark and light themes.
Fixed Aurorae decorations having “sharp” corners
Credits: Michail Vourlakos
The blur effect is applied to the region beyond top-left corner
If you use a decoration theme powered by Aurorae decoration engine, then the decoration borders may not be as round as they are supposed to be. It’s been a long standing bug caused by the blur effect and lack of enough metadata in Aurorae decoration themes
The blur effect is applied as expected in 5.25
Window management refactors
Credits: Nils Fenner
KWin used to have a strange window class hierarchy that always created confusion among new contributors.
KWin used to use the word “client” to refer to managed windows, i.e. the ones with frames, but the word “client” means a totally different thing in the Wayland world, it represents the other endpoint connected to the compositor, e.g. an application. The word “toplevel” also means different things in KWin and the xdg-shell protocol, which is used by practically all Wayland applications to create “normal” windows and popups.
Toplevel and AbstractClient classes were merged into the base Window class with a far more intuitive name. That makes the class hierarchy simpler, and hopefully removes an obstacle for new contributors.
fbdev backend was dropped
The fbdev backend was in a bit-rotten state. With the emergence of simpledrm kernel driver, we decided to drop the fbdev in favor of the DRM backend, which is actively maintained.
Closing words
5.25 is going to be the biggest release by the scale of changes within recent years, which is both great and terrifying, so it’s more than ever important that as many as possible people give us feedback about the upcoming beta. Please join us at https://community.kde.org/Schedules/Plasma_5_BetaReviewDay, which is going to be held on May 26th in https://webchat.kde.org/#/room/#plasma:kde.org, to help us to make this release smooth and amazing.
KNRO
@sitter:kde.org
. XRechnung is an E-invoicing format more and more mandatory in the governmental area in Germany. We are very proud that Kraft is the first open source office tool that supports that standard in a user friendly way. All invoices can now also exported in the XRechnung-XML format.
