… or “how does KMyMoney map accounts to/from AqBanking“.

Since the author of AqBanking recently posted the question how this works, I think it is a good idea to document it in a publically visible way. First of all: why do we need mapping at all? KMyMoney as well as AqBanking deal with the representation of bank accounts and assign each such object an internal ID. Unfortunately, both of them use a different ID for the same account and so one needs some way of turning a KMyMoney ID into an AqBanking ID and vice versa. This is what we are talking here.

Since KMyMoney does not only support AqBanking as an online banking backend it provides a standardized interface to all of them. Also, a set of procedures is defined to support a wide range of possible backends. Now we deal with two different interfaces: one required for KMyMoney and another one required by AqBanking. The trick here is the glue-logic residing in KBanking. It does all the magic that is needed for a successful marriage of the two participants.

How the connection is constructed

The connection between the two accounts on each side of the glue-logic is called mapping. It is started by a call to KBanking::mapAccount(). This method takes two parameters: the account object in KMyMoney and a key-value-store which holds all variables required in the process that need to be stored with the account object. The contents of that key-value-store is only known to KBanking (or any other online banking glue code).

mapAccount() itself creates the dialog KBMapAccount and displays all available AqBanking account inside a list. The user can select an account out of the list for the mapping. Once this has been done, KBanking creates a unique mappingId for the KMyMoney account which consists of the storage ID and the account ID. This needs to be done, because the same account ID may exist in different KMyMoney files but identifies completely different accounts. This allows to map the same account ID in different files to the same or different AqBanking account without problems. Check KBankingExt::mappingId() how it is constructed.

This unique mapping ID is then assigned as alias to the AqBanking account using AB_Banking_SetAccountAlias(). Next the account reference for the AqBanking account will be constructed out of the routing and account number by extracting data from AB_Account_GetBankCode() and AB_Account_GetAccountNumber(). Leading zeros are stripped and both elements are joined with a dash (‘-‘) in between. This resulting value is stored in the key-value-store under the key kbanking-acc-ref.

From KMyMoney to AqBanking

The method KBanking::aqbAccount() takes a reference to a KMyMoney account and returns a pointer to the respective AB_Account structure by calling AB_Banking_GetAccountByAlias() with the above mentioned unique ID.

The other way around

Based on values returned by AB_Banking_GetAccountByAlias() and AB_ImExporterAccountInfo_GetBankCode() the acc-ref is constructed and searched within the set of available KMyMoney accounts. This is performed as part of the import process in KBankingExt::importAccountInfo().

Today we’re going to talk at length about something a little different: the headerbar, a combined titlebar-and-toolbar control that holds a window’s toolbar buttons, close/minimize/maximize buttons, drag area, and (sometimes) app name/title/filename, but with no menubar:

Headerbar in a GNOME app

This type of headerbar is used to a extensively in GNOME and macOS. The adoption of headerbars appears to be an industry trend, and people often ask why KDE apps don’t have headerbars or even seem to be working towards gaining them.

Today I will attempt to answer that question from my own personal perspective. Note that these are my views, and should not be seen as necessarily representative of the views of the KDE Community as a whole. This is just how I see it.

I feel that the headerbar is a fatally flawed user interface concept that must not be used under any circumstances!

To back up this bold and controversial statement, I offer the following list of problems introduced by replacing a window’s traditional titlebar and toolbar with a headerbar:

Reduced drag space to move the window

A traditional titlebar generally consists of 90%+ draggable space, no matter how wide the window is. This provides a large and convenient target for clicking and dragging on to move the window around.

But when you combine the titlebar with the toolbar, the previously empty drag area becomes filled with interactive controls. If like macOS’s implementation your headerbar doesn’t allow dragging the window from the user interface controls, then there is an inherently very low upper limit on the number of things you can put on a headerbar in the interest of preserving adequate drag area:

Headerbar in a macOS app. Look at the small number of items and the huge amount of padding and whitespace required to ensure an adequate drag area!

If, like GNOME’s implementation, your headerbar can be dragged from the clickable controls, this provides relief at the expense of intuitiveness (who would think to drag a window by grabbing one of its buttons?). But it also precludes the use of any user interface controls that can be clicked and dragged. This is an acute problem with the most popular web browsers, and Firefox implements a truly awful headerbar with draggable tabs in it, reducing the space available for dragging the window to almost nothing:

The tiny red squares show where you can drag the window from

Nowhere to put the menubar

Traditionally on Linux, apps’ menubars are integrated into their parent windows, between the titlebar and the toolbar–rather than sitting on a global menubar at the top of the screen like macOS has. When you decide to merge a Linux app’s titlebar and toolbar, what do you do with the menubar that’s in between them?

macOS solves the menubar location problem by having an always-visible global menubar at the top of the screen. This provides the visual design benefits of headerbars with all of the advantages of traditional menubars. However, it isn’t any help if your desktop environment doesn’t force the use of an always-visible global menubar.

The GNOME-style headerbar deletes the menubar entirely, replacing it with in-window controls, a small number of headerbar buttons, and a hamburger menu (ugh) to hold everything else. In practice this requires a near-total rewrite of the app’s user interface, which happened for GNOME 3.0.

