A little over a year ago I published an instant-workstation script for FreeBSD. The idea is to have an installed FreeBSD system, then run a shell script that uses only base-system utilities and installs and configures a workstation setup for you.

The script lives on GitHub and has had some pull requests submitted and issues filed over the course of a year. I’ve gone and implemented them, so the script is slightly longer and more involved now.

• Support for more operating environments has landed
• Support for application installations has landed (this covers basically my own application needs: I tick all the boxes and go to the races, but the support in general is there if someone wants to add, say, Haskell development to the mix)
• VMWare support was submitted
• SDDM / polkit configuration has been introduced so you can shutdown / reboot from inside the KDE Plasma environment via the Leave menu. (That’s a tip from Shurik, slightly adjusted to be less overall-permissive, following the polkit manual)

The script is updated intermittently when new PRs come in, or when I have to reinstall a machine and things do not behave the way I think they should. If you want a quick live KDE Plasma experience with FreeBSD, head on over to FuryBSD which does live ISO images with a variety of environments.

 I been posting then on Instagram and Twitter 

https://www.instagram.com/p/CFNMjTMhu4E/?igshid=u3szn5uau64y

@pinheirokde in both cases

Small videos are posted there of what I did  with my 2 hour a day budget... 

After almost a year’s work and a month in beta, we’re happy to announce the availability of the next release of LabPlot: version 2.8 is at last here.

In this release announcement we will highlight the most important new features, so be prepared for a long post! For a shorter version of what has been done, check the ChangeLog… Or why not directly download the new release and experience LabPlot 2.8 for yourself?

Educational Data Sets

In 2.8 we made it easier to access many online resources that provide data sets for educational purposes. These data sets cover a variety of different areas, such as physics, statistics, medicine, etc., and are usually organized in collections. In this first release of this feature in LabPlot we have included five collections with over 2000 documented data sets:

• JSE Data Archive is a data archive provided by the Journal of Statistics Education.
• The R data sets are a collection of over 1300 data sets that were originally distributed alongside the statistical software environment R and some of its add-on packages.
• Australasian Data and Story Library (OzDASL) is a library of data sets and associated stories maintained mostly by teachers of statistics in Australia and New Zealand, with emphasis on data sets with an Australasian context.
• StatLib is an archive maintained at Carnegie Melon University.
• The Data And Story Library (DASL) is a library maintained by Data Description, creator of the data analysis and exploration software “Data Desk”.

The import dialog for data sets allows for an easy navigation and search in the thematically grouped categories and sub-categories of the data sets. The short video below demonstrates this and how to actually import a set:

For more details on this new feature see the dedicated blog post.

Worksheet

Next up: plotting capabilities. This release comes with two new worksheet objects – reference lines and image elements. Reference lines can be freely positioned on the plot to highlight certain values in the visualized data. Image elements let you add an image to the plot or worksheet. The example below, showing statistics of the amount of debris created and left floating in space since 1961, demonstrates the usage of these two new objects:

For more information about the data shown here and about the new worksheet elements see this blog post.

Spreadsheet

The spreadsheet provides descriptive statistics for the data sets. We extended this information and added the calculation of quartiles, trimean and of the statistical mode:

The normalization methods list has also been extended and we added a couple of new frequently used methods:

Furthermore, we added another small feature to the spreadsheet: the calculation of Tukey’s ladder of powers:

Data Analysis

LabPlot supports different analysis methods, such as fitting, smoothing, Fourier transformation, etc. The fitting capabilities have been improved with an extended dialog.

For smoothing, we added the calculation of rough values. The difference between the approximating smooth function and the original data is called “rough” in this context (data = smooth + rough). We calculate and expose the rough values and  made it possible to visualize them and to check the goodness of the smoothing process. The example below demonstrates the first two plot iterations of a moving average smoothing algorithms applied to the original data. The second plot shows the corresponding rough values for both iterations:

Computer Algebra Systems

