Cantor 18.12 – KDE way of doing mathematics


Curious to read about Cantor on LabPlot’s homepage? This is easy to explain. Cantor has got quite a lot of development in the last couple of months, also with great contribution from LabPlot developers. There is a close collaboration between these two KDE projects which we hope to intensify even further in future and to make better use of the common code and human resources in order to provide a strong computational and visualization platform for scientific purposes.
In this blog post we want to highlight the more striking new features in Cantor 18.12 that was recently released. Since Cantor can run embedded in LabPlot (see the LabPlot 2.3 release announcement for couple of examples), all the features described below are of course also available for users using Cantor from within LabPlot.
We invested quite a lot into improving the overall usability of Cantor’s worksheet. First improvement we want to mention is the handling of long running and waiting commands. In the past, when executing multiple commands at the same time, there was no feedback for the user which command is being calculated right now and which commands are waiting. In the current release we highlight the currently calculated command entry with a small animation of the prompt. The pending (meaning, queued but not being calculated yet) command entries are also highlighted so the user has the full picture of the processing status.
-
- Login or register to post comments
Printer-friendly version
- 1839 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
Android Document Scanning and Developer-Focused TV Box
| Improving the security model of the LVFS
There are lots of layers of security in the LVFS and fwupd design, including restricted account modes, 2FA, and server side AppStream namespaces. The most powerful one is the so-called vendor-id that the vendors cannot assign themselves, and is assigned by me when creating the vendor account on the LVFS. The way this works is that all firmware from the vendor is tagged with a vendor-id string like USB:0x056A which in this case matches the USB consortium vendor assigned ID. Client side, the vendor-id from the signed metadata is checked against the physical device and the firmware is updated only if the ID matches. This ensures that malicious or careless users on the LVFS can never ship firmware updates for other vendors hardware. About 90% of the vendors on the LVFS are locked down with this mechanism.
Some vendors have to have IDs that they don’t actually own, a good example here is for a DFU device like the 8bitdo controllers. In runtime mode they use the USB-assigned 8bitdo VID, but in bootloader mode they use a generic VID which is assigned to the chip supplier as they are using the reference bootloader. This is obviously fine, and both vendor IDs are assigned to 8bitdo on the LVFS for this reason. Another example is where Lenovo is responsible for updating Lenovo-specific NVMe firmware, but where the NVMe vendor isn’t always Lenovo’s PCI ID.
|
Programming: Vim, Qt Shader and Python
| Games: Pygame, The Long Dark, DXVK and Shovel Knight
|
Recent comments
3 hours 36 min ago
3 hours 54 min ago
3 hours 59 min ago
4 hours 53 min ago
11 hours 8 min ago
11 hours 55 min ago
12 hours 5 min ago
12 hours 13 min ago
12 hours 35 min ago
18 hours 4 min ago