Unfortunately, for all but the most trivially simple apps, lots of functionality will no longer have any visible user interface. For example classic cut/copy/paste features are almost always missing from headerbar apps’ hamburger menus; you need to use keyboard shortcuts or a right-click context menu to access them. Believe it or not, lots of users don’t use the keyboard shortcuts or context menus to access these features! If they’re not available in a menu, many users will falsely assume they aren’t implemented. Menubars also teach users keyboard shortcuts right at the point of use, aiding in the transition to proficiency. Without keyboard shortcuts being visible and connected to their functionality, most users will never learn them and will be stuck endlessly clicking around.

I’m not convinced that menubars should be abandoned–especially not before we’ve come up with something better to replace them. Hamburger menus certainly don’t cut it. Microsoft’s Ribbon paradigm is interesting and innovative, but even they don’t fully implement it everywhere. Heads-up displays are a promising concept, but the last production-ready implementation died with Ubuntu 17.10. Bottom line: it’s premature to kill the menubar on desktop apps.

Not universally implementable even by all apps on the same platform

Expanding on the above point, many apps cannot simply lose their traditional menubars. This includes all “productivity” and “prosumer” grade apps that are packed with features–as well as many of the simpler apps too. Take a look at all the functionality available in the menubars of Gwenview and Okular, which are fairly typical content viewing apps:

I don’t know about you, but I sure wouldn’t want most of those features to get removed, become invisible and disconnected from their associated keyboard shortcuts, or go into a single hamburger menu. It would probably overflow the screen.

And that’s just two basic content viewing apps! Forget about it for content creation apps like Krita, LibreOffice, GIMP, Inkscape, or Kdenlive.

Since a headerbar can’t accommodate menubars, and many apps can’t lose their menubars, only some apps will be able to adopt headerbars. You’ll wind up with very simple apps that use headerbars, and complex apps that either use traditional titlebars, menubars, and toolbars.

This inconsistency is exactly what’s happened on GNOME and macOS–platforms that make extensive use of headerbars. In fact on macOS, all document-based apps (1st party as well as 3rd-party) do not and cannot use headerbars because key features are attached to the titlebar’s window title and its proxy icon, which are missing from headerbars.

Reduced flexibility for users and developers

Since the arrangement of controls in a headerbar is critical to ensure that there’s adequate drag area, headerbars are non-editable and generally impose a minimum window width. The headerbar user interface is thus very inflexible compared to traditional toolbars and titlebars, both of which can be customized by the user, and can show some of their elements in an overflow menu if the window becomes really narrow. These technical limitations could theoretically be solved by allowing headerbar contents to be edited like traditional toolbars and display overflow menus instead of imposing minimum window widths, but in practice no implementation that I’m aware of does these things.

With multipurpose non-editable headerbars, developers have to take great pains to ensure that the controls they put there don’t interfere with any other functionality. I mentioned the example of browser tabs in a prior section, but it goes beyond that: every other user interface control that needs to respond to a click-and-drag (such as a slider or combobox) is perilous to use on a headerbar because it will reduce the amount of draggable space. Best not to use them at all, either. For headerbar implementations that don’t allow you to drag the window from the buttons, the number of controls that you can fit on a headerbar is very low or else there is practically no space to drag the window.

Because traditional toolbars and titlebars do not need to pull double duty and merge together, users are free to adjust the controls to best suit their needs and preferences.

App name/window title/filename are omitted or else take up excessive space

A traditional titlebar displays the app name and window title right in the center. It’s a nice wide space that can accommodate quite a bit of text, which is especially handy for web browsers and document-based apps where the webpage’s title or document’s filename appears there:

But with headerbars, this space is filled with user interface controls, so the titlebar text has to compete with them for space. If the headerbar-using app’s developer decides not to show the app name, window title, filename, etc. in that space, then that information is simply… gone!

This is a particular concern for document-based headerbar apps, where the name of the current document is important information that has to be visible. GNOME’s Gedit editor resolves this by putting that information in the headerbar’s precious center position:

As you can see, the need to ensure enough space for the filename doesn’t leave much room for anything else, giving the impression that the app can’t do much.

When it’s up to each headerbar app developer to figure out how to present their app’s name, window title, or the name of the open file, every app needs to reinvent the wheel. If you use a traditional titlebar, your app gets enough space to show its name, window title, or the open document for free!

Unimplementable in a cross-platform manner

The traditional system has a clear separation of roles: the titlebar is drawn by the operating system’s window manager, and the app content is provided by the app. The window manager draws the titlebar however it likes, but leaves the app responsible for defining the actual user interface controls, only theming them to blend in visually. Because every operating system’s window manager knows how to draw a titlebar, this aids in write cross-platform apps and improved the ability of cross-platform apps to blend into whatever operating system they’re run on.