Thanks to the work carried out on Cantor during the last months, in this release of LabPlot we have been able to add compatibility with Jupyter project files:

Contrary to Cantor which is able to open and save .ipynb files (Jupyter notebooks), LabPlot allows only to open such projects. After loading a notebook, its content is shown in a computer algebra worksheet in LabPlot. The modified CAS Worksheet can be saved in a native project file together with other native objects, such as spreadsheets, worksheets, etc.

It was already possible to create new CAS Worksheets in LabPlot wherever the machinery of Cantor was used internally — see this blog post for couple of examples. But it was not possible to open Cantor’s project files (*.cws file extension) directly . We have corrected this and the handling of Cantor project files is similar now to the handling of Jupyter projects described above.

The screenshot below shows an Octave project from Cantor’s collection of example projects for different computer algebra systems:

Settings for Units and Decimal Separator

It’s possible now to globally define which units (metric or imperial) and which decimal separator (dot, comma, Arabic comma, system default) have to be used everywhere in the application. The settings dialog was extended for this:

Better Support on macOS

More effort has been put into the macOS version of LabPlot. Besides many small macOS specific fixes, we have also added support for the touch bar that is available on newer MacBook Pro models. In the touch bar we expose the most frequently used actions for the different objects. The screenshot below shows the touch bar with worksheet actions:

A tab bar, that’s easy, isn’t it?

You would think so… But this topic seems like an everlasting journey ;=) Or running in circles…

A bit of history

The evil past without tabbing (long long ago, far far away…)

Kate did a long time not have tabbing. My initial design was a MDI editor with a list/treeview for the file selection.

We had splitting very soon and some when in-between we had tabs around the split areas (like in good old Konqueror). But we had no tabs for documents. The tabbing for the split views was removed again later, as close to nobody understood or even found it ;)

Here is some good old Kate, (alias Kant) screenshot from the good old KDE 2.2 times.

As you can see, that is the ancient past. We used CVS, the Real Player was a thing on Linux (I think I had some ‘The Secret of Blue Water’ soundtrack as rm files) and I was young and friendly and added nicknames everywhere to my copyrights.

The good old times with different tabbing variants (KDE4 based Kate)

The KDE4 versions of Kate had two plugins to handle tabbing documents. No joke, we had more than one for that ;=) I have actually no real memory how they behaved, my cloudy memory just tells me “like some tab bar”. But yes, there were differences that made it worth to have two plugins doing this, as nobody had the time to unite them. For people interested, this commit removed them.

Below both variants that were available in action.

I must confess, I can’t remember if I ever really enabled them on my normal installation for anything beside a short test.

The initial KDE Frameworks 5 base Kate versions - LRU is cool

During the Kate/KDevelop/Skanlite Sprint in 2014, we implemented the tab bar as used in Kate up to and including the 20.04 release. Or more precise, Dominik implemented it and I raged around about how cool LRU is. That I work on static analyses for cache replacement policies might have had some influence…

This tab bar shows the documents you are working on in a least recently used (LRU) fashion. It only shows as many tabs as fit into the tab bar, since we want to avoid horizonal scrolling (it does not scale). If not all documents fit into the tab bar, just use the Documents tab on the left, or the quick open icon in the view space tab bar bar on the right to to launch quick open.

Here some slightly later screenshot from after Akademy 2014. Looks already more or less like we kept it up to 2020.

Dominik further fine-tuned that over the year, the styling got even closer to a normal tab bar and tabs got movable.

This is the tab bar variant I actually really start to use. Perhaps because it was “default” on and I liked the LRU behavior.

Kate 20.08 - the return of the “normal” tabbing

Whereas some people seemed to be happy with the LRU tabbing, we got on the other side a lot complaints about it in bugs and other feedback. For many people, it was just to alien compared to the tabbing you have close to everywhere else.

If more users liked it the LRU variant than not is hard to tell, as we normally get only feedback that is “negative”. Unhappy users are unfortunately in most cases more eager to send some mail (or file a bug, why would you file one, if you are happy with the behaved…)

