KStars v3.8.3 is released on 2026.06.01 for Windows, Linux, and MacOS. For Linux users, it's highly recommended to use the official KStars Flatpak hosted at Flathub. This release brings major improvements to the Mount Modeler with artificial horizon filtering and uniform point distribution, significant connection speed optimizations, better guide streaming integration, and enhanced rotator handling. We've also fixed several scheduler and stability issues reported by the community. Here are the highlights: Alignment & Mount Modeler 
Christian Kemper added Artificial Horizon filtering to the Mount Modeler wizard, allowing generated alignment points below the active horizon to be automatically filtered out. Candidate coordinate points (both generated AltAz coordinates and snapped catalog objects) are now checked and rejected if they fall into active artificial horizon regions. New Uniform Distribution mode generates points spread evenly across the visible sky using a Halton sequence, sampling in AltAz space to guarantee every point is above the configured minimum altitude. Points whose declination exceeds +/-80 degrees after conversion are rejected. The Any Stars, Named Stars, and Any Object modes now adopt this distribution internally and snap each generated position to the nearest qualifying object. Auto-sorted wizard output: points added by the wizard are automatically sorted in nearest-neighbour slew order, minimizing total slew distance. Users no longer need to click Sort after running the wizard. Clicking Sort during a run reorders only the remaining unvisited points, leaving completed rows undisturbed. The wizard now automatically configures the solver for each alignment point. Blind solves are used by default because no pointing model exists yet at the start of a run, so the mount's reported position may be significantly off. The GOTO mode is forced to Sync so the mount is updated after each successful solve. The original settings are saved and restored when the run finishes, is aborted, or is reset. Refactored point generation logic to eliminate duplicated generation and conversion math in the test suite, improving generator efficiency using a stateful sequence Toni Schriber fixed activation of the rotator button in the align module Fixed effective focal length calculation to use radians in the DSLR branch Guide 
Thanks to Andreas Ruthner, guide streaming now correctly handles video stream window interaction. The video window no longer pops up when guide streaming starts, displays frames correctly when opened from the Capture module after a guide session, and now renders 16-bit mono stream frames (previously only 8-bit mono and RGB were handled). Andreas also fixed frame, binning, gain and exposure sync for streaming mode. When starting guide streaming, the module now applies the same frame settings that captureOneFrame() applies for single-frame captures. Previously, streaming mode skipped this setup entirely, causing stale values from other modules to remain active in the driver. Frame ROI and binning now sync on stream start, live gain updates apply immediately when the user changes the spinner during active streaming, and binning/exposure changes automatically stop and restart the stream Added 0.001-0.01s exposure values to the guide exposure spinner for fast streaming and daytime testing Rotator Fixed several issues with Reversed rotator state not taken into account in various rotator operations Rotation now aborts if the Position Angle error keeps increasing due perhaps to reversed rotator behavior Ekos Profiles & Connection Significantly cut down time to connect to INDI web manager by skipping DNS resolution if we already have an IP address specified for the remote host Fixed rare crash due to dangling clientManager pointer with test to verify the fix Capture & Livestacking 
Use OpenCV debayering by default. Enforce even ROI selection to ensure bayer boundaries are respected. Always sync from INDI to overwrite shadow states in the Camera process Account for STREAM_FULL_DEPTH when streaming John Evans added support for Live Stacker Alt/AZ data via Seestar S30 Pro. It should support other telescopes in Alt/AZ mode. John added a gradient removal option to post processing in Live Stacker. FITS Viewer & File Handling Use standard gzip compress instead of Qt own compression algorithm Support loading .fits.gz and .xisf.gz in the viewer Scheduler & Observatory Automation Fixed scheduler freezes when loading ESL referencing many ESQ files (patch by Tomas). BUGS:519294 Autopark should work over multiple nights now If observatory is not started, skip shutdown procedure Fixed issue where post-shutdown script run in infinite loop Fixed scheduler and capture scripts not running inside flatpak Optical Trains & DBus API Added DBus call to set and get Pictures directory Fixed warning of missing devices when we already selected alternative devices in the optical train Build & Infrastructure Use KSUtil to consolidate all calls to external executable so they can run correctly within a flatpak as well Within flatpak, run the external scripts on the host system since it may require libraries that are only available on the host system Christian Kemper fixed macOS iconutil failure by adding 256px and 512px icon sizes rendered from the existing SVG source, which are required by iconutil on macOS 15 (Sequoia) Wolfgang Reissenberger updated the Dockerfile to be based on installation scripts for all steps: INDI, StellarSolver, PHD2, GSC, openCV. All scripts are built uniformly such that existing packages or installations are preferred. If the package is missing, first installing the appropriate package is tried. If this fails, the package is built from sources Stability & Bug Fixes Fixed crash reported in crash-reports.kde.org regarding invalid base device or message text. The check for message text now occurs earlier in the process to protect against this crash. Milhan Kim fixed test deadlock by replacing QTest::mouseClick with animateClick(), which posts the click through the event loop and prevents tests from hanging indefinitely on QDialog::exec() loops Fixed an issue where frequent temperature updates can cause the dark cover check to run indefinitely Hy Murveit fixed green lines display issue Fixed solution assignment Fixed crash and distorted artifacts in video streaming Replaced all abs and fabs with std::abs for consistency Modernized signals and slots Many thanks to Christian Kemper, Andreas Ruthner, Toni Schriber, Hy Murveit, John Evans, Milhan Kim, Wolfgang Reissenberger, Tomas, and all others who contributed fixes and improvements to this release! Your work makes KStars better for everyone. Download KStars v3.8.3 today and enjoy improved mount modeling, faster connections, and more reliable guiding!...
Throughout this new process at KDE, I believe I have failed to clearly state what Ocean is and what it means for the future for Plasma user interface and experience. In this post, I will try to shed some light into this and hopefully it’s easier for new people interested in this project. Why the Confusion? I think a lot of the confusion primarily comes from my part in showing graphics first and interface later. Graphics tend to attract a lot of attention. So much that it swallows other narratives about what Ocean is. It’s natural for our users to want to know more and accept that the graphics are the whole story. Spoiler… it’s not just graphics 
How Should We Think of Ocean? Ocean is many things, let me list them out: Ocean Design System Ocean Widget Style Ocean Font Ocean Icons(Icon Pack) Ocean Plasma Style Ocean Color Scheme I think this is another reason why there is confusion out there. I have given a few talks on this as well, but I also see how it’s confusing. In simple terms, Ocean is a new graphic design platform for the Plasma Desktop. This new platform aims, first, to organize the way graphic design for Plasma is achieved. As you may know, designers like me, tend to be pretty creative and unbound. We give free range to creativity and we like to break norms. This is a problem, because if we want to make graphics for a computer system, such as Plasma, we need to organize our creativity in way that developers can understand. For this reason, in recent years, a modern way to organize creativity for computers was invented by applications like Sketch, Figma, and Adobe XD. In these applications SVG is the graphic of choice. SVG is a set of coordinates that tell the system how to draw shapes on the screen. It’s versatile enough that SVG code can be read and tweaked by designers and developers alike. It can be stretched without losing quality, yadah, yadah, yadah… You know the rest. This new wave of applications work with SVG as collections or repeatable graphics interconnected with each other. They use systems of “Components” and “Variants”. Given that computer UI is generally very repetitive, these components save designers time in building more copies of the same graphic with only slight modifications, let’s say for states such as default, hover, selected, etc. These design systems help bring the world of UI development into the graphic design applications. Many developers are very used to working with graphical components, but only until recently were designers able to work with them in a flexible graphical way. KDE Plasma has never had a system like this to organize design around the UI. Because of this, designers haven’t really made a ton of inroads into the system and this limits users in the way that we can deliver design for them. In essence, we designers, were never organized enough to provide a proper, development-ready, graphic design that could be used for Plasma. This is where Ocean comes in. We took up the idea of creating a design system for Plasma that accounts for most, if not all, of the necessary graphical building blocks that developers could use, that preserve consistency between graphics and code, and deliver a cohesive experience for users. By doing this, our hope is that graphic designers that are used to working with design systems can join our team and help us go even further. On the developer side, a design system is a much more clear way of communicating component organization. Developers can more easily understand how buttons are made, what colors are used, what typography levels are on screen, etc. We do this by creating a series of graphic tokens that describe their use in more detail. CSS is also involved, even though we may not support it, applications like Figma and Penpot have the ability to represent component code in CSS terms that others can read. In addition to these tokens, we create a series of foundational tokens where we declare our colors, typography, shadow levels and composition, blur levels, etc. Everything that users would need to see on the screen. Ok, But What About the Graphics You Keep Showing? During the first part of creating a design system, we noticed something pretty meaningful. Breeze and other previous themes, while they work, they don’t have any reflection in a design system. Therefore, designers have a hard time completing the puzzle for a good design system that accounts for Breeze. With any attempt, we would be completing so much of a missing puzzle that we would create something new anyway, just to replicate a style in Penpot, for example. Because of this, we decided to create a new style called Ocean and any style is composed of many parts, listed above. Because of this, we created: Ocean Icons (In progress) Ocean Plasma Style (Complete in Penpot) Ocean Font (In progress) Ocean Style (Complete in Penpot) Ocean Color Scheme (Complete-ish, needs more testing) And one little important detail, it doesn’t matter so much how Ocean style looks. Why? Because through a design system for graphic designers, we have the ability to distribute our system for free to anyone that wants to use it. Graphic designers can tweak the design tokens that Plasma can understand and by doing that, they can more easily build a Plasma Style on their own in a way that is cohesive, thoughtful, complete. We then give those elements to the developer team that would help us execute the design. Hence why I say that Ocean is a design platform. Still, we created a new style in graphical form and we are working with the developer team to execute this style, using the design system tokens and components, in the same way that the designer intended. Our current focus is on icons, particularly application icons. This is just one of the many parts that compose Ocean design. A few months ago we completed a round of design that created monochrome Ocean icons. These icons are functional in nature and much easier to put together. However, we knew that app icons take longer because they are colorful and require lots of time and styling. Icons My recent posts showcase the progress on these icons. To be more clear about how we are doing this icon design element, here is a process: Formalize the visual system Define strict rules for perspective, lighting, shadows, gloss, depth, materials, and color usage so all icons feel like one coherent family. Strengthen semantic readability Ensure each icon immediately communicates the app’s purpose, especially at small sizes. Avoid abstraction that weakens recognition. Improve visual hierarchy Reduce competing elements and make each icon have one clear focal point with cleaner foreground/background separation. Tighten color discipline Use fewer competing colors, control saturation more carefully, and keep palettes more consistent across the set. Be more selective with stylistic quirks Avoid asymmetry, misalignment, or unusual perspectives unless they clearly improve recognition or composition. Standardize depth and rendering behavior Keep extrusion, internal shadows, dimensionality, and lighting logic consistent across all icons. Shift from per-icon experimentation to system-level art direction Prioritize cohesion and consistency over making every icon individually novel or visually surprising. …and we are in step 3 of the process for these icons. We are moving them from rough mockups and sketches into more formalized shapes. At this stage, you should not expect a lot of color or shape cohesion. After this pass comes a time of definition. We restrict our colors even more, simplify shapes for impact, remove or redo icons, etc. It’s a major review. We expect to do this along with the community. We also decided to not create icons for third parties. This makes the amount of app icons to make much smaller. This also makes it easier to think about what our icons should look like going forward. All in all, Ocean is a platform composed of many parts. Our current design focus is set on completing the icon pack while the rest of the style is preparing for development. I hope this makes it easier to understand and I am happy to answer any questions...