Combining titlebars and toolbars muddies the roles and causes many problems. If the headerbar implementation uses “client-side decorations” (CSD), the app itself becomes responsible for drawing its headerbar. This means that client-side-decorated headerbar apps look and feel totally alien on platforms not specifically targeted by the developers: close/minimize/maximize buttons are in different places or don’t appear at all; windows don’t get shadows or any space along the edges for resizing; there’s no visual change when an app loses focus; and so on.

This destroys visual and behavioral consistency with the operating system’s own style, reducing apps’ ability to work properly outside of their native platforms, and encouraging developers to abandon the concept of cross-platform apps entirely.

A proposed alternative is the implementation of a server-side “dynamic window decoration” spec that all toolkits and window managers would adhere to, allowing apps to tell the window manager what controls they want drawn in the titlebar. This proposal would theoretically work but has no chance of ever being implemented in the real world due to technical and philosophical disagreements between the developers of the different Linux window managers. This is in fact exactly what has happened any time such a spec is proposed.

Even if somehow all of them actually did come to some agreement, there is no chance that Apple and Microsoft would sign on because they prefer that developers use in-house, platform-specific interface toolkits rather than a cross-platform toolkit such as Qt. Without buy-in from macOS and Windows, it would be impossible to write a truly cross-platform headerbar app, which means that toolkits like Qt that care about being cross-platform wouldn’t be able to implement it, and even so, developers wouldn’t use it because it would require much more work to write a headerbar implementation for Linux and a titlebar-and-toolbar implementation for macOS and Windows.

So what are the advantages, anyway?

With all of these problems, I often wonder why the concept even exists in the first place. What’s the advantage? Nevertheless, there are a few:

• Headerbars are very visually clean and attractive. There is something about them that just looks good. While I was taking screenshots of GNOME apps, I kept remarking, “dang, these apps look great!” The attractiveness is probably a big factor driving adoption and user desire for more of them, despite the disadvantages I’ve brought up. I also think a big part of this attractiveness is the fact that in GNOME, generally all the buttons actually look like pushable buttons, and different areas are separated from one another with single-pixel lines rather than enclosing everything in frames. But that’s another story.
• Headerbars consume roughly 44 pixels less vertical space by omitting menubars and making the toolbar also function as a titlebar. This amounts to an almost 6% vertical space savings on a low-quality 1366×768 screen, and about 4% on a 1080p screen. Thus, headerbar apps can indeed provide a bit more space to their content areas and less to the window chrome and user interface controls.
• Headerbars reduce some redundancy by providing an opportunity to display a relevant title in only one place (in the center of the headerbar), rather than duplicated in the titlebar and in the window, which is especially common in Settings apps where the window content consists of multiple pages of settings, each with its own title.
• Finally, headerbars offer the opportunity to make the close button enormous. Not all do (macOS does not, for example), but in GNOME, headerbars have gigantic close buttons that are very easy to click on once you’re sick of using a headerbar app (I kid, I kid!).

Assuming these are valid advantages, perhaps we can gain the same things in KDE oftware without needing to go all the way to headerbars. Let’s take a look:

• It’s true that GNOME apps just have that je ne sais quoi of visual attractiveness that many KDE apps lack. This is a major concern of mine that I plan to put some work into in 2019–without removing or hiding any features of course! Stay tuned!Beyond that, KDE apps can gain the visual cleanliness of the titlebar and toolbar sharing a visual style in a variety of ways in. For example all colors are customizable, so you could simply make the titlebar color match the toolbar color. Also, windows are draggable from their empty toolbar areas by default, so it is actually very easy to simulate a merged titlebar and toolbar, but without any of the disadvantages:
  
  The old Oxygen theme implemented all of this by default, and many other 3rd-party themes do too. Nothing stops a KDE distro from shipping this way by default.
• In KDE Plasma, you can already save the vertical space taken up by in-window menubars by using a single always-visible global menu, or put the whole menubar in the titlebar behind a button! This latter option is really quite cool:

  For those of those of you who noticed that the highlighted menu item is using the wrong icon, I already fixed it

  Again, there’s no reason why a distro couldn’t ship with one of those two configurations out of the box.

• The problem of textual redundancy between the titlebar and the window content in some apps is real, especially Plasma’s System Settings app. However this is fixable with design and code changes: We could make the titlebar simply not repeat the name of the active page, while still somehow exporting that text so that it can be visible in the Task Manager. This is a solvable technical problem.
• Finally, KDE Plasma also offers you the ability to make your window’s close buttons gigantic if you’d like–perhaps for accessibility purposes:
  

So we see that for the small number of advantages that headerbars offer, KDE Plasma already allows you to benefit from nearly all of them without needing to butcher your apps. Now it’s true that headerbars offer the advantages tied up in a nice neat package that’s available by default. That’s true. But the costs hugely outweigh the advantages in my book, especially when there are relatively trivial configuration changes and visual design improvements capable of producing most of the same benefits.

Let me repeat that I plan to put some work into modernizing the look of KDE apps in 2019, and I hope that we can tweak the Breeze theme in a few small but important ways that make our apps really stand out and look fantastic.

Phew, if you’ve gotten this far, you must really care about user interfaces! Might I suggest checking out KDE’s Visual Design Group, where we discuss this kind of thing all the time? Head over to https://community.kde.org/KDE_Visual_Design_Group and make a difference in the most awesome open-source desntop environment’s user interface!