Tomaz stepped up in this merge request to rectify the situation and port our tabbing to a generic QTabBar based version. Beside solving some minor styling issues, this provides a more “common” tabbing like people are used from their browser.

I was ok with this and we merged this before the Kate 20.08 release.

And then we were happy forever… Or not..

Kate 20.12 - the return of LRU, yes really, it is back, but optionally

As we thought, not all people were completely happy with the new behavior.

I already noticed during my own work (I normally use some Manjaro Linux with the default installed Kate version for my daily work) that the normal tabbing sometimes is lacking, if you are used to LRU and now the most recently used stuff isn’t staying visible, but you have more or less just the open order in the tab bar and are scrolling around a lot during switching.

The same issue got expressed in multiple bug reports.

Therefore, I re-implemented the LRU behavior, but still using the current QTabBar implementation and no custom widget. And this is now optional, default off, you can just configure some limit for the number of tabs you want to have. As long as you set no limit, the normal tabbing behavior will be used, if you set some limit, the old LRU algorithm is used.

See this merge request for the concrete code changes.

No screenshot here, as it just looks 1:1 the same as the above 20.08 screenshot, just the number of tabs is limited and they are replaced instead of the scrolling arrows you have otherwise. This is actually a feature, as the slightly different styling was one of the issues fixed with the 20.08 change.

Is this now the end? I guess or hope not, as there is never the “final” fix or solution for anything that is still in active use. And I hope Kate stays in active use.

But I think, Kate 20.12 will have the best of both worlds.

For the average user, the default tabbing behavior is just like they know it from e.g. their browser. My change should not affect this use case at all, zero behavior changes.

For people like me, they can switch over to the LRU behavior (and now even configure how many LRU tabs they want to have visible).

But hey, I want to have…

You have more needs for tabbing or other stuff? You can code? Show up and provide some patch to us on our GitLab instance.

If you have feedback on this post, use this thread on reddit.

Here are some of my impressions of this year’s Akademy, KDE’s eight day annual conference. While all virtual this time for obvious reasons, this nevertheless came much closer to the real thing than I had expected, and was in no way less intense or productive for me.

Going Virtual

By and large the technical infrastructure, both of the event and my own, held up. Over the course of the event a number of ideas for improving remote event experience came up though, such as those for Plasma collected in task T13570.

Some of the important social interactions during a physical events are missing at a virtual event, the creation of the hallway BBB rooms helped a lot with this though. It’s still not the same as having dinner with a small group for example, but it nevertheless enabled discussions on random topics, fun and hacking for hours after the official schedule had ended for the day.

Another very positive aspect is that the virtual setup not only enabled many people to participate that otherwise might not have been able to attend at all, but also let people say hello again that weren’t that active in recent years.

As said before we should find a way to retain remote participation in post-pandemic physical events for this reason.

Talks, Meetings and Discussions

It’s impossible to cover everything that happened in a single post, so as a start here is an unordered collection of personal highlights or topics I have been involved with. Where available there’s links to more detailed reports, for some of these I’ll also try to write more about here eventually.

• We looked into a few KUserFeedback issues as well as ways to improve analysis of the data we got so far, see David Edmundson’s blog post.
• At the KDE PIM BoF, we celebrated the merge of the Etesync GSoC project for the 20.12 release, learned about cool new work that André and Ingo are doing on using USB password tokens for crypto keys and discussed the ongoing work of untangling the codebase to make it easier accessible. Meeting notes are in the wiki.

