KDE

As some of you might know, I started the application Cantor in KDEedu a couple of years ago, since I didn’t want to rely on comercial computer algebra systems during my studies, and because all the free alternatives seemed to lack a decent graphical ... [More] interface. Since then Cantor has grown to support all kinds of different mathematical languages due to numerous contributors from all over the world. Unfortunately, lately I’ve found myself with less and less time to spend on Cantor especially since I’ve started working on my Phd. Luckily for me others have made sure that the project keeps going, and have for example ported it to KF5 etc. So now I think its time for me to step down as the maintainer of Cantor, and hand over the reins to Filipe Saraiva, who has been with the project for a long time now, and was the main driving force behind the Python backends and the Frameworks port (among other stuff). So I’d like to wish Filipe, and the Cantor project all the best, I know he is up to the task, while I take on more of an observer role to its development. [Less]

A new widget called KNewPasswordWidget has been added to the KWidgetsAddons framework, starting from 5.16. I decided to create this widget because sometimes you cannot just use KNewPasswordDialog to ask the users for a new password. This is the case ... [More] when you need to add further options to the same dialog. This widget is meant to be easily embedded in such a custom password dialog, without having to code it from scratch. You get for free: Password and verification input fields Action to toggle the password visibility Strength meter bar (which you can hide) A signal to connect to, in order to update the dialog stuff (e.g. enabling/disabling the OK button). You can also set a background “warning” color, displayed when the verification password does not match (feature borrowed from KeePass). So the following is a custom password dialog with a KNewPasswordWidget and a couple of checkboxes: Code sample is available in the doxygen documentation of the widget. [Less]