This post explains how to install the Spanish government official tool to generate digital signatures and the web applet used in the Spanish government web sites to sign documents that the user needs to upload. If enough people request it, I’ll write also an English version, but for now, as it’s mainly useful for Spanish openSUSE/SUSE users, I’ll write the rest of the post in Spanish.

En este post voy a explicar cómo instalar AutoFirma (también llamada @firma o clienteafirma en distintas versiones) en openSUSE Leap (15 y 42.3), openSUSE Tumbleweed y SUSE Linux Enterprise.

El método fácil y rápido

Para instalar AutoFirma en openSUSE, basta usar la instalación en 1 click, pulsando en el siguiente botón:

Instalar AutoFirma

El método alternativo

Si se prefiere usar la línea de comandos, se puede añadir mi repositorio de paquetes estables que todavía no están en la distribución e instalar el paquete autofirma desde ahí. En este repositorio intento mantener versiones estables de paquetes que creo que pueden ser interesantes o que personalmente me resultan interesantes así que debería ser seguro añadirlo a los repositorios del sistema. Además, si en algún momento arreglo algún problema o actualizo la versión empaquetada a una más reciente, se obtendrán las mejoras automaticamente al actualizar el sistema. El repositorio es home:alarrosa:packages y para añadirlo hay que usar:

En openSUSE Tumbleweed:

sudo zypper ar -f https://download.opensuse.org/repositories/home:/alarrosa:/packages/openSUSE_Tumbleweed/home:alarrosa:packages.repo

En openSUSE Leap 15:

sudo zypper ar -f https://download.opensuse.org/repositories/home:/alarrosa:/packages/openSUSE_Leap_15.0/home:alarrosa:packages.repo

En SLE 15:

sudo zypper ar -f https://download.opensuse.org/repositories/home:/alarrosa:/packages/SLE_15/home:alarrosa:packages.repo

Y para instalar el paquete:

sudo zypper in autofirma

Cómo usar autofirma

La forma más fácil es añadir el certificado que se haya descargado de la página de la FNMT al almacén de certificados de Firefox (en Preferencias / Privacidad y Seguridad / Certificados). La mayoría de las acciones también permiten usar ficheros PKCS #12 (.p12) directamente.

Las aplicaciones AutoFirma y Cliente @firma aparecerán en el apartado de Oficina del menú de aplicaciones.

AutoFirma

AutoFirma permite firmar documentos muy facilmente.	Diálogo para seleccionar el rectángulo donde se generará una firma visual.
No hace falta modificar las opciones por defecto.	Mensaje de documento correctamente firmado.

Cliente @firma

Cliente @firma da más opciones de firma.	Selección del certificado con el que firmar.
Con cliente @firma se puede validar si una firma es correcta.	Mensaje de firma validada correctamente.

Sobre el paquete autofirma

La última versión oficial distribuida (en el momento en que escribo estas lineas, es la 1.6.3 para Windows y la 1.6.2 para Linux) no permite leer correctamente el almacén de certificados de Firefox, razón por la cual decidí empaquetar la versión en desarrollo de github. Además, hice algunos cambios para que encuentre las librerías del sistema y de Firefox correctamente en openSUSE. También he añadido ficheros .desktop para integrar mejor clienteafirma/autofirma en el escritorio.

Para finalizar, sólo comentar que me llevé una grata sorpresa al ver que el código fuente de autofirma estaba disponible en github con una licencia libre (GPL 2.0 y EUPL 1.1). Desde aquí me gustaría agradecer a los desarrolladores de autofirma por su compromiso con el software libre. En las próximas semanas intentaré enviarles los cambios que he realizado para que los introduzcan en las versiones oficiales por si le son útiles a otras distribuciones.

Actualización: Añadidas instrucciones para SLE 15

FreeBSD 12 was released last week. I’m in the process of rebuilding my main workstation to all-flash (which means backups, disentangling ZFS pools, etc. etc.) and in the meantime installed 12-R to an older i3 I had lying around. KDE Applications 18.12 were released last thursday. Those are in ports, but haven’t made it around to the official packages yet. So here are some notes on almost-current KDE on almost-current FreeBSD:

Installing modern KDE: from a freshly installed 12-R system, getting to a KDE Plasma desktop is a matter of installing two metapackages: pkg install xorg kde5 . That will leave you in a state where you need to link .xinitrc to startkde .. rather old-school. For purposes of having a pleasant setup, pkg install falkon quassel sddm as well.

Graphics configuration: with FreeBSD 12, the Intel on-board graphics drivers have synced up with Linux KMS. Since I’m running an Intel box with iGPU, I installed package drm-kmod and drm-fbsd12.0-kmod, and added the kernel module (as instructed by the pkg-message):

sysrc kld_list+="/boot/modules/i915kms.ko"

Configuring KDE packages: Plasma (modern desktops in general) want to have DBus running, so enable it: sysrc dbus_enable=YES. If you want SDDM, enable it too: sysrc sddm_enable=YES. The invocations of sysrc can be combined, it’s smart enough.