• Dan, Kai and I came up with a plan on how to generalize the schema.org extraction and data model code in KItinerary, enabling a much wider use of these components in Plasma Browser Integration and KMail, independent of travel documents.
• Cornelius chaired a BoF on efforts to investigate power consumption of software, and achieve certification for the German eco label “Blauer Engel”. An interesting greenfield topic that could still benefit from some foundational work on techniques and tooling IMHO. Ordered some parts for this, let’s see :)
• We discussed requirements for unifying the various mapping and translations for countries, regions, timezones, etc we have all over KDE’s code (such as this), aiming to find our what we would need to unify this in a low-tier framework like KI18n. I yet have to finish writing this up and putting it into the corresponding task.
• We are aiming at another dedicated sprint for progressing the KF6 work later this year (meeting notes).
• REUSE compliance was a recurring topic, special thanks to Andreas for driving this and people like Christophe for doing a huge amount of work in this area as well. This isn’t a particularly attractive work, but it’s very important to ensure the continued access and usability of all our work as the license landscape evolves, way beyond KDE’s upcoming 25th birthday.
• Following the discussions at the Android BoF, I’ll be looking into upstreaming the CMake AAR support to ECM, as well as turning KAndroidExtras into a proper framework.
• I had multiple good discussions with KDE sysadmins on how to proceed with deploying the update of the OSM raw data server on maps.kde.org, so we’ll hopefully be able to complete this in the not too distant future.
• I was hoping to come to a decision on where to move the barcode scanning functionality to counter the duplication of that we have in a few apps right now. We only got this down to a few possible candidates though that still need closer evaluation (KF5::Prison, KF5::Purpose, Kirigami Addons, XDG portals).
• The slides of my talk on how we can make use of Wikidata and OpenStreetMap data in our applications have been uploaded to the talk page.
• It wasn’t all tech talk though, I’d like to especially mention the implicit bias training and Valorie’s keynote on burnout that put spotlights on topics we all should be aware of.

Akademy Awards

This year I had the honor of picking the Akademy Award winners together with Marco and Nate. Finding candidates isn’t hard, making a choice among them more so. I’m quite happy with our selection though:

• Bhushan for his work on Plasma Mobile.
• Carl for his work on KDE’s web presence.
• Luigi for his efforts around the localization of our software.
• And of course this year’s Akademy team who have faced a once-in-a-century situation in organizing our yearly gathering.

Thank you!

A big thank you to everyone who helped to make this event possible, despite this year’s obstacles!

Akademy is immensely valuable, the above is just a tiny glimpse into the productivity we achieve when having everyone together for a week, even if just virtual, not to mention the big motivational boost we get out of this.

If this is something you’d like to support, check out the donation options of KDE e.V..

Kontrast is a contrast checker available for desktop and mobile devices. You can use Kontrast to choose background and text color combinations for your website or app that your users will find easy to read. Kontrast can help you improve the accessibility for your site or app for people with vision problems.

Kontrast won’t catch all the problems, but it should still be very helpful to catch many issues early on, when designing your interface.

I released the first version of Kontrast earlier this month.

Another big feature of Kontrast is the possibility to generate random color combinations with good contrast. These colors can be saved in the application itself, so that you can keep a particularly good color combination for later use.

Kontrast is available for the Linux desktop, Plasma Mobile and there is also a Beta version for Android.

This application is built using the excellent Kirigami framework.

You can download and install Kontrast from Flathub and a nightly build is also available in binary factory.

The tarball is available here and is signed with my gpg key 14B0ED91B5783415D0AA1E0A06B35D38387B67BE.

Future Improvements

Future plans include improving the Android build, possibly release a stable build of the Android version and also create a QtQuick-based color picker that is better integrated with the application.

Frameworks 5.75 => KSyntaxHighlighting Themes

Last week I reported about the currently done changes to the color themes in KTextEditor (Kate/KWrite/KDevelop/…). As this was just the half finished job, I felt somehow motivated to work on the remaining parts.

I had more time this week to work on it than thought and finalized the transition from the old “schema” stuff we had to pure use of KSyntaxHighlighting themes. This is a rather large change, I guess one of the largest code changes I did in KTextEditor in the last years beside the porting of the highlighting itself to KSyntaxHighlighting. This change touches a lot stuff that is more than one decade old.

