Despite an extra-long beta period during which we got awesome feedback from our community, 4.4.0 was released with several regressions, that is, bugs that weren’t present in 4.3.0. So today we’re releasing Krita 4.4.1 with the following fixes:
If you’re using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.
NOTE for Windows Users: Microsoft has changed the way applications signed with certificates are handled. Only Digicert certificates are automatically trusted, other certificates will only be trusted if enough people bypass smartscreen to run the signed application. If you see the “Windows protected your PC” screen, press “More Info”, then select “Run anyway”. The more people do this, the earlier Microsofts machine learning algorithm will learn Krita is perfectly fine.
(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)
Note: the gmic-qt is not available on OSX.
This time, the Android releases are made from the release tarball, so there are translations. We consider Krita on ChromeOS and Android still beta. There are many things that don’t work and other things that are impossible without a real keyboard.
For all downloads:
Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos! With your support, we can keep the core team working on Krita full-time.
The post Krita 4.4.1 Released appeared first on Krita.
The FreeBSD project – which creates and publishes an operating system for a half-dozen machine architectures and packages and distributes about 40000 software products – has a quarterly report from all the various parts of that project: administration, sysadmin, ports and packages and specific technical highlights.
One small part of that vast collection of moving parts is the KDE-FreeBSD initiative, which is also a part of the KDE community. KDE-FreeBSD is a kind of a bridge project, trying to make various bits fit together.
I write “the quarterly” for KDE-FreeBSD, which is mostly based off of what other people do and which I just observe. My hat is off to the folks K-F team doing the real work; farther away in FreeBSD-land I salute Rebecca, Deb and Lara and others for doing deep technical and organizational things.
The K-F team describes itself in various ways; most recently we came up with
The KDE on FreeBSD project aims to package all of the software produced by the KDE Community for the FreeBSD ports tree. The software includes a full desktop environment KDE Plasma, an IDE KDevelop, a PIM suite Kontact and hundreds of other applications that can be used on any FreeBSD machine.
Most of the work the K-F team does on actual ports is done in the GitHub repository and coordinated on IRC in the #kde-freebsd channel on Freenode. (If you look at that repo, you see a bit yellow Dependabot warning, which is because somewhere among the 40000 packages that FreeBSD produces, there’s at least one security vulnerability: rarely one that is relevant to KDE on the FreeBSD desktop.) One interesting change in the past months is that there is now also a desktop@ team that handles things-shared-by-various-desktops. This broadens our developer base a little.
The short form is:
CMake and Ninja and other build-infrastructure maintained by KDE-FreeBSD just keeps chugging along. I submitted a handful of changes to CMake for the 3.19 release that should make it a bit better on FreeBSD, so that we need to patch it in packaging a bit less.
The big item for KDE-FreeBSD in 2020q4 is probably dealing with Python 2.7 deprecation. There is very little Python 2 left in the packaging of KDE software – I think there was a Kross plugin that used it, and we have disabled that one – but the elephant in the room is QtWebEngine, which embeds Chromium, which has a horrific custom build system that is all tied to Python 2. I have about 90% of a port to Python 3 stashed away (in public) but that got bogged down – part of the build system uses pickle to export a configuration to a later stage, and the data going into pickle is flawed, but I have not figured out where that flawed data is coming from.
This year’s annual international conference organized by TeX Users Group — TUG2020 — was held completely online due to the raging pandemic. In TUG2020, I have presented a talk on some important Malayalam typeface design factors and considerations.
The idea and its articulation of the talk originated with K.H. Hussain, designer of well-known fonts such as Rachana, Meera, Meera Inimai, TNJoy etc. In a number of discussions that ensued, this idea was developed and later presented at TUG2020.
Opening keynote to TUG2020 was delivered by Steve Matteson, about the design of Noto fonts. He mentioned that Noto was originally envisaged to be developed as a single font containing all Unicode scripts; but that was changed due to a couple of reasons: (1) huge size of resulting font and (2) the design of many South/South-East Asian characters do not fit well within its Latin font metrics.
This second point set up the stage nicely for my talk, in which we argued that a paradigm shift from established Latin font metrics is necessary in designing and choosing font metrics for Indic scripts, in particular with Malayalam as a case study.
Indic scripts have abundant conjunct characters (basic characters combined to form a distinct shape). The same characters may join ‘horizontally’ (e.g. ത്സ/thsa) or ‘vertically/stacked’ (e.g. സ്ത/stha); and Malayalam script in particular has plenty of stacked conjuncts even in contrast with other Indic scripts. This peculiarity also makes the glyph design of fonts challenging — to balance aesthetics, legibility/readability and leading/line spacing. Specifically, following the usual x-height/cap-height/ascender/descender metrics used in Latin fonts put a lot of constraints in the design of stacked conjuncts. We propose to break away from this conventional metrics and adopt different proportions of the above- and below-base glyphs (even if they are the same characters, e.g. സ in the double conjunct സ്സ), still conforming to the aesthetics of the script yet managing the legibility and leading.
Details of this study, argument and proposal can be found in the slides of the presentation available at the program details as well as the recorded talk now available on TUG YouTube channel.
The conference paper, edited by Barbara Beeton and Karl Berry will be published in the next issue of TUGBoat journal.
FreeBSD has a FUSE kernel module (Filesystems in User Space, I think), which allows it to use other filesystems – in user space – than it would normally do. Today it saved my bacon.
I do a lot of development work on a FreeBSD machine, with Linux as the target platform: that’s what you get (punishment?) for writing Linux installers, I guess. I have a handful of development and test VMs, all in VirtualBox, all with a ZFS volume (a reserved chunk of disk) as virtual disk. This normally gives me a lot of freedom in what I do with my VM’s HDDs: I can manipulate them easily from the host system. For testing purposes, that’s usually either zeroing them out or putting some partition table on them beforehand.
For whatever reason, today VirtualBox was giving me
no end of trouble: as I boot each Linux VM, it gets
a ton of I/O errors reading the disk, then ends up wedged
somewhere in what looks like Plymouth in the guest, and then VBox tells
me there was an error and gives up on the VM.
It’s not physical I/O errors, since I can read
all the data from the ZFS volume with dd, but how
can I reach the data?
Enter FUSE, along with the port fusefs-ext2. Getting the software up-and-running (for an ad-hoc need-data-now session) took two steps. For good measure, I also installed e2fsprogs, which allows me to debug ext2 (and three, and four) filesystems from the host system as well.
[ade]
# pkg install fusefs-ext2 e2fsprogs
# kldload fusefs
Voila!
My ZFS volumes are regular “disk” devices for all intents and purposes:
GEOM (the disk subsystem) recognizes that they are GPT or MBR
partitioned and puts
per-partition (“slice” in BSD jargon) files under /dev/zvol
as needed. So from the FreeBSD host I can do:
# fdisk /dev/zvol/zippy/scratch-2-medium
# fsck.ext4 /dev/zvol/zippy/scratch-2-mediump1
# fuse-ext2 /dev/zvol/zippy/scratch-2-mediump1 /mnt/tmp
To (respectively) double-check that the disk contains what I expect
(fdisk tells me it’s a GPT disk, which I should have guessed from
the p1 partition naming), fsck the filesystem (now that
VirtualBox has flipped out over it),
and mount it read-only (to get at the data I need).
To give this a teensy bit of a KDE spin, there’s also a port fusefs-smbnetfs
which exposes Samba to FUSE, and which can then be used from Dolphin
to FUSE-mount network shares – if I were a more avid Dolphin user,
and less of a now-satisfied-I-can-get-my-data-from-the-command-line user,
I might go looking if FUSE-mounting zvols in general can be done from Dolphin.
Cutelyst the C++/Qt Web Framework and ASql the ASync SQL library for Qt applications got new versions.
Thanks to the work on ASql Cutelyst got some significant performance improvements on async requests, as well as a new class called ASync, which automatically detaches the current request from the processing chain, and attaches later on when it goes out of scope.
With the ASync class you capture it on your ASql lambda and once the query result arrives and the lambda is freed and the ASync object gets out of scope and continues the processing action chain.
KDAB’s fix on a 10 year old bug raised my attention back to a note on QTcpSocket documentation:
Note: TCP sockets cannot be opened in QIODevice::Unbuffered mode.
Which is actually wrong, according to the source code, Cutelyst has been using buffered mode since always due that, so hopefully this new version will be a bit faster and consume less memory, it’s important to notice that once the Kernel tells it’s going to block QTcpSocket writes get buffered anyway.
Now talking about ASql you might notice the jump on release versions, this is because I’ve been experimenting some changes and didn’t want to write a post at each new feature.
ASql is now at the closest API I’d like it to be, unfortunately one of my goals that would be to be able to handle it’s AResult object to Grantlee/Cutelee and be able to iterate over it’s records just once, but the call QVariant::canConvert with QVariantList must succeed and the class be able to be casted to QAssociativeIterable or QSequentialIterable, which I didn’t managed to get it working in a way I like.
But AResult has hash() and hashes() methods that convert the data to a format that can be used in templating.
On the plus side I added iterators (if you have experience with iterators please review my code as this was the first time I wrote this kind of code) that also work on for ranged loops, and they also have faster type conversion methods, instead converting the data to a QVariant type, and them using QVariant to get the data out of it, one can just call toInt() which will get the int straight from the result set without checking each time if it’s an int.
Added AMigrations which is an awesome database maintenance class that is both simple and helpful to maintain database schemas.
Oh, and Cutelyst results on TechEmpower already got better thanks to ASql, hoping to see even better results when I update the tests to 2.13 that has Unbuffered and faster async handlying.
If you’ve read the first article in this series, you’ll know what full stack tracing is and why you definitely want it. This time, we’ll show you how to setup full stack tracing on your Linux system. There are two steps – first get everything configured to capture a trace, and then view and interpret the trace.
To capture a trace, we’ll be using LTTng (Linux tracing toolkit next generation) in our examples. LTTng captures tracepoints with minimal overhead. This is something you definitely want, as too much extra CPU introduced by tracing can change the system’s behavior, even causing it to fail unpredictably. Another factor in LTTng’s favor is that it’s well supported by the open source community.
LTTng was designed to record kernel level events. However, you’ll also want to use its user space tracepoints to capture application level events. That will give you consistent visibility, regardless of where execution moves throughout the software stack. User space tracepoints is critical to the setup of full stack tracing as it lets you integrate application, Qt, and kernel tracepoints together in a single view.
Start by making sure that your kernel is configured appropriately. Using make menuconfig (or its GUI cousins xconfig and gconfig), look under Kernel Hacking > Tracers and enable the following at a minimum:
CONFIG_MODULES CONFIG_KALLSYMS CONFIG_HIGH_RES_TIMERS CONFIG_TRACEPOINTS
You’ll probably also want to add these options, which are highly recommended for more complete coverage:
CONFIG_HAVE_SYSCALL_TRACEPOINTS CONFIG_EVENT_TRACING CONFIG_KALLSYMS_ALL
Note that if you are doing embedded work, you’ll need to invoke menuconfig for cross-compiling (substituting the architecture of your embedded target, of course):
$ make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig
Next thing you’ll want to do is build your kernel. That may vary based on your distribution and target and other options, but again for embedded development it will likely look something like this:
$ make ARCH=arm CROSS_COMPILE=arm-linux-
Of course, once your new trace-ready kernel is built, you’ll need to deploy it to your target.
You’ll also need the LTTng tool itself. The three main packages you need are lttng-tools for the command-line interface, lttng-modules-dkms for the kernel tracepoint modules, and liblttng-ust-dev to support user space tracing, which includes tracepoints in Qt and your application. (There are a couple of other optional packages if you need tracing from Python or Java.)
If apt-get is your package manager, installing LTTng will look like this:
$ apt-get install lttng-tools $ apt-get install lttng-modules-dkms $ apt-get install liblttng-ust-dev
If you use a different package management system, you might be able to find the equivalent commands in the LTTng docs.
Because LTTng is such a common debugging tool, other distributions may provide simpler alternatives. For example, Yocto enables LTTng by adding the following line to your local.conf:
EXTRA_IMAGE_FEATURES += "tools-profile"
To get traces from Qt APIs and internals, you’ll have to build Qt from source rather than using the pre-built libraries. KDAB has been leading the charge on enabling Qt for full stack tracing, but it’s undergoing active development and is a moving target. While our first pushed changes for Qt tracing support got merged into 5.12, you’ll definitely want 5.13 or later.
If you’re using 5.13, you’ll need some patches. These patches will enable tracing within QtQuick/QML:
If you happen to be using yocto, you can also apply the following patch to get some additional tracepoints:
If you’re using 5.14 or later, you won’t need any of these patches – they’re all merged in. Either way, the next step is to build Qt.
$ ./configure -trace lttng $ make $ make install
Again consult the docs if you need anything besides the simplest configuration. For example, if you want to keep a trace-enabled and trace-free version, you may want to set up shadow building to keep binaries and build artifacts for both configurations in separate directory trees.
Once you have Qt built, put it on your embedded target with your reconfigured kernel and you should be all set to start tracing.
LTTng does need a few options to tell it where to capture a trace and what events you want to catch. So, you’ll need a script to configure LTTng with all the needed options. As a starting point, here’s my LTTng launch script:
#!/bin/sh
if [ ! -d "/tmp/lttng" ]; then
mkdir "/tmp/lttng"
fi
lttng create -o "/tmp/lttng/$(date -Iseconds)"
# enable only the most important kernel tracepoints
lttng enable-channel kernel -k
kernel_events=(
"sched_switch,sched_process_*" "lttng_statedump_*"
"irq_*" "signal_*" "workqueue_*" "power_cpu_frequency"
"kmem_"{mm_page,cache}_{alloc,free} "block_rq_"{issue,complete,requeue}
# page fault tracing is sadly not yet available on embedded systems:
# "x86_exceptions_page_fault_"{user,kernel}
)
for event in "${kernel_events[@]}"; do
lttng enable-event -c kernel -k "$event"
done
lttng enable-event -c kernel -k --syscall -a
# enable all user space tracepoints
lttng enable-channel ust -u
lttng enable-event -c ust -u -a
# actually start tracing
lttng start
A short explanation of this shell script:
Properly configuring a trace can require fine-tuning since you are often trading off between two critical factors – the size of the trace data and the speed of the trace. If there is too much trace data, you’ll exhaust your buffers and/or disk space, which will prevent you from seeing the events you’re trying to capture. And if the trace capture is too slow, it can alter the behavior of the system. Slow traces can either mask timing problems or – even more likely – introduce new issues and prevent proper operation of the system.
What you change to impact the size of your trace is often related to its speed and vice versa. Let’s look at a couple ways that you can tinker with the configuration to make sure that your full stack trace does what you want.
By telling LTTng where to put its captured trace data, you have some control over the speed of the capture. In the lttng_start.sh script above, we invoke lttng with the “create -o” argument to store the tracing data under /tmp/lttng, which normally resides on the embedded system’s flash drive. Hence, the speed of the trace buffer disk flushes will depend on the speed of your flash. With a slow flash and a lot of data, it may be better to move the buffer onto a RAM disk to make LTTng’s buffer writing as fast as possible. You can do this by replacing the lines of directory management and session creation with this:
mount -t tmpfs -o size=128m tmpfs /tmp/lttng lttng create -o "/tmp/lttng/$(date -Iseconds)"
You may need to ratchet your buffer above 128 Mb to capture your whole trace or lower it if you need to conserve RAM. This will improve buffer write times, letting you capture more data without overflowing. Clearly though, this strategy only works if you’ve got enough RAM to spare.
Another thing you can do with the trace file is to remotely stream it to your development workstation. LTTng calls this network streaming mode (using lttng-relayd); this technique lets you capture larger and longer traces on your embedded device. Of course, your mileage may vary depending on what you’re tracing and the speed of your connection. The network has to be fast enough to move the trace data off the system before LTTng buffers overflow, so lttng-relayd is probably best reserved for fast connections (like hard-wired Gigabit Ethernet) rather than slow ones (like WiFi).
Many kernel events are called nearly constantly by a running system. Capturing tracepoints on those events can capture too much data, bogging down the system or exhausting your disk space.
To more easily locate problems, as well as ensure the trace is small enough to operate on your system properly, it’s best to capture only the essential tracepoints. In our lttng_start.sh script (setting the kernel_events environment variable), we’ve tried to provide a comprehensive event set that’s not too dramatically verbose. However, you may need to remove some of these events or add even more of your own, depending on what you’re attempting to catch – see the LTTng documentation to see how to get the list of possible trace events on your system.
Turning off tracing is as simple as running LTTng with the stop command. While it’s not completely necessary to setup full stack tracing, it does make it easier if you wrap the stop with a script that allows you to delay for a bit before stopping it. That’s because a trace with a fixed duration is often the easiest way to capture the snapshot you need.
#!/bin/sh if [ ! -z "$1" ]; then # delay stopping sleep "$1" fi lttng stop lttng destroy
We use this technique to capture the boot process: one of the nicest applications of full stack tracing.
However, sometimes what you’re trying to capture won’t happen within a fixed time window. Maybe it’s a sporadic bug, or it happens much later after the application has started. In those cases, you can also turn off the trace when initiated by the developer. Or alternatively, create a small script to periodically check for the problematic event and turn off tracing once it’s found. Here you’ll want LTTng to capture events using a ring buffer that constantly overwrites old events. That way, you can see the last several seconds prior to when you stop the trace, presumably as soon as the bug shows itself. We won’t go into that use case here; you’ll want to investigate the event record loss modes in the documentation to understand how it works and set things up properly.
You’ve now got everything configured and LTTng is ready to go. How do you capture your first trace? To diagnose problems in the boot process, add some systemd scripts to fire up the trace during the system startup.
[Unit] Description=start lttng tracing After=sysinit.target Before=multi-user.target [Service] Type=oneshot ExecStart=/usr/bin/lttng_start.sh RemainAfterExit=true [Install] WantedBy=sysinit.target
[Unit] Description=stop lttng tracing After=multi-user.target [Service] Type=oneshot ExecStart=/usr/bin/lttng_stop.sh 20 [Install] WantedBy=multi-user.target
Once these scripts are in place, you’ll want to enable the trace start/stop service, so they’ll be called during a reboot:
$ systemctl enable lttng_start.service $ systemctl enable lttng_stop.service
This will trace 20 seconds of system behavior during the boot, so you can catch whatever is slowing down your boot process.
That’s about it to setup full stack tracing! Stay tuned for our next blog where we’ll continue with how to view and interpret your traces.
If you like this blog and want to read similar articles, consider subscribing via our RSS feed.
Subscribe to KDAB TV for similar informative short video content.
KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.
The post Full Stack Tracing Part 2 appeared first on KDAB.
KDE Plasma-Desktop
The Kubuntu community are delighted to announce the release of Kubuntu 20.10 Groovy Gorilla. For this release Kubuntu ships with Plasma 5.19.5 and Applications 20.08. The desktop carries the fresh new look and gorgeous wallpaper design selected by the KDE Visual Design Group.
Cloud Ready
With the rapid growth in cloud native technologies the kubuntu community recognise that Kubuntu users need access to cloud and container technologies.
Kubuntu 20.10 also includes LXD 4.6 and MicroK8s 1.19 for resilient micro clouds, small clusters of servers providing VMs and Kubernetes.
Kubuntu 20.10 includes KDE Applications 20.08.
Dolphin, KDE’s file explorer, for example, adds previews for more types of files and improvements to the way long names are summarized, allowing you to better see what each file is or does.
Dolphin also improves the way you can reach files and directories on remote machines, making working from home a much smoother experience. It also remembers the location you were viewing the last time you closed it, making it easier to pick up from where you left off.
For those of you into photography, KDE’s professional photo management application, digiKam has just released its version 7.0.0. The highlight here is the smart face recognition feature that uses deep-learning to match faces to names and even recognizes pets.
If it is the night sky you like photographing, you must try the new version of KStars. Apart from letting you explore the Universe and identify stars from your desktop and mobile phone, new features include more ways to calibrate your telescope and get the perfect shot of heavenly bodies.
And there’s much more: KDE’s terminal emulator Konsole and Yakuake; Elisa, the music player that looks great ; the text editor Kate; KDE’s image viewer Gwenview; and literally dozens of other applications are all updated with new features, bugfixes and improved interfaces to help you become more productive and making the time you spend with KDE software more pleasurable and fun.
You probably have heard the news by now that Microsoft have released the Linux version of their new Chromium-based Edge web browser. Of course I’ve been waiting for this day ever since they announced the switcheroo to Chromium in order to bring Plasma Browser Integration to Edge users. It took Microsoft almost two decades to offer another web browser to a Unixoid desktop and this time around it’s based on KDE’s legacy – what a time to be alive!
You can already use Plasma Browser Integration just fine with Edge by installing it from the Chrome web store. Until Plasma 5.21 is out, however, it will only see it as yet another Chromium, meaning that KRunner, media controls, and so on might not map to the correct browser window or show only a generic icon.
I’ll look into getting it listed on the Edge extension store, too. If you’d like to help with that or even maintain our future store presence there, please get in touch!
The binary that runs in the background bridging the extension to your Plasma desktop has to impersonate the browser, so that for example a download job in notifications shows the correct application icon. Currently this is done using a heuristic based on user agent and parent process name. Doing that is somewhat brittle and needs to be updated whenever a new browser shows up and can’t tell the difference between stable, developer, and nightly builds. Since I can’t know what desktop file name the release version of Edge will eventually get – will it have a “stable” suffix to match the “dev” version or not? – I was looking for a way to get the browser identity some more generic way.
Fortunately, Plasma nowadays launches applications in their own cgroups, and since the bridge is started by the browser, it will be in the same cgroup as it. This way I can just look up the relevant browser desktop file from there and set a matching application name and icon by merely reading from that file without having to worry about distribution-specific packaging, special release flavors, or keeping a heuristic up to date.
I haven’t tried it with anything but Edge yet but I’m fairly certain once this change is merged it should be able to identify Firefox nightly as well as work properly with pretty much any Chromium-based browser that supports Web Extensions. This approach is yet another great example of how leveraging modern infrastructure can reduce maintenance cost and future-proof a project. Nevertheless, I’ll keep the old heuristic in place for compatibility and extend it to go looking for an “msedge” binary, too.
Translations are a vital part of software. More technical people often overlook it because they understand English well enough to use the software untranslated, but only 15% of the World understands English, so it's clear we need good translations to make our software more useful to the rest of the world.
Translations are a place that [almost] always needs help, so I would encourage you to me (aacid@kde.org) if you are interested in helping.
Sadly, some of our teams are not very active, so you may find yourself alone, it can be a bit daunting at the beginning, but the rest of us in kde-i18n-doc will help you along the way :)
This is a list of teams sorted by how many translation commits have happened in the last year, more commits doesn't mean better, even teams with lots of commits will probably welcome help, maybe it's not in pure translation but instead in reviewing, you can also check statistics at https://l10n.kde.org/stats/gui/trunk-kf5/team/
More than 250 commits
Azerbaijani
Basque
Brazilian Portuguese
Catalan
Estonian
French
Interlingua
Lithuanian
Dutch
Portuguese
Russian
Slovak
Slovenian
Swedish
Ukrainian
Between 100 and 250 commits
German
Greek
Italian
Norwegian Nynorsk
Spanish
Between 50 and 100 commits
Asturian
Catalan (Valencian)
Czech
Finnish
Hungarian
Indonesian
Korean
Norwegian Bokmal
Polish
Vietnamese
Chinese Traditional
Between 10 and 50 commits
British English
Danish
Galician
Hindi
Icelandic
Japanese
Malayalam
Northern Sami
Panjabi/Punjabi
Romanian
Tajik
Chinese Simplified
Between 0 and 10 commits
Albanian
Belarusian
Latvian
Serbian
Telugu
Turkish
No commits
Afrikaans
Arabic
Armenian
Assamese
Bengali
Bosnian
Bulgarian
Chhattisgarhi
Crimean Tatar
Croatian
Esperanto
Farsi
Frisian
Georgian
Gujarati
Hausa
Hebrew
Irish Gaelic
Kannada
Kashubian
Kazakh
Khmer
Kinyarwanda
Kurdish
Lao
Low Saxon
Luxembourgish
Macedonian
Maithili
Malay
Maltese
Marathi
Nepali
Northern Sotho
Occitan
Oriya
Pashto
Scottish Gaelic
Sinhala
Tamil
Tatar
Thai
Tswana
Upper Sorbian
Uyghur
Uzbek
Venda
Walloon
Welsh
Xhosa
P.S: Please don't mention web base translation workflows as comments to this blog, it's not the place to discuss that.
KDAB has released KD Chart 2.7.2, the final release in the KD Chart 2.7 series. This is a very minor release; however, it’s significant in that it may be the final release of KD Chart that will support Qt 4.
KD Chart is a comprehensive business charting package with many different chart types and a large number of customization options. We are constantly improving the package, and have been doing so for years.
The following changes come with KD Chart 2.7.2:
Find out more about KD Chart here.
Login to your KDAB customer account or create a KDAB customer account here, to download a GPL license of KD Chart.
To discuss licensing options, contact us at sales@kdab.com.
If you like this blog and want to read similar articles, consider subscribing via our RSS feed.
Subscribe to KDAB TV for similar informative short video content.
KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.
The post KD Chart 2.7.2 released! appeared first on KDAB.