And .. that’s it! Updates (for KDE Applications 18.12) are a pkg upgrade away.

There are a couple of tweaks I’ve left out: SDDM will complain about HAL not being started; I need to sort out what that means, effectively, for us. And both Falkon and Akonadi want larger local socket buffers than the default. That requires sysctl.conf changes and I’m not sure they are actually needed on 12-R. So it’s more a matter of “these legacy tweaks might still be necessary, I’m ignoring them to find out if they are actually necessary.”

Metrics and telemetry are fundamental in any engineering activity to evaluate, learn and improve. They are also needed to consolidate a culture in which opinion and experience are continuously challenged, in which experimentation and evidence becomes the norm and not the exception, in which transparency rules so co-workers are empowered, in which data analysis leads to conversations so evaluations are shared.

Open Source projects has been traditionally reluctant to promote telemetry, based on privacy concerns. Some factor that comes to my mind are helping to change this perception:

• As FLOSS projects grow and mature the need for information grows.
• It is easier now to process big amounts of data while keeping high levels of anonymity.
• The proliferation of company driven and consortium driven FLOSS projects, specially those related with SaaS/cloud technologies and products, showing how useful telemetry is. In general, corporations are less concerned about personal data privacy than many Open Source projects though.
• The DevOps movement is spreading like a pandemic and telemetry is an essential action for practitioners.

So the last few years data analytics is becoming more popular among Open Source projects.

Finding the right metrics is frequently tough. Most of the times projects, teams or departments get drowned in data and graphs before they realize what actually matters, what does it have real business value. When you find the right metrics, somehow it means that the right questions are being asked which I find the hardest part. To identify those questions, I recommend organizations or projects to invest in exploring and learning before moving into automating the data collection, processing, plotting and irradiate the results to be analysed.

So when BuildStream is getting into its third year of life, I thought it could be interesting to invest some effort in digging into some numbers, trying to find a couple of good questions that provide value to the project and the stakeholders involved.

The outcome of this exploratory effort was published and spread across the BuildStream / BuildGrid community. The steps taken to publish the report has been:

• Select a question to drive this exploratory effort, in my case: are we growing?
• Select data sources: in my case, information from the ticketing system and the git repositories.
• Collect the data: in this case, the data sets from the BuildStream ticketing system were exported from gitlab.com and the data sets from git obtained through a script developed by Valentin David.
• Clean the data set (data integrity, duplications, etc.) in this case the data was imported into GSheets and worked there.
• Data processing: the data was processed and metrics were defined using GSheet since the calculations in this phase were simple enough and the amount of data and processing power did not represent a challenge for the tool.
• Plot the data: since the graphs were also simple enough, GSheet was also used for this purpose.
• Initial analysis: the goal here was to identify trends, singularities, exceptions, etc and point them to the BuildStream community looking for debate and answers.
• Report: provided in .pdf and .odt, it has been publishing in the BuildStream Group in gitlab.com and sent to the community mailing list. The report include several recommendations.

The data set could lead us to a deeper analysis but:

• It would have also take me more time.
• I wanted to involve the contributors and stakeholders early in the analysis phase.
• Some metrics which collection, processing and plotting can be automated has been identified already so to me it is better to consolidate them to bring value to the project on regular basis than to keep exploring.

I understand that my approach is arguable but it has worked for me in the past.  The debate of just half way cooked analysis increases the buy-in in the same way that developers love to put their hands in half-broken tools. Feel free to suggest a better approach that I can try in the coming future. I would appreciate it.

Link to the report on gitlab.com. Download it.

What’s next?

I am looking forward to have a fruitful debate about the report within the BuildStream community and beyond. From there, my recommendation is to look for an external provider (it is all about providing value as fast as possible) that, working with Open Source tools, can consolidate what we’ve learnt from this process and can help us to find more and better questions… and hopefully answers.

What is BuildStream

I have been putting effort on BuildStream since May 2018. Check the project out.

Here is another release for the release month! This time it's a new release of Pixel Wheels. This one has been a long time coming: version 0.10.0 got released in September.

So, what's new in this release? These changes:

• Pixel Wheels now remembers the best lap and best total time for each track and shows you a congratulation message when you reach the top 3 in either categories (This one is for you, Benjamin!)

• Sounds have been added to the start up countdown.

• The faster the vehicle is driving the more zoomed out the view is, giving you more time to anticipate the track.

• The game now shows a blocking message if there aren't enough gamepads to start a game, or if a gamepad is disconnected while playing.

• The focus indicator in the game menu has been reimplemented: now each menu item has its own, fading, focus indicator. This fixes the focus indicator glitches when a screen appeared or when switching between tabs in the configuration screen.

• The screens to select vehicles, tracks and championships now show the name of the selected element. Furthermore, the track selection screen shows the track records.

• Fixed glitches when changing tabs in the configuration screen.

• Added secret key shortcut to save a screenshot ('S' for now).

• Switched desktop version to LWJGL3.

• Updated libgdx to 1.9.8.

• Make Google Play happy: bump targetSdkVersion to 26.