Important: This port needs some small fixes in KSyntaxHighlighting. If you want to try current KTextEditor master branch, please ensure you have a up-to-date KSyntaxHighlighting master copy, too!

What does that mean for users?

From Frameworks 5.75 on, KTextEditor will not use any KConfig based schema config. It will rely on the JSON based theme format of KSyntaxHighlighting for the color themes.

You will need to adjust your configuration once after this update. The configuration dialog is fixed to now allow the manipulation of the new theme JSON files. As can be seen below, bundled themes are now marked as read-only and you will need to copy them to change their settings.

The new configuration default is to choose some theme that matches your currently set application palette. This means finally per default if you e.g. switch over to some dark theme in KDE or your other favorite desktop environment, KTextEditor based applications will follow and select some dark color theme.

At the moment there is no automatic conversion code for any old configuration, that is unfortunately non-trivial. The old configuration will not be purged and will stay e.g. on Linux in ~/.config/kateschemarc and ~/.config/katesyntaxhighlightingrc. KTextEditor will just no longer touch these files. That means there can be still converters implemented to recover stuff, patches are very welcome.

As a side note: If you miss the font configuration in the Color Themes section: This got decoupled, themes don’t contain the font, that is now configured on the Appearance configuration page as can be seen below.

This has the nice side effect that color theme changes no longer change the current font or font zooming like before. This was rather unintended.

JSON theme format?

KSyntaxHighlighting reads color themes from some simple JSON format.

At the moment there is no extensive documentation beside the bundled themes we provide in this folder.

The format should be easy to understand, beside this, as mentioned above, the KTextEditor configuration dialog will now allow to just configure this stuff via the UI.

As the new theme format does per default store one theme in one file, this is much easier to archive/version/distribute than the old storage that mixed all configured stuff in two large configuration files.

Local themes are per default stored e.g. on Linux in ~/.local/share/org.kde.syntax-highlighting/themes.

More bundled themes wanted?

With 5.75 (at least as of today), we will ship seven default themes with KSyntaxHighlighting that can be used out of the box with any KTextEditor based application.

For more details see the themes overview page with some show case rendering of all provided themes.

I think that is already a good start but for sure many users would be happy to have more themes available per default.

If you want to help out, please submit MIT licensed themes to us. There are a lot of popular themes available under MIT that just need to be converted into our format.

See e.g. the contributing via merge requests post how to contribute to our stuff.

If you have feedback, use this thread on reddit.

The new website for kde developement information was deployed during the Akademy and contains many information about building awesome stuff using KDE tools and large collection of Qt based libraries.

The long term goal of this new website is to increase the first and third parties use of the KDE Frameworks and development tools. To achieve this goal, this website will provide high quality and complete documentation about the usage of the KDE Frameworks and other libraries (a quite ambitious goal I know), but also provide marketting content for the libraries to offer them a bigger visibility in the internet.