At the LibreOffice conference in Aarhus, Denmark, last September, I talked about the future of ODF (slides). OpenDocument, the file format for office applications, is currently at version 1.2. What should go into version 1.3 and later? I presented ... [More] nine ideas and measured the applause that each idea got. The results of the measurement can be seen in the table at the bottom of this post. (The applause volume was read by playing the audio of the presentation in Audacity.) applause meter OpenDocument exists to make life easier for computer users and software developers. A well documented file format leads to a more diverse market: if the file format is not secret or changing constantly, everyone can write software for it. The standard is not created in a vacuum. Good ideas can come from anyone and users of ODF software have a say in what improvements are made to the standard. The ideas in this document are just a few possible improvements to the standard and the ecosystem. The ODF Technical Committee is always open for your ideas. Testing and certification ODF 1.2 is a very complete office file format. There is no software that supports all ODF 1.2 features. Some parts are handled differently in different packages. An overview of how well each package supports which features is missing. The ODF plugfest is a reccurring event where ODF software is tested. This event is held at a physical location. To test all parts of ODF, a lot more testing is needed. That is why there is a need for a continuous ODF plugfest online: a website where people can test all office suites. People would be able to upload files and see how they render in the different packages. The site would offer a way to define tests that say unambiguously if a feature is supported well. The site could feature a live score for each ODF package. At the last plugfest a rough design for ODF plugfest online was made. Currently, that design is being worked out. Profiles Writing valid ODF software is very easy: the specification says: An OpenDocument producer is a program that creates at least one conforming OpenDocument document [...] So it can be argued that a copy command is an OpenDocument producer. Making an ODF reader seems harder: An OpenDocument consumer is a program that can parse and interpret OpenDocument documents according to the semantics defined by this specification [...] however: it need not interpret the semantics of all elements, attributes and attribute values. There is currently no straightforward way to define which parts of the specification are supported by a particular implementation. One could list all supported elements and attributes. An idea for current and future versions of ODF is to define profiles. Each profile contains a list of features. ODF software can then comply to one or more profiles. Scripting language Up until version 1.2 of ODF, the syntax and semantics of formulas in ODF was not specified. Formulas were implemented in the http://openoffice.org/2004/calc namespace: table:formula="oooc:=SUM([.B5:.B12])" Since ODF 1.2, spreadsheet formulas are written in an OpenDocument namespace urn:oasis:names:tc:opendocument:xmlns:of:1.2: table:formula="of:=SUM([.B5:.B12])" Automated office documents require scripting or macros. ODF documents can contain macros, but the programming language for the macros has not been specified. The points where macros access the document are specified, but no language is chosen. In practice, macros created in one package do not work in another package. Webpages can, in theory, also use different programming languages. But in practice, only JavaScript is supported across browsers. In office suites no interoperable choice is available. Requiring support for one particular programming language in the specification might change this situation. Real-time change tracking ODF supports change tracking: a user edits a document and the situation from before and after the edit is stored in the document. Etherpad popularized the idea of working with multiple people at once on one document. WebODF was the first ODF package that supported this style of working on ODF documents. OX Documents allows turn-based editing with fine granularity. MS Office and Google Docs also support it. In all these packages, everyone has to use the same software. The edit history is not available in a standard format. The Advanced Document Collaboration subcommittee is working on creating such a standard. It is highly anticipated but a lot of work. If you are up to the challenge, please join this effort. Upgrade / downgrade instructions ODF 1.0, ODF 1.1, ODF 1.2 and ODF 1.2 Extended are the current versions of OpenDocument. Many ODF 1.2 documents do not contain features that are specific to ODF 1.2 and could be converted to an older version of ODF without information loss. There is no shared software or documentation for 'upgrading' or 'downgrading' ODF documents. If there was, it would be trivial for software that supports ODF 1.1 to add support for reading (when no ODF 1.2 features are used) and writing ODF 1.2 documents. The task is not terribly hard, because nearly all features that are shared between 1.1 and 1.2 are exactly the same in both versions. HTML storage format The best way to send somebody an ODF file for reading is to wrap it in a PDF file. That way, you share the original file and you can be sure that the receiving party can view it. It's a fact that nearly every tablet, phone and computer has a PDF viewer. Support for ODF is less pervasive. Alternatively, one could wrap an ODF file in an HTML file. The HTML would be a static rendering of the document using HTML elements. The original ODF would be available via a 'save as' button (implemented as a link with a data URL). If you want someone to work with you on an ODF file, that person also needs an ODF editor. WebODF shows that it is possible to create an ODF editor that takes up only a few megabytes. Adding an ODF file and the editor for it into and HTML file that one can send out, would bring ODF everywhere instantly. Such a mix of HTML and ODF would be nice to have. But is it something for a specification or for a software project? Normalization Software developers rarely use ODF for writing documents. They prefer HTML, Markdown, or plain text files. One explanation is that developers like to store their work in version control systems like Git. In these systems, commits are important. A commit shows the difference between versions of a file. These difference can be shown best for text files. The text files are usually edited in plain text editors. But ODF is not a simple format and is usually edited in an office suite. Everytime the document is saved after an edit, it changes in many places. The clearest example of this are the automatic styles. The names of automatic styles are only used internally and the precise value has no meaning. So with ODF, the number of changes that developers see in their commits is confusingly large. It is mostly noise. A solution would be to write rules to have a standard way to write things like automatic styles. Additionally, choices like how to indent the XML and how to order the attributes and elements have to be made and standardized. When that is done, developers will warm more to using ODF. The convenience of a powerful well-structured file format can win over the obscure terseness of Markdown. Standardize handling of invalid files The HTML specification has a very long description of how to parse HTML. Parsing HTML is complicated because browser developers think that even HTML files with errors in them should be read. And if that's a requirement, it's best to standardize how to deal with errors. Of course when invalid syntax is standardized, that syntax is now also valid. The result is a very, very complicated syntax. An alternative, simple and strict syntax also exists: XHTML. There is a high software development cost to entering the browser market because of the complicated syntax. ODF does not have a long chapter on parsing and it should not have one. This idea is not a serious suggestion. In ODF, rules for parsing invalid files are not needed because nearly all ODF files are created with high-level software. HTML is often written in simple text editors where it is easy to make syntax mistakes. Condoning such mistakes is not a good idea for ODF. Theme support ODF has support for styles. The styles shown in the user interface are called 'common styles'. Swapping out common styles for other common styles gives a document a different look. The names for the common styles are not standardized. A standardized set of common style names would make it easier to swap out style files (themes). Within an organization, one might well choose for a common set of names for styles. Web applications like Wordpress can have themes because the components of the pages are defined by the software. In ODF, there is a set of names for the components in a presentation. Sets of names for common styles could also be added. Applause! The audience at the LibreOffice conference had preferences. Real-time collaborative editing was the clear winner. Theme support was the runner up and testing and certification and normalization tied for the third place. Idea Applause No applause -48 Maximum applause -4 Testing and certification -6 Profiles -9 Scripting language -9 Real-time change tracking -3 Upgrade / downgrade instructions -10 HTML storage format -48 Normalization -6 Standardize handling of invalid files -48 Theme support -5 This was the opinion of the room in Aarhus. I'm sure there are many different ideas and preferences. Some ideas are already being worked on and some are waiting for someone to step in and help. the presentation in Aarhus watch the presentation [Less]