The addition of the best lap and total time records for each track took longer than I expected, but I am happy with the end results: I think it improves the game replay value.

There’s big news in Usability & Productivity: Firefox 64 can now use native KDE open/save dialogs! This is optional, bleeding-edge functionality so no distros ship with it yet, but it’s pretty simple to enable yourself:

1. Make sure you’re using Firefox 64
2. Install the xdg-desktop-portal and xdg-desktop-portal-kde packages
3. Set GTK_USE_PORTAL=1 somewhere in your environment. Putting it in Firefox’s Desktop file works. Here’s how: https://www.reddit.com/r/kde/comments/a5cxwk/firefox_v64_can_now_use_the_kde_file_selection/ebmemp1/

Once you do this, Firefox should use native KDE open/save dialogs! Please give this a shot and test it out so bugs (like the empty filename field) can be found and fixed, which will make distros more likely to turn it on automatically. On that subject, I’ve filed tickets to get this integrated by default for Kubuntu and Manjaro.

If you find a problem, file a bug to the “xdg-desktop-portal-kde” product.

Of course that’s not all: a lot of improvements have been made to Discover, Plasma, and, heck, all over the place!

Bugfixes & Performance Improvements

• Plasma no longer crashes when clicking on the clipboard dialog’s “Disable this Popup” button (Kai Uwe Broulik, KDE Plasma 5.14.5)
• In Discover, when viewing a Snap app’s available channels, the version of the app available in each channel is now displayed (Aleix Pol Gonzalez, KDE Plasma 5.14.5)
• Discover’s app progress detail view no longer visually changes when you hover the mouse over a task, because nothing happens when you click on it (Aleix Pol Gonzalez, KDE Plasma 5.14.5)
• In Ubuntu-based distros, Discover now respects the system’s user-configurable check-for-updates frequency setting (Aleix Pol Gonzalez, KDE Plasma 5.14.5)
• Discover no longer futilely offers to show dependencies for locally-downloaded packages (Aleix Pol Gonzalez, KDE Plasma 5.14.5)
• Discover once again shows a Cancel button in its toolbar when an app is in the middle of installing (Aleix Pol Gonzalez, KDE Plasma 5.15.0)
• Discover now displays the correct set of information for locally-downloaded Flatpak packages that have fetchable metadata (Aleix Pol Gonzalez, KDE Plasma 5.15.0)
• Discover no longer crashes when uninstalling multiple apps in rapid succession (Aleix Pol Gonzalez, KDE Plasma 5.15.0)
• Fixed a weird bug in Discover that could cause the Featured list to lose entries after installing an app when multiple backends and sources are configured (Aleix Pol Gonzalez, KDE Plasma 5.15.0)
• In System Settings, it’s once again possible to set a font DPI lower than 96 (David Edmundson, KDE Plasma 5.15.0)
• When a dialog window is open and its parent window is minimized, the dialog window now gets minimized too (Vlad Zagorodniy, KDE Plasma 5.15.0)
• In Discover and other Kirigami-based apps, scrollable views’ scrollbars no longer overlap the content and no longer unexpectedly scroll to the top under certain circumstances (Aleix Pol Gonzalez, KDE Frameworks 5.54)
• The context menu for Trash icons on the desktop once again shows the “Empty Trash” menu item (Kai Uwe Broulik, KDE Frameworks 5.54)
• Drop-down menus in QML-and-Kirigami-based apps no longer have background highlights that are sometimes too short (Aleix Pol Gonzalez, KDE Frameworks 5.54)
• SQLite files now get appropriate icons (me: Nate Graham, KDE Frameworks 5.54):
  

User Interface Improvements

• While in Panel Edit Mode, it’s now a bit easier to figure out how to move a panel: the cursor changes to a more appropriate icon when hovered over the Screen Edge button, and when you click on it instead of dragging it, a helpful tooltip appears letting you know what to do (Björn Feber, KDE Plasma 5.15.0):
  
• The button on a panel that allows you to enter Panel Edit Mode and configure your panel now uses the standard “Configure” icon, instead of a hamburger menu icon (Björn Feber, KDE Plasma 5.15.0):
  
• The context menu for desktop icons is now identical to Dolphin’s (me: Nate Graham, KDE Plasma 5.15.0):
  

  Folder view on the left, Dolphin on the right

• Improved the user interface of the list view in the Desktop Effects System Settings page in various ways (Björn Feber, KDE Plasma 5.15.0)
• Discover now remembers your preferred sort order on the search results and Installed pages (KDE Plasma 5.15.0, Alex Pol Gonzalez)
• Discover’s Sources page now has a better interaction model: the list items are no longer uselessly clickable, and items that can be somehow interacted with have inline buttons (Aleix Pol Gonzalez, KDE Plasma 5.15.0):
  

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

We will be holding a Bug Day on December 15th, 2018, focusing on Kdenlive. Join at any time, the event will be occurring all day long!

This is a great opportunity for anyone, especially non-developers to get involved!

