I’m pleased to announce the immediate availability of Plasma Browser Integration version 2.0 on the Chrome Web Store and Microsoft Edge Add-ons page. This release updates the extension to Manifest Version 3 which will be required by Chrome soon. The major version bump reflects the amount of work it has taken to achieve this port.
Konqi surfing the world wide web
Plasma Browser Integration bridges the gap between your browser and the Plasma desktop. It lets you share links, find browser tabs and visited websites in KRunner, monitor download progress in the notification center, and control music and video playback anytime from within Plasma, or even from your phone using KDE Connect!
Despite the version number, there aren’t many user-facing changes. This release comes with the usual translation updates, however. Since this release doesn’t bring any advantage to Firefox users over the previous 1.9.1, it will not be provided on the Mozilla add-ons store.
We have taken the opportunity of reworking the extension manifest to make the “history” permission mandatory. When the browser history KRunner module was originally added, the permission was optional as we feared it might scare users away when presented with a scary permission warning when updating the extension.
Since dolphin-plugins 24.05, you can git clone from dolphin with dolphin-plugins git plugin.
Once the plugins are installed and Git is enabled in the context menu settings, you have this context menu action available:
And this shows this git clone dialog (with my french locale):
You can paste a git repository url and it will fetch its branches.
If you happen to have a url in your clipboard or a git clone command line, it will directly extract it as the repository url.
This was spearheaded by Nikolai Krasheninnikov, thanks.
I participated a bit as well and reviewed it.
There is still opportunity to improve the git implementation, like having a better commit dialog.
That would be a nice and simple new contributor opportunity :)
Log out and log back in (or restart) to re-initialize the XDG_DATA_DIRS variable, otherwise, newly installed Flatpak apps will not run or appear in the startup menu.
This blog post provides the heads-up about planned tablet input changes that are brewing for Plasma 6.3. KWin provides support for the tablet input protocol, but things are different on the client side. Some apps support it, some do not. If an application supports the tablet input protocol, great, it will receive tablet input events as is. On the other hand, if the application does not support the tablet input protocol, then KWin will fake tablet input as pointer input. In Plasma 6.3, KWin will stop doing that and I think that we should briefly talk what led us to such a decision and what impact it will have.
Originally, when the tablet input protocol support had landed in KWin, there were still pretty few applications and toolkits that supported it. Emulating tablet input was a fairly reasonable decision, otherwise you would have likely not been able to use tablet in the Plasma Wayland session at all. As time went by, more and more clients gained native support for the tablet protocol. Unfortunately, in meanwhile, we had also started noticing various issues with tablet emulation.
So, what’s the reasonable thing to do about it? Fix the bugs of course. And we did. But there is still a set of issues that cannot be addressed without bringing more complexity in already too complex code that we are struggling to keep afloat. Enough is enough.
Q: What’s new in 6.3?
A: Starting since 6.3, tablet input emulation will be deprecated and disabled by default. Note that you can enable it back by setting the KWIN_WAYLAND_EMULATE_TABLET=1 environment variable.
Q: When will tablet input emulation be dropped?
A: There is no concrete milestone at the moment.
Q: What does it mean to you? (as a user)
A: Hopefully, nothing. The major toolkits such as GTK, Qt, and SDL already provide support for the tablet protocol, so does Xwayland. So, you should be able to use tablet without any issues in X11 applications or Wayland native applications that use the aforementioned toolkits. Chromium/Electron still does not provide native support for tablet input on Wayland, but it’s also worth noting that most of those applications run through Xwayland by default unless the user sets some command-line arguments.
If your favorite application does not work with tablets, please tell it to the developers of that application so they know that there’s demand for such an operation mode.
Q: What should I do? (as a toolkit developer)
A: Please add support for tablets! If your toolkit already supports the tablet input protocol, wonderful, no work to do. \o/
Q: Is KWin alone by stopping emulating tablet input?
A: No, it is not. Mutter (the Wayland compositor in GNOME Shell) doesn’t emulate tablet input either.
Closing words
Deprecating tablet emulation is disappointing but the options that we have are not great either. It’s either bring in more complexity in order to fix the existing issues (plus even more code to ensure that the pointer focus is managed correctly when using both pointer and tablet) into an already too complex codebase or just do nothing special about applications that don’t opt in into tablet input. Hopefully, the remaining applications and toolkits that still miss tablet support add it in the near future. If you have more thoughts about it, please reach out to us at our matrix room.
This is a very harsh and bleak view on the current generative AI craze. Clearly it survives on some sort of weird faith that things will magically improve. Some decision makers clearly run fully on said faith and lost all kind of realistic view of the situation. They are just very disconnected from the user’s needs.
There’s even a funny quote in there: “Generative AI must seem kind of magical when your entire life is either being in a meeting or reading an email”.
When this bubble bursts, it’s hard to predict what the fallout will be on the tech industry… for sure it won’t be pretty. It also begs the question: what is this industry going to do next? There’s clearly no plan after generative AI.
Need to illustrate how much the current AI arm race is an ecological and social problem? Here is a very pathological case. This is what you get when you let the tycoons behind this completely unchecked.
Larry Ellison’s AI-Powered Surveillance Dystopia Is Already Here
Tags: tech, oracle, surveillance
People are gasping in horror with Larry Ellison’s latest claims… but really they should realize he’s not dreaming big. All of that is already here in one form or another. Maybe it was time to protest years ago?
Or why we should all be concerned and condemn the latest pager and walkie-talkie attacks. They clearly opened a Pandora’s box, it’d be surprising not to see more of those from various organizations. The funds and efforts required make it affordable enough.
Or why going through an event loop might be more work initially but will make some things easier longer term. Nice way to frame how threads are bringing some opaque state.
We should definitely be more wary of metrics indeed. They help for a while, but at some point you’ll necessarily get unfortunately burnt by them. The only fallback is “good judgement”… do what you can with this.
This year Akademy was in Würzburg (shock! horror!). I think its not too far fetched to say that we pulled it successfully.
How it came to be
During last years Akademy in Thessaloniki the idea came up given the high density of KDE
people in the area to hold Akademy in Würzburg. On top we had the perfect venue in mind: two lecture halls for talks, BoF rooms
and a ample common area for people to hack and socialize. I had such thoughts in the back of my mind for a while but did not share
or go through with them.
However what Akademy does is it makes you talk to people and Tobias convinced it me that we should do it
and more people even agreed that Akademy in Würzburg would be a good idea! (Of course some of these encouragers this does not mean
work organizing Akademy like it would mean for us…) So on the second-to-last day of Akademy I sat down and wrote an email to my
former university professor to enquire about the possibility of doing Akademy in the building that we envisioned.
And just like that, after some informal talks during Akademy and a meeting at the University and sending in a proposal after the
Call for Hosts later you end up having weekly meetings to talk about and plan the next installment of Akademy.
How it did go
There were some problems but I think all in all this year Akademy went very well. I heard so much praise and positive feedback
it felt a bit surreal at first (as did Sunday evening when all the talks were done). The most stressful situation for me happened
on Sunday afternoon when I retrieved my charging phone from the team room to discover that the social event could not go ahead
as planned and trying to manage that with the rest of the team. I think the resulting evening was very nice and chill and you could feel
my relieve. I heard there was even an afterparty afterwards at the bar where we had held the welcome event.
Of course during the event there are always minor issues that need dealing with and looking out for those, dealing with them
and trying to make sure everything is running smoothly (and the stress coming these things) meant that I couldn’t (and was not in the right state of mind) to focus much on the talks. When the BoF days started this was bit better but only on Thursday after the day trip I felt in a ‘conference mood’
and was able to focus fully on the BoFs that I was attending and sit down and hack a bit. If you want to learn more about the actual conference many people have blogged about it on the planet or read the report
on the Akademy website.
In the end I think it’s fair to say that Akademy was a success. Made possible by KDE e.V. (go donate!), the sponsors, all the people of the Akademy team local and non-local,
all the Volunteers on short and on long notice an last but not least all the awesome attendees - there would be no Akademy without any people.
Thank you to you all! I am excited to learn about where next years Akademy will be (you can do it as well - it’s not hard and you get an awesome award on top) and looking forward to attending it as
‘normal Attendee’ and meeting everyone again there (if not earlier).
It contains bug fixes and graphics improvements on multiple activities.
This version adds translation for Latvian.
It is fully translated in the following languages:
Arabic
Bulgarian
Breton
Catalan
Catalan (Valencian)
Greek
UK English
Esperanto
Spanish
Basque
French
Galician
Croatian
Hungarian
Indonesian
Italian
Lithuanian
Latvian
Malayalam
Dutch
Norwegian Nynorsk
Polish
Brazilian Portuguese
Romanian
Russian
Slovenian
Albanian
Swedish
Swahili
Turkish
Ukrainian
It is also partially translated in the following languages:
Azerbaijani (97%)
Belarusian (87%)
Czech (97%)
German (96%)
Estonian (96%)
Finnish (95%)
Hebrew (96%)
Macedonian (90%)
Portuguese (96%)
Slovak (84%)
Chinese Traditional (96%)
You can find packages of this new version for GNU/Linux, Windows, Android, Raspberry Pi and macOS on the download page. This update will also be available soon in the Android Play store, the F-Droid repository and the Windows store.
The jury of this year’s KDE Akademy Awards, being by tradition representatives of last year’s winners, has selected the hex editor Okteta in the category “Best Application”. Thanks to them for this appreciation, even more for a niche application
Though, appreciation for what, as there are no details? The last new feature was added in 2019, with the 17th patch release since just done. So, for a reliable program with no need to relearn the UI every year and proudly close to zero open actual bug reports? Then the port to Qt6/KF6, while started in 2022, might be only completed in 2025… if ever. So rather, is this an end-of-life award for an aged 16 years old program?
Looking Back
Triggered by the event some reflection on the past development, if only for the author himself, to update the memories how one got here and what it brings for the future. Which turned into a longer text than anticipated
2003-2006: Years of Initial Need for a Widget
The Okteta project was born in 2003 , the known first code traces date back to May 13th, 2003. The first related code was imported into KDE’s code repository in August 15th, 2003, by the commit message:
Initial import of KHexEdit2, featuring a widget, a kpart and an app. Most important is the widget... Hopefully it will be usable enough ready for KDE 3.2...
The name “KHexEdit2” was chosen as the project was a re-implementation of KHexEdit, the hex editor part of KDE since KDE 1.1. Because those times I was trying to create a viewer for executables and libraries (project name Binspekt, stalled soon), for which I wanted a widget for displaying bytes. KHexEdit seemed to have no code that could be cleanly ripped out and be reused, so work started to code such a widget from scratch and respectively also consumers of it, to add more reason & motivation.
The formal request on September 29th that year to then move the project’s code from the “kdenonbeta” area into release-covered areas had this optimistic line in it:
Finally there will be an app, build around the ReadWritePart. In 2004.
Turned out, life did not agree to that plan, thus 2004 passed without any such app. And so did 2005.
Still, back in February 2004 as part of KDE 3.2 the first elements of the still named KHexEdit2 project made a first release. Though with a bit of complexity. ((Note that at this time KDE was still also the name of the released bundle product, composed of the so called modules kdelibs, kdebase, kdeutils, etc. Where kdelibs held all the public libraries, kdebase the basic desktop components, and so on.)) As adding a complete implementation of a hexeditor widget to the official kdelibs for just a few potential users was declared unbalanced, instead just some header files with KHE namespaced abstract interface classes were added, with an inline utility method to dynamically load any plugin implementing them. So not increasing the actual runtime and installation size of kdelibs. And the kdeutils module got to provide such a plugin by the name KBytesEdit. This then was implemented by the hex editor widget library from the KHexEdit2 project, also in the kdeutils module, whose own API and headers were kept private. To confuse everyone this library was yet named libkhexedit, even if the actual KHexEdit program did not use it. Because the spirit of the naming was on the level of widgets and classes, not program names, and there the 2 postfix made no sense. Consumers of this construct became at least the utility app for Palm Pilot handhelds KPilot and the debugger plugin of the IDE KDevelop.
In March 2005 KDE 3.4 then included the KHexEdit2 KPart (read-only) as well, also located in the kdeutils module and also implemented using the private libkhexedit library. Making some people unhappy as it registered (like its Okteta successor still does today) as handler for the MIME type application/octet-stream, so popping up as fallback KPart where no other handler was found,. And seeing raw bytes over nothing has been partially perceived as “broken”
2006-2008: Second Try on a Program, as Sample and with new Dedicated Name
2006 arrived, and with the author there was still some ever developing curiosity about the feasibility of writing viewer & editor programs using some higher-level reusable & exchangeable components. Now a byte array is a pretty simple data structure to use for a sample implementation of such a concept. And here we had a widget implementation for byte array viewing and editing fully under our control. And a certain level of skills with C++ acquired at the time. This was just too tempting to not give it an own try, for fun and experience. So a June blog post “Fun with KHexEdit” also mentioned a program again and introduced the name designed meanwhile:
I am tackling the construction of a successor to KHexEdit again, projectname “Okteta”.
Later that year a first visual snippet was shared, showing how KHexEdit’s UI served as initial template for Okteta, also to potentially help the transfer of existing users:
November 2006: first published screenshot of Okteta in some pre-Alpha state
To avoid duplicated efforts and to increase pressure to deliver, two weeks later on November 27th an optimistic email was sent to KDE’s great eternal to-newer-API porting worker Laurent Montel, as it was the time to port KDE software to Qt4/KDELibs4:
Hi Laurent,
please don't spend too much effort at the old program KHexEdit, I am quite far on the way to write a successor, called Okteta. Concerning feature compatibility, so far I implemented around 60 % of the features of KHexEdit, and hope to do the last 40 % until at least January. Yes, no code yet in SVN (besides the library), but that will change in three weeks, promised. [...]
This time life agreed mainly to the plan. Though the promise on the code in SVN was delivered on only with almost a year delay. A first dump of the program code was committed into KDE’s code repository on October 23rd, 2007, by the commit message:
Uploading the Okteta program into KDE's playground,
so the code isn't lost, after growing slowly only on my hdd for more than a year.
Okteta is a planned successor to KHexEdit, yet misses all of it's functionality.
With it's modular architecture, based on the co-developed lib kakao, it should
soon offer more than would could be done with the monolithic KHexEdit. I hope.
As can be read, this first copy also was featuring a first draft for the own before mentioned higher-level component system, initially named “Kakao”, later in 2009 to be renamed to “Kasten”. That first name was made ad-hoc inspired by a drink on the table (in learned safe distance from the keyboard), to soon find it used similarly by some certain bigger IT company, even for a somehow related subject, thus a new name was by the time designed less ad-hoc.
And so some months later in April 2008 Okteta entered the “kdereview” phase, to proceed after two weeks into the kdeutils module. In time for KDE 4.1, so premiering its release as part of that in July 2008. Okteta here also took over to provide the KBytesEdit plugin for the kdelibs KHE interfaces as well as the KPart, which before had resided in subdirectories of the KHexEdit program sources. KHexEdit itself stayed unported to Qt4/KDELibs4, so Okteta as planned did not run into duplicated efforts and rivalry (or, it avoided competition, for good and bad).
July 2008: Okteta’s first release, as version 0.1, part of KDE 4.1
2008-2012: Years of Features Flow
With the foundations laid and releases established as part of KDE releases, the next years saw a number of features added, initially even each KDE version:
2010-Present: Sharing Functionality in Rich Public Libraries
From the very begin of the project on the byte array viewing & editing feature was embeddable by 3rd-party software using the abstract KHE interfaces in kdelibs, or then the KPart at least for viewing, Though this allowed only little control & features due to a limited API.
Starting with Okteta 0.4 in February 2010, the two sets of underlying libraries, Kasten and Okteta ones, used to implement the Okteta program, the Okteta KPart and the KHE KBytesEdit plugin, are provided with stable public API.
The lower-Qt-level Okteta GUI library also started to be accompanied by a Qt Designer plugin, to allow easy use of the two provided classes of widgets also in Qt’s UI files.
February 2010: new Okteta widgets plugin for Qt Designer, part of Okteta 0.4
In February 2010 during a week-long Kate-KDevelop development meeting in Berlin the intended flexibility of the new public libraries proofed itself by enabling to create a plugin for KDevelop to integrate hex viewing & edting and all the Okteta tools in just those few days, for some nice satisfaction. The plugin was officially released first with KDevelop 4.1 in October 2010 and later also ported to the Qt5/KF5 version of KDevelop. For the current Qt6/KF6-based version of KDevelop the plugin is excluded from the build for now, given the current lack of a released Qt6/KF6-based version of the Okteta and Kasten libraries.
October 2010: Okteta plugin for KDevelop, first released with KDevelop 4.1
2012-Present: Switching from Features to Architecture, from Bundled to Stand-Alone
The port to Qt5/KF5 happened without any issues and was completed for version 0.15, released as part of KDE Applications 14.12. During the transformation of KDELibs4 to KDE Frameworks 5 the KHE interfaces also got dropped there, due to Okteta meanwhile directly providing public libraries. So this ported version of Okteta also no longer provided the KBytesEdit plugin, but otherwise as before the public libraries and the KPart, next to the program itself.
After KDE Applications 17.12, as for a while there was no feature development and only occasional work on the design of the Okteta & Kasten libraries happened, the Okteta project switched to a stand-alone release schedule. A 0.25 version branch was created and patch version releases only done when there were user-relevant changes like bug fixes or bigger translation improvements.
Then 2019 brought the first version and for now also latest to also provide at least one new feature to users, for which a 0.26 version branch was created. This version has meanwhile got 17 patch releases, with bug fixes, translation improvements and other adjustments. And after 5 years of such polishing is the one which now received the “Best Application” 2024 Akademy Award
March 2019: new features in Okteta 0.26, released on own schedule
2022-Present: Preparing for Qt6 & KF6
Okteta’s code base has been mostly quickly updated to any API deprecations, also as part of a “zero build warnings” strategy. So the approach taken for both Qt & KF libraries to strive for source-backward-compatible C++ API in their both new major version 6 made the initial port of Okteta to Qt6 & KF6(-Alpha) a matter of less than a day in May 2022. Now, only if one ignores one of the tools.
The Structures tool, first developed by Alexander Richardson in 2010 for Okteta 0.4, was in 2011 for Okteta 0.7 extended by him to also support dynamic structure definitions, using JavaScript expressions. For this QtScript has been used as engine. Four years later, in July 2015 though Qt 5.5 declared QtScript as deprecated. The officially recommended substitute QJSEngine turned out to not allow the dynamic translation of JavaScript properties and methods as relied on by the Structures tool for the copy-avoiding mapping of the data blob interpretation into the JavaScript scene (beware, for what the author understands so far). So it could not be used as drop-in replacement.
As finding a suitable and more future-proof JavaScript engine or exploring a possible reimplementation using the QJSEngine is a complex task and also needs bigger chunks of time & focussing, it had been postponed. Year after year. And thus now nine years later in 2024 there is still not even a plan. And Qt6 no longer now provides QtScript.
Just dropping the Structures tool is not a real option. It is a great feature, which also got some users. So a plan is needed and work to be done by someone. As of now my own, surely radical idea is to rewrite the whole Structures tool from scratch, still for the Qt5/KF5 version of Okteta. This should lead to fully wrapping the brain around this complex feature, instead of seeing to indirectly explore it by trying to understand all the details of the current elaborated implementation with the risk to misinterpret some intentions. Starting from scratch might also allow to finally share all the code used for the data formats in the separate Decoding Table tool, and perhaps even to introduce a more generic approach on the data formats supported in the main mass display besides currently byte values and 8-bit charset mapping. Idea, Should, Trying, Starting, Might, Perhaps… any words of confidence, please?
For now the initial Qt6/KF6 port is maintained by a single commit containing the complete dump of the “it builds, starts and does not crash on simple usage” changes, in a work branch continuously rebased to the latest current Qt5/KF5-based development branch. This commit would then at the time of the real Qt6/KF6 port be properly split into the different aspects of porting. For now it serves to hold the door open while still on the other side.
Looking Forward, by Looking Back Some More
For sure the initial goal with the Okteta program to do something for fun and experience has been largely achieved The current challenge with the needed replacement of the used JavaScript engine promises more experience, though no fun initially to me at least.
And some feedback as well even a KDE Akademy Award now hint the created and publicly shared program also served other people for their serious and less serious needs. Possibly even some desperate Faust-like persons, “So that they may perceive the bytes which hold their doc[ument] together in its inmost fold.” (and even tweak them for better as needed, owning their world or document). Though no contracts done, and thus no souls here owned.
But as before, Okteta actually is just a sample implementation of the actual interest pursued here, exploring the feasibility of writing programs by higher-level reusable & exchangeable components, ideally also allowing random end users to mesh those components themselves into tailored solutions for certain needs. So if development has stalled as it has, both on the components concept but also the hex editing features, how to increase motivation again to set resources aside, and for which part?
Position in the Hex Editor Solution Space
When it comes to the Free Software solution space for hex editor needs, next to Okteta there is currently coverage starting from simple ones like GHex over wxHexEditor, which serves needs beyond Okteta by support for paged loading of big files and also the working memory, though sadly unmaintained currently, to the newer yet most impressive and very powerful ImHex (by what the web pages show, never tried).
So would people suffer if Okteta is gone for current platforms, at least for a while?
Open Component Systems vs. Closed Monolithic Blobs
Now the author, while being curious, never got around to actually study existing solutions for the concept of higher-level component system or even deploy them in projects, only ever saw some theoretic surfaces. And is fully aware of the own experiment turning into something serious rather being a pipe dream. Even more when after soon two decades the initially created TODO list is not even 10 % done, this won’t work out this single human’ life So the following is more like the wish-wash of a hobbyist bird watcher, while also having some chicken in the backyard to which things are compared. Or alike.
It seems composable systems with complex interfaces are not the dominating species in the Free Software ecosystems. The Linux kernel outpaced any microkernel systems, e.g. Gnu Hurd is yet to be spotted outside OS zoos. The Eclipse Rich Client Platform, whose concepts were one of the original by-headlines inspirations for this project, seems to have maxed out some time ago as well. at least in the mainstream through the author’s bubble space. StarOffice^WOpenOffice^WLibreOffice has the UNO component system, but how many Add-Ons flourish on it? Then GnuStep would have enabled to spread the component concepts of OpenStep, but little has be seen? The later GnuStep-related, indeed thriving for stars impressive project Étoilé seemed to be overloaded with related ideas, but sadly never lift off. Then the GNOME project even had a reference to component systems in its initial full name “GNU Network Object Model Environment”, but its respective Bonobo framework based on CORBA faded away rather soon.
Also KDE started initially with implementations around the idea of components. To quote the KDE 1.0 announcement:
In view of these circumstances the KDE Project has developed a first rate compound document application framework, implementing the latest advances in framework technology and thus positioning itself in direct competition to such popular development frameworks as for example Mircrosoft’s MFC/COM/ActiveX technology. KDE’s KOM/OpenParts compound document technology enables developers to quickly create first rate applications implementing cutting edge technology. KDE’s KOM/OpenParts technology is build upon the open industry standards such as the object request broker standard CORBA 2.0.
KOM/OpenParts was then in KDE 2.0 replaced by KParts. Actually the presence of such technology development was the deciding factor to go for KDE when the author those days got into “Linux” and had to choose between GnuStep, Enlightenment, GNOME and KDE. These days though KDE is run with claims like “All About Apps”. The generic KServices system got destructed for KF6. The possibly latest KPart (a Markdown Viewer) was written years ago by this author, and the once KDE-central KPart-driven program Konqueror is only a shadow of its former self. KOffice & Calligra as component-oriented office suites also died or stalled close to extinction. Generic plugins like the KParts are not even listed on apps.kde.org or elsewhere anymore, also no longer mentioned as concept in KDE Gear release announcements. Similar specific plugins like the Plasma applets, they are also not listed separately, but only as part of the respective, in the example, Plasma products.
Additionally packaging formats like Flatpak or Snap are discussion-less embraced and promoted, which push in the direction of isolated and frozen software programs. Even today does Flatpak’s metadata system appstream. also otherwise discussion-less embraced by KDE, not have a concept of generic plugins, so KParts cannot be described properly.
In such an environment a component system would be limited to predefined fixed component sets in libraries, from which applications would then provide a setup and offer that to users. A bit like being able to shop as consumer at the kitchen equipment store only preset exhibition rooms, instead of meshing up items from different providers into ones’ own tailored meal preparations “app”. Surely it is in the interest of the dominating providers who then will see to bundle only their items, and then add bloat as well as only making half the items good. As consumer I desire to have the choice over pre-made bundles vs. self-assembled ones. Like there are times for All-inclusive vacations and times for self-organized ones. So with current KDE but also the larger current Free Software “desktop” scene as real world development environment working on and thinking about component systems has the author feel at odds.
So maybe the experiment with Kasten as a higher-level component system could also stop here. Perhaps some research instead could be done why such systems failed in comparison. Like, was it due to the inflexibility presented by fixed published interfaces, where on new feature needs implementations cannot simply do temporary shortcuts and adaptions where needed to be quick back to the market? Could it be due to the possible need for more abstract and generic thinking with component systems, where the majority of developers working for the market might prefer to think more concrete and case-by-case? Then, might there still be a middle-ground, where any advantages of high-level component systems are the deciding factor in the competition?
Next Release Scheduled: October 10th, version 0.26.18
As described already for the early stages, there always have been ideas and plans.. and delays… and also doubts… and then things happened. Locally there are lots of notes with ideas, and a number of code drafts and sketches stacked by the years. And at least in the near future it seems there are still time windows, electricity, a laptop, and enough human capabilities to carry on and tinkering over this stack.
The Okteta (& Kasten) project for now is alive, just lurking around in front of the next evolution step to take. Which might find it new ground. Or extinction anyway. And while it is lurking, it gets a tad more feathers polished, by another bug fix release already scheduled for next month
We’re pleased to announce the release of KD Reports 2.3.0, the latest version of our reporting tool for Qt applications. This marks our first major update in two years, bringing several bug fixes and new features that further improve the experience of generating reports.
What is KD Reports?
KD Reports is a versatile tool for generating reports directly from Qt applications. It supports creating printable and exportable reports using code or XML, featuring elements like text, tables, charts, headers, and footers. Whether for visualizing database content, generating invoices, or producing formatted printouts, KD Reports makes it easy to create structured reports within your Qt projects.
What’s New in KD Reports 2.3.0?
The new release includes essential bug fixes and feature enhancements that make KD Reports even more robust and user-friendly.
Bug Fixes
The 2.3.0 release addresses several important issues to improve stability and compatibility. One major fix resolves an infinite loop and other problems caused by changes in QTextFormat behavior in Qt 6.7. Right-aligned tabs, which previously didn’t work when paragraph margins were set, have also been corrected. High-DPI rendering has been improved to eliminate blurriness in displays where the device pixel ratio (DPR) is not equal to 1. Furthermore, an issue with result codes being overwritten in the KDReportsPreviewDialog has been fixed. Finally, table borders, which were lost after upgrading to Qt 6.8, now behave as expected, maintaining their cell borders throughout.
New Features
KD Reports 2.3.0 introduces several new features aimed at providing more customization and flexibility in report generation. For instance, the AutoTableElement now supports customization of header styling via the new setHorizontalHeaderFormatFunction and setVerticalHeaderFormatFunction, which are demonstrated in the PriceList example. Additionally, individual table cell formatting has been enhanced with the setCellFormatFunction, allowing for customization of borders and padding. Text alignment within table cells has also been improved with the new setVerticalAlignment feature, making it easy to vertically center or top-align text when using different font sizes within the same row.
The AbstractTableElement now allows setting column constraints while leaving some columns without constraints—just pass {} for unconstrained columns. This feature is particularly useful when setting constraints for columns further to the right. Also, the TableElement has gained rowCount() and columnCount() methods, which can be used in dynamic scenarios, such as applying alternate background colors to rows.
Lastly, you can now disable the progress dialog during printing or PDF export using setProgressDialogEnabled(false). This is useful for applications that generate multiple documents or handle progress tracking internally, offering more control over the user interface during these operations.
You can explore all the new features and improvements in KD Reports 2.3.0 on its GitHub page. Download the latest release and check out the detailed changes to see how they can enhance your reporting tasks. Feel free to share your feedback or report any issues you encounter along the way.
@kbroulik:kde.org
meven
This year Akademy was in Würzburg (shock! horror!). I think its not too far fetched to say that we pulled it successfully.