This is the third and final part of a little blog series about a new chunking algorithm that we discussed in ownCloud. You might be interested to read the first two parts ownCloud Chunking NG and Announcing an Upload as well. This part makes a couple ... [More] of ideas how the new chunking could be useful with a future feature of incremental sync (also called delta sync) in ownCloud. In preparartion of delta sync the server could provide another new WebDAV route: remote.php/dav/blocks. For each file, remote.php/dav/blocks/file-id exists as long as the server has valid checksums for blocks of the file which is identified by its unique file id. A successful reply to remote.php/dav/blocks/file-id returns an JSON formatted data block with byte ranges and the respective checksums (and the checksum type) over the data blocks for the file. The client can use that information to calculate the blocks of data that has changed and thus needs to be uploaded. If a file was changed on the server and as a result the checksums are not longer valid, access to remote.php/blocks/file-id is returning the 404 "not found" return code. The client needs to be able to handle missing checksum information at any time. The server gets the checksums of file blocks along the upload of the chunks from the client. There is no obligation of the server to calculate the checksums of data blocks that came in other than through the clients, yet it can if there is capacity. To implement incremental sync, the following high level processing could be implemented: The client downloads the blocklist of the file: GET remote.php/dav/blocks/file-id If GET succeeded: Client computes the local blocklist and computes changes If GET failed: All blocks of the file have to be uploaded. Client sends request MKCOL /uploads/transfer-id as described in an earlier part of the blog. For blocks that have changed: PUT data to /uploads/transfer-id/part-no For blocks that have NOT changed: COPY /blocks/file-id/block-no /uploads/transfer-id/part-no If all blocks are handled by either being uploaded or copied: Client sends MOVE /uploads/transfer-id /path/to/target-file to finalize the upload. This would be an extension to the previously described upload of complete files. The PROPFIND semantic on /uploads/transfer-id remains valid. Depending on the amount of not changed blocks, this could be a dramatic cut for the data that have to be uploaded. More information has to be collected to find out how much that is. Note that this is still in the idea- and to-be-discussed state, and not yet an agreed specification for a new chunking algorithm. Please, as usual, share your feedback with us! [Less]

You guys are awesome. Thanks for contribution. RJ Quiralta with Autumn  Martin Klapetek with Fallen Leaf Timothée Giet with Flying Konqui Dmitri Popov with Colorful Cups Maciej Wiklo with by the water And last but not least Risto S with A Path, Cold Ripple, Darkest Hour, Kite, One Stands Out and Summer

Hi Folks! Later but not too late we just began our preparations for the release candidate alpha and change the repos to the kde place, so we have a lot of tasks and we are pleased with the help and feedbacks that we got, thanks to you guys we are ... [More] finally advancing in a rapid pace to make the 3d part working properly =]. Now we are working on : Make the final code cleaning to move Make some little mods on icons set and interface *(Hope finish still in November) Preparing to open GCODE files *( STL ready) Implement some little comands as speed control Write more tips and the maintenance 3d print module Solve some issues with Repetier binary Make it work with Marlin firmware Do more and more and maxxxximummmm of printer tests that we can More manobrability tests with diferant users Complete the english translation Well…we HOPE laush the firts alpha release candidate until December and the alpha at Campus Party Brasil as the oficial printer host of the event *(Yes…. IF we get the 3D working smootly…it WILL be use by the oficial printers of Robotic Arena YAY!!!) Other great news is just STUNNING!!! We got our very first SPONSOR!!! “Filamentos 3d Brasil” is sponsoring us giving filament for our tests so we don’t need to worry with it any more =] , thanks a lot people! If you wanna know more about they so check out the website =] . This is it for today, soon we will be back with more stuff! [Less]