1. Check out our Bug Triaging guide for a primer on how to go about confirming and triaging bugs.
2. Log into KDE Phabricator and join the Bugsquad!
3. Join the #kde-bugs IRC channel on Freenode to chat with us in real-time as we go through the list.
4. Open the shared Etherpad for this event (use your KDE Identity login) to select your block of bugs and cross them off.

If you need any help, contact me!

If you can see this, that means that the migration of my blog to Jekyll should be complete. Yay!

WordPress was actually quite good to me and quite easy to maintain and use. As uncomplicated as the Jekyll approach is, aided by its usage of convention to just do the smart thing, there’s still a fair bit of setup and playing around you need to do to get Jekyll sorted out.

But I have to admit I feel better about being able to maintain a less dynamic server footprint to be able to serve up my blog, especially since it’s so completely low-traffic now.

The theme here is Basically Basic, as installed as a Ruby Gem. I’ve disabled the fancy fonts and analytics (all I could find at least).

I’ve tried to ensure all the old URLs don’t break, and even fixed up some stray conversion issues that had come from my last attempt to migrate to WordPress years ago. The RSS feed is now an Atom feed though (hope that doesn’t break your reader).

There are two terms that brings a heavy controversy in the Open Source world: support and stable. Both of them have their roots in the “old days” of Open Source, where its commercial impact was low and very few companies made business with it.

You probably have read a lot about maintenance vs support. This controversy is older. I first heard of it in the context of Linux based distributions. Commercial distribution had to put effort in differentiating among the two because in Open SOurce they were used indistictly but not in business. But this post is about the adjectivet stable…

Stable as adjective has several meanings in English:

• According to the Cambridge dictionary stable is, among others: firmly fixed or not likely to move or change. I am used to this meaning because of my backgroun in Physics.
• One of the definitions provided by the Oxford dictionary is slightly different: not likely to change or fail; firmly established.

Can you see the confusion between…?

1. It is hard to move… or move slow.
2. It does not fail… it is hard to break.

I am not an English native speaker. Maybe because of its latin root (I am Spanish) or maybe eacuase I studied Physics, I do not provide to the adjective stable the second meaning. It has always called my attention how many people provide both meanings to the word, specially when referring to software releases. Looking at the dictionaries, I can tell why in English there is such link between both ideas.

I read today on Twitter another example of this confusion/controversy. The comment has its roots on a different topic but it has embedded this confusion, I think.

Open Source projects used to have as the main testing strategy the collaboration with a group of beta testers and power users. This strategy helped to create this relation between “not moving” and “not failing” that has become so popular. But this relation is not direct if you have a different release/deploy strategy. The way to increase stability (as hard to break) is by detecting and fixing bugs and that can be done moving fast (constantly updating), or moving slow (backporting). I will not get into which one is better. Both are possible and popular.

I think the word stable should be avoided. Many system and application developers or integrators refer to it as “move slow” as “it will not change much“. But what many users hear is “it will not break” which is why “it moves slow“.

Which adjective can we use to label a release that “moves slow“, so it is not mistaken with “it is not expected to break“?

Is this controversy present in other languages as strong as I perceive it in English? Is it just me who see this controversy?

More and more applications invite you to add a pic in your profile, a gravatar. In some applications and specially in social media the size and position of these gravatars are becoming prominent, too much for my taste. I am not a fan of pictures, I have never been. I do not like selfies, I have no Instagram, I try to avoid publishing pics of myself on Facebook… .

I use two different gravatars in internet. One for professional profiles and applications, associated to my corporate account ( agustin.benito@codethink.co.uk nowadays ), which was taken about 4 years ago, and one I took over 10 years ago associated to my personal account. I have hair on that one.

A few months back I started to think about my approach to this gravatars, looking for something simpler that could last, reflect my personality and that could be used for both, personal and professional profiles… and substitute the pic I have in my site.

My first idea was to ask a couple of photographers I know to take a good picture of me. One of those super modern, super cool, super fancy I-enjoy-life-you-should-ping-me-and-I-will-teach-you-how-but-only-if-you-are-cool-enough-to-deserve-my-coolness kind of picture. I was not fully convinced on this approach though. It would only work if the pic is really cool and checking LinkedIn, I had little confidence my pic could be at the level of some of my connections. Yep, I am connected to very cool people.

Then, looking at some gravatars from hackers I know who have zero interest in publishing a pic of themselves, I thought that maybe an illustration could work. Something simple, not a portrait. An illustration that looked like me but is not me, that could work in small and medium size formats… .

Exactly, I did not know what I want. It was more like… I do know a few things I do not want.

With this “crystal clear” idea, I contacted Ramón Miranda.

Ramón is a professional illustrator that has contributed to several Open Source projects, like Krita. He lives only a few kilometres away from my place in Málaga, Spain which is… great.

I explained him in a mail my idea. We have a video chat to polish the concept and a few days later he invited me over his place to show me a draft. A few days later my new representation of myself was done… with Open Source tools (Krita). And yes, I have the source file.

Thank you Ramón for accepting the challenge and for your dedication. I like the result… a lot.

Dear reader, do you? Yep, I will erase you comment if you don´t.