The more short term and more realistic goal is to import the existing tutorials available from various places (techbase, the framework book, the plasma mobile docs and other more hidden places. And more importantly while importing the content, also update and improve it and allow other in the community to review the content for correctness. Another big task is to better organize the content in logical sections.

Behind the scene

The website is powered by the Hugo static site generator and by a fork of the docsy theme. The modifications to the theme are the support of gitlab web editor, the integration of KDE branding and support of linking to api.kde.org class and function with macros. In term of design, I’m not entirely satisfied yet but for a first it’s good enough and because I know developers like dark themes, the website also supports a dark via prefers-color-scheme: dark.

All these changes allow us to provide a custom website tailored to our needs (git based code review, web interface to edit the page if needed, custom design, api.kde.org integration and good separation between the content and the layout of the page).

Future planned improvements to the infrastructure are:

• Add a .gitlab-ci.yml to test most of the code examples, to make sure the code examples still compiles and there is no regressions.

Get Involved

You can find many tasks in Invent, porting old tutorials and improving them can be a good way to learn them or better understand them.

You can also review open merge requests and look if the information are correct.

Thanks to (in no particular order) Paul Brow, Suraj Kumar Mahto, Tobias Fella, David Barchiesi, Han Young, Jonah Brüchert, Nicolas Fella, Nate Graham, Cyril Rossi, Ahmad Samir and Kevin Ottens for their help contributing new content or/and reviewing open merge requests.

Hello so ... 

My name? Nuno Pinheiro.

Ocupation? Heee Designer Stuf.

Location? Portugalio.

Age? C'mon don't ask things like that...., but apparently its a good answer for anything and everything.

So introductions made,...heee right what is this about?

Read the title... geee..

Not clear enough? Right....

Ok lets get one thing straight, this is not Oxygen all over again, it is but... its not, heee... Oxygen was made to be default. Oxygen had more capable people than me steering it in the beginning, Oxygen was massive, we are talking about something in the whereabouts  8000-12000 hours worth of work.

For Oxygen amount of work we have Breeze. 

So now that I stated what it is not i'm done right.?... humm?.. no?

Ok starting to get a bit more serious because, well I have to, this new thing is something that I had as a plan since the end of Oxygen.. Something on the realm of... "How would I do it now that I know what I did not knew wen this started....." But even before that I had to come to terms with the present at the time design ethos. AKA the flatness. I have to be honest was not my thing, still is not my thing, I get it, but I got pretty good at disguising my design limitations under layers of more design, decoration, skeomorphism, gradients etc..

I had to, take my time to discover what I was a designer, and also I was burned out on KDE again look at the hours mentioned... And real life and work was work enough. And so a few years passed...

In what today seams eons ago in Qt world Summit I got to have diner with Good Friend Eike Hein, that challenged me to get back  (aka if anything goes terribly wrong you know the reasons name). And that was it i was decided.... some day I would be back....

Cue in 2020. A year that will be...yeah.. Specially by me, with 2 of the most important people in my life gone (not Covid related). 

Finally Akademy 2020, I got to do a Design/Workshop thingy, had to prepare for it think about it. witch meant thinking of just how much fun I had doing KDE stuf. and it was great. meeting the people way greater... and that was it, I was hooked again...

The master plan.... 

Lets do an experiment. a Massive experiment...

Oxygen add a big problem a very common problem in computer stuf, it was suposed to be used wile being developed and worse DESIGNED wille Developed.

Meaning that the experimentation was limited to the technically possible, cue in a time were alot of hings were changing and beeing invented as we went. the result was that design was very much affected by technical limitations, and that's great... But not what I want to do this time... 

This time around I want to do it in a perfect land that ignores reality, (overrated as any one knows).

Cue in what do I want to do?? 

Well still not absolutely sure, but its a Style with all the things that a Style requires to work... that meens working color pallets, visuals assets, interaction, animations, action icons. etc etc etc...

Requierements:

Scalable... needs to be be scalable, VERY scalable, did I say it needs to be scalable?

Including but not limited to... dpi scalable, size scalable, content scalable... (will talk about all of that to exhaustion), any one that knows me can attest to how boring I am about Scalability, and SVG usage..

Modern. (what ever that means)

Simple color pallet... Use no more than 5-6 base colors for the pallete. every single color in the style needs to be derived (mathematically) from those (ideally the pallete itself can be auto generated from some picture the user likes).

Lots and lots of testing.

In the end if all goes ok, we sould have a plasma theme, a QtQuick Controls theme and an QtStyle.. and a KWin theme.. also maybe a icon theme but icons theese days are fairly simple things to do. And what ever I find useful to do

But for now I will just do what limits me the least.... pure QML components. this will allow me to test things experiment change them test them aging share the results get other people to test etc etc.

OK last thing resources

2 Hours per day 2 years cap... run the numbers you know 2² ? something like that.

Im also thinking this blog stuff is not what kids these days look at... so I might be doing Videos every week or 2 weeks, mostly commenting on recorded work sessions, probably better to show somthing working rather than mockups or screenshots...