So, first of all, this is all very much work-in-progress and highly experimental. It’s related to the work on screen management which I’ve outlined in an earlier article. I ran a few benchmarks across our wayland stack, especially measuring ... [More] interprocess communication performance when switching from X11 (or, in fact XCB and XRandR) to wayland. I haven’t done a highly scientific setup, just ran the same code with different backends to see how long it takes to receive information about screens connected, their modes, etc.. I also ran the numbers when loading the libkscreen backend in-process, more on that later. data The spreadsheet shows three data columns, in vertical blocks per backend the results for 4-5 individual runs and their mean values. One column for the default out-of-process mode, one with loading the backend in process and one showing the speedup between in- and out-of-process of the same backend. The lower part contains some cross referencing of the mean values to compare different setups. All values are nano seconds. 2x My results show a speedup of between 2 and 2.5 times when querying screen information on X11 and on wayland, wayland being much faster here. The qscreen and xrandr backends perform pretty similar, they’re both going through XCB. That checks out. The difference between wayland and xrandr/qscreen can then be attributed to either the wayland protocol or its implementation in KWayland being much faster than the corresponding XCB implementations. But, here’s the kicker… in- vs. out-of-process The main overhead, as it turns out, is libkscreen loading the backend plugins out-of-process. That means that it starts a dbus-autolaunched backend process and then passes data over DBus between the libkscreen front-end API and the backend plugin. It’s done that way to shield the client API (for example the plasma shell process or systemsettings) from unsafe calls into X11, as it encapsulates some crash-prone code in the XRandR backend. When using the wayland backend, this is not necessary, as we’re using KWayland, which is much safer. I went ahead and instrumented libkscreen in a way that these backends are being loaded in process, which avoids most of the overhead. This change has an even more dramatic influence on performance: on X11, the speedup is 1.6x – 2x, on wayland loading the backend in-process makes it run 10 times faster. Of course, these speedups are complementary, so combined, querying screen information on wayland can be done about 20 times faster. While this change from out-of-process to in-process backends introduces a bit more complexity in the library, it has a couple of other advantages additional to the performance gains. In-process means that debugging is much easier. If there are crashes, we do not hide them anymore, but identify and fix them. It also makes development more worthwhile, since it’s much easier to debug and test the backends and frontend API together. It also means that we can load backend plugins at the same time. I’ve uploaded the benchmark data here. Before merging this, I’ll have to iron out some more wrinkles and have the code reviewed, so it’s not quite ready for prime-time yet. [Less]

Upstream link to changelog: KDE Applications 15.08.3 Please help test KDE Applications 15.08.3 in Wily. Once this has been tested and placed in Wily backports, I will backport it to Vivid. As always do NOT test on a production machine. Well you ... [More] can, but I am not responsible for any explosions Thanks for your help! To test: sudo add-apt-repository ppa:kubuntu-ppa/staging-kdeapplications sudo apt-get update && apt-get dist-upgrade Do things as you normally do, and report back any crashes or unexpected behavior. Try and run as many applications as you can and or are familiar with ( I know there are alot!) It is also good to test the changes from the above changelog. Once you are done testing it is very important to remove the staging PPA. sudo apt install ppa-purge sudo ppa-purge ppa:kubuntu-ppa/staging-kdeapplications Thank you!! If you find any of my work useful, please consider a donation or become a patreon! I can no longer sustain working without an income. If patreon works I can continue all of my (K)ubuntu and KDE contributions ( a full time job in its current state + tons of overtime!) Patreon for Scarlett Clark (me) A big thank you to the few whom have contributed. Still needs lots more to consider this a success. Thank you for your support. [Less]

Packages for the release of KDE’s Plasma 5.4.3, bugfix Release for November, are available for Kubuntu 15.10. You can get them from the Kubuntu Backports PPA. Please report any bugs you find. Bugs in the packaging should be reported on Launchpad. ... [More] Bugs in the software should be reported to KDE. Or ping sgclark in #kubuntu-devel. To update, follow the Software Repository Guide to add the following repository to your software sources list: ppa:kubuntu-ppa/backports Special thanks to sgclark for packaging this update and to testers who hang out on the #kubuntu-devel IRC channel.   [Less]

Plasma5.4.3 Bugfix release. KDE Upstream link to changelog: Plasma 5.4.3 To install add ppa:kubuntu-ppa/backports by folling the instructions found here: Adding and using repositories in Kubuntu If you find any issues please hunt me down in the usual ... [More] places. Vivid backports will be done in the next day or two. Enjoy! If you find any of my work useful, please consider a donation or become a patreon! I can no longer sustain working without an income. If this works I can continue all of my (K)ubuntu and KDE contributions ( a full time job in its current state + much overtime!) Patreon for Scarlett Clark (me) [Less]