If you ever need a professional illustrator consider pinging Ramón. He is a hell of a professional. Ah, and he provides online training sessions for those wanting to learn or improve how to draw/paint in the analog and in the digital world (with Open Source tools).

Time to substitute my pics with this new gravatar.

This week I gave KDE Frameworks a web page after only 4 years of us trying to promote it as the best thing ever since cabogganing without one.  I also updated the theme on the KDE Applications 18.12 announcement to this millennium and even made the images in it have a fancy popup effect using the latest in JQuery Bootstrap CSS.  But my proudest contribution is making the screenshot for the new release of Konsole showing how it can now display all the cat emojis plus one for a poodle.

So far no comments asking why I named my computer thus.

by

OFX is the Open Financial eXchange protocol used by various financial institutions in a few countries. KMyMoney provides an OFX client implementation using the open source LibOFX library allowing users to import transactions directly from the bank’s server without using the detour through a web-browser and a downloaded file into the ledger of the application.

A while ago, a KMyMoney user reported a problem with a single institution using OFX transaction download. Out of a sudden, this feature did not work anymore and the bank did not allow to login anymore and provided the following error message:

We're very sorry, but that content you are looking for can't be found. Please try the homepage again. If you continue to receive this message, please call the Customer Service number on the back of your card. We apologize for any inconvenience and appreciate your patience.

Since there was no change on the KMyMoney side nor on LibOFX, the problem must have been with the institution. So he contacted their customer support but the answers did not help to solve the problem.

Not surprisingly I got nowhere talking to tech support at the bank. I don’t think anyone answering the phones knows anything about direct connect .”Can you logon to our website” and “reinstall your personal finance software” is about all they could suggest.

A frustrated KMyMoney user about his banks customer support

We know these answers just to well and one can find them on mailing lists and forums of almost any open source finance applications in or another form.

Living in a country where banks don’t use OFX at all, it is kind of hard to support these stranded users. We tried to log the requests and analyze them, but all just looked well according to the OFX specs.

Searching the web, I came across a posting where a GnuCash user reported, that adding a trailing blank to the username and changing the application version in the request solved the problem. This just sounded too strange, so I forwarded this information to the user and he answered:

Not surprisingly… ipwizard does it again!

I changed the APP_VER to 2400 using the KMM online settings as suggested. Then I saved my KMM file in XML, opened the XML and added a space to me user name.

Worked like a charm.

A happy KMyMoney user

I was also able to get it working with KMM 4.8.0. I just unmapped and remapped the account adding a space to the end of the user ID and using 2700 as the version. No XML hacking required.

Another KMyMoney user also being happy

As a side effect of my search, I stumbled across a posting about OFX security issues. Very interesting article which does not surprise me and shows the partial ignorance of banks regarding security on top of their sometimes non-existant customer support if it comes to home banking.

Calamares, the Linux system installer for boutique distro’s, is translated into 50 or so languages. It’s not a KDE project, but uses a bunch of KDE technology like the KDE Frameworks and KPMCore. It doesn’t use the KDE translation infrastructure, either, but Transifex.

There’s two languages for Calamares that don’t have any translators — they were requested, and then added to the system, but there is noone to do the work. Those are Macedonian and Uzbek. That said, there are also translations to Lao, Farsi, Gujrati, Urdu and Swiss French (is that even a thing) that have not seen any actual translation work done.

If you’re interested in any of those languages, the Calamares translators guide can get you started.

PS.: boutique distro for me means anything outside the “big five”, it doesn’t say anything about the size or importance of the distro itself.

LetsEncrypt is wonderful — SSL certificates automatically generated and updated. CertBot does the actual work in one of its many incarnations. Most of my sites use LetsEncrypt to auto-renew certificates. Recently the CertBot at my hoster stopped updating, and now certificates are expiring. The hoster isn’t responding to mail asking them to give CertBot a kick in the pants, so I’m starting to look at other options. It’s weird because for the past 10 years they’ve been good Open-Source-Friendly hosters.

If things move there will probably be a hiccup in access, but I’ll give a shout when it does. The Calamares site runs on GitHub, so is unaffected by this whole thing.

This is a reminder — for those who don’t read all of the FreeBSD mailing lists — that KDE4 is marked deprecated in the official ports tree for FreeBSD, and will be removed at the end of this year (in about 20 days). Then Qt4 will be removed from the official ports tree in mid-march.

Since both pieces of software are end-of-life and unmaintained upstream already for several years, the kde@ team at FreeBSD no longer can maintain them. Recent time-sinks were dealing with OpenSSL 1.1.1, libressl, C++17, .. the code is old, and there’s newer, nicer, better-maintained code available generally by replacing 4 with 5.

Users are encouraged to migrate to Qt5 and KDE Plasma plus KDE Applications. The easiest way to do so is to follow the instructions on the KDE-FreeBSD community wiki.

Last time I tried printing with the raspberry pi I had only one machine to try with now I have two. Lets see if the Pi can handle two instances of AtCore and control two 3d printers at the same time. This is a follow up to AtCore takes to the pi. So please read that for more about the RPi setup. This post is in video form, please enjoy.