December 19, 2018

… 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().


We have released version 2.10.0 of our Qt application introspection tool GammaRay. GammaRay allows you to observe behavior and data structures of Qt code inside your program live at runtime.

GammaRay 2.10 comes with an entirely new inspection tool for QtLocation geo positioning data. Besides visualizing the currently provided positioning data on a map, it also allows you to override this data, either manually or via replaying an NMEA GPS log. So there’s no need to physically move around anymore when debugging location-aware applications ��

Also new is the new centralized problem report view. While so far inspection tools that noticed an issue in the application code reported that in their own way, we now have the infrastructure to collect this in a single place, including navigation to the corresponding source code location where available. This view now also allows to scan the entire application for certain problem types.

GammaRay problem report view

Another easily noticeable change is the new consolidated system information view, that unifies system environment and system paths views, and can show a number of additional pieces of information about the Qt installation used by the analyzed application.

GammaRay unified system information view

The QPainter paint analyzer got significant improvements once more. After GammaRay 2.9 introduced the painter profiler, we have now also got object navigation for the Qt Quick software renderer (with Qt 5.12 or newer). That is, you can navigate to the Qt Quick item responsible for the paint operation you are looking at. We also considerably improved the performance of the paint analyzer on Windows.

GammaRay paint analyzer with object navigation

A less visible but quite impactful change is that GammaRay no longer triggers the on demand Qt Quick anchor object creation by accessing the anchor related properties, but can inspect those without side-effects now. There’s many more fixes and improvements of course, such as correct palette usage in the style inspector, reduced network load in the property view or improved performance of the GDB injector, to name just a few.

GammaRay is available as part of the Qt Automotive Suite including QtCreator integration and professional support, or GPL-licensed on Github.

About KDAB

KDAB is a consulting company offering a wide variety of expert services in Qt, C++ and 3D/OpenGL and providing training courses in:

KDAB believes that it is critical for our business to contribute to the Qt framework and C++ thinking, to keep pushing these technologies forward to ensure they remain competitive.

The post GammaRay 2.10.0 Release appeared first on KDAB.

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!

December 18, 2018

El cuarto podcast de la quinta temporada de los podcast de KDE España estará dedicada a “KDE y software para el arte I: imagen” en el que veremos aplicaciones como Krita o digiKam. Como siempre, en directo pero que dejaremos grabado para la posteridad el próximo 19 de diciembre a las 22:30 CEST.

KDE y software para el arte I: imagen, próximo podcast de KDE España

KDE y software para el arte I: imagen, próximo podcast de KDE España

KDE cuenta entra sus aplicaciones con varias dedicadas a la imagen como la famosa aplicación de dibujo Krita o digikam, el gestor de fotografía.

En el próximo podcast hablaremos de las opciones libres para los artistas del dibujo o los aficionados y profesionales a la fotografía, como están los proyectos, en que dirección se están enfocando y sus posibilidades de futuro.

Para poder disfrutar del podcast en directo seguiremos utilizando los servicios de acontecimiento en vivo de Youtube y contestaremos, si podemos, vuestras preguntas en directo. Por cierto, este podcast será el cuarto de la quinta temporada, para los que les gusta la metainformación y, por tanto, con toda probabilidad el último del este 2018.

¡Os esperamos el miércoles 19 de diciembre a las 22:30!

Los podcast de KDE España

Ayúdanos a decidir el temaEn un afán de acercarnos más a todos los simpatizantes de KDE hace un tiempo que empezamos a realizar podcast. En ellos varios miembros de la Comunidad KDE de España nos reunimos para hablar un poco de los diversos proyectos.

Hemos hablado de muchos temas como por ejemplo Akademy, KDE Connect, Plasma Mobile, Kirigami, KDE y el mundo empresarial y un largo etcétera de temas. Por supuesto, os animo a ayudarnos proponiendo temas en los comentarios de esta entrada, en el grupo de Telegram de Cañas y Bravas o en la sección especial en la web de bugs que hemos creado para la ocasión.

Podéis seguirnos en el canal de Youtube de KDE España o en Ivoox, donde estamos subiendo poco a poco los audios emitidos. Esperamos que os gusten.

Qt Champions

Another year has passed, winter has come so it’s time to celebrate the Qt Champions!

So without further ado:

@christian-ehrlicher was granted the *Rookie of The Year* title. Christian did an impressive number of submissions through this year while beginning only at the end of 2017. He wrote quite a lot of fixes for the model view system as well as test and documentation fixes.

@aha_1980 has again earned the *Quality Assurer* title due to his continuous services on the bug report system as well as doing quality reviews. He’s also actively improving Qt Creator and the QtSerialBus module.

This year’s *Ambassador* title goes to Kazuo Asano who’s a very active IRL Qt promoter in Japan. His various activities including study-sessions, seminar and now a book are doing wonder making Qt known in the empire of the rising sun.

Orgad Shaneh is our *Maverick Of The Year*. He’s the one we can thank for the now famous branch change bot on Gerrit. Bot he implemented as a side project to make the life of the sysadmins and developers easier.

This year’s *Fixer* is Alexander Volkov who’s done a lot of work on the X11/xcb backend that has no secret for him.

@VRonin various helper libraries and examples earned him the *Content Creator* title. His knowledge of Qt’s model view system is also well known and appreciated on the forum.

Due to his extensive presence on several fronts (IRC channel, forums, and more), @GrecKo has well earned the *Community Builder* title.

His many and to the point answers on the forum as well as continuous presence on it made @jsulm the second *Community Builder*.

And last but not least, his friendliness, continuous support, numerous examples and tests through these past years have opened him the door to the hall of fame. Congratulations to @mrjj who becomes the second Qt Lifetime Champion!

Let us all congratulate our Champions!

Many thanks for all the work done with and for the community!

The post Welcome to the 2018 Qt Champions! appeared first on Qt Blog.

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:

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

December 17, 2018

El mismo día que nos enteramos que ya se han llegado a los 5000 juegos para GNU/Linux en Steam me entero de un proyecto lúdico de uno de los miembros de la Comunidad KDE. Se trata de Aurélien Gâteau, responsable durante 14 años del magnífico visor Gwenview, que nos ofrece Pixel Wheels, un juego de coches de vista superior realmente sorprendente.

Pixel Wheels, un juego clásico para tu Linux

Ayer fue lanzada la versión 0.11.0 de Pixel Wheels, un juego clásico de coches en vista cenital al más estilo micromachines de los 80 y 90.

Pero no os dejéis engañar por lo temprano de la versión, mientras desayunaba esta mañana la he descargado y probado en mi portátil, y la la sensación de fluidez y de que estamos ante un juego que nos puede dar horas y horas de diversión no me han abandonado durante el corto espacio de prueba.

Pixels wheels

De momento solo dispone de 4 circuitos pero está en crecimiento. Si sois jugones no le quitéis ojo.

 

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.”

Could you tell us something about yourself?

My name is Alejandro Montes Bascuñan, I’m 25 years old, and I’m a digital artist from Chile.

Do you paint professionally, as a hobby artist, or both?

I’m just a hobby artist at the moment like I’ve been since I started years ago, although I wish to make this my job someday.

What genre(s) do you work in?

I paint mainly portraits, that’s what I like the most. I like drawing people of different ages, races, cultures, etcetera.

Whose work inspires you most — who are your role models as an artist?

My biggest inspiration is definitely Ayami Kojima. Her art is a wonderful mix of beauty and horror that I simply love. My other biggest inspiration is also a Japanese artist, Yoshitaka Amano. His use of color, shapes and lively brushstrokes are just wonderful.

How and when did you get to try digital painting for the first time?

Roughly 4 years ago, when I was still drawing on paper, my brother bought a little Wacom tablet that he was planning to use but ended up never using it, so I tried using it myself and although it was really hard to get used to it at first, I loved it in the end and abandoned paper forever.

What makes you choose digital over traditional painting?

It’s cleaner and faster especially when it comes to posting artwork online, it can be done in just a few minutes after finishing a piece instead of having to digitize a drawing/painting which can take a while depending on the piece.

How did you find out about Krita?

I found out about it when I was specifically looking for drawing and painting software that could run on Linux because I was about to make the change from Windows 10 to Linux but the only thing holding me back was the program that I would use to draw. Then I stumbled upon Krita and gave it a try and well, the rest is history.

What was your first impression?

I was amazed by the amount of tools and cool features it had: the liquify tool, all the different blending modes, the brush engine and even animation!

What do you love about Krita?

I don’t know what to say, other than that its a solid program. It has every tool a 2d artist needs and more! Also it gets updated and new features are added all the time, that’s amazing! And the fact that it’s free makes it easy for me to recommend it to other people.

What do you think needs improvement in Krita? Is there anything that really annoys you?

There’s nothing big that annoys me but a few small things, mainly minor bugs and little graphical glitches that happen here and there, although they are small and far between they are definitely noticeable when you use the program several hours a day like I do, but other than that I think Krita is great.

What sets Krita apart from the other tools that you use?

Out of all the tools I’ve used I’ve found the brush engine in Krita is the best. It’s so customizable with so many different options and easy to understand, anyone can start using it right away.

If you had to pick one favorite of all your work done in Krita so far, what would it be, and why?

The one with the man with blue hair (I don’t name my paintings). I really like how it turned out, I like the colors, the blending and obviously the man himself, the ambiguous look in his eyes and smile, that you don’t really know what he is thinking, I love that.

What techniques and brushes did you use in it?

Nothing fancy really, first I did a small sketch with the pencil tool, once I was happy with it I blew it up to a bigger size I added flat colors on a layer below and then blended all together on a layer above the sketch with a round hard edge brush, that’s what I use most of the time, 2 tools, pencil and round hard brush.

Where can people see more of your work?

My Instagram account, and my Twitter account that I created a few weeks ago.

Anything else you’d like to share?

I want to thank you, the Krita Foundation and all its contributors, for creating this amazing program, Krita is a great example of the wonders that free/open source software can accomplish and I wish Krita keeps reaching more people so we can see more people create amazing artwork done with it.

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.buildstream-beaver

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.

December 16, 2018

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.

Beat the best lap on Let it Snow!

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.

The Skrooge Team announces the release 2.17.0 version of its popular Personal Finances Manager based on KDE Frameworks

Changelog

  • Correction bug 400695: Designer plugins get installed as versioned libraries
  • Correction bug 400724: Import of Quicken 2012 .QIF file failed due to tags
  • Correction bug 402031: ERR-4/ERR-5 opening relative path to .skg from command line, then zombie Skrooge
  • Correction: Transfer created with value at 0. Regression due to 399672. (see https://forum.kde.org/viewtopic.php?f=210&t=155713&p=406978)
  • Correction: QIF import with transfer on split (see https://forum.kde.org/viewtopic.php?f=210&t=155614)
  • Correction: Add delay (300 ms) on text filter
  • Correction: "Search & Process" create a duplicate a duplicated category in some cases
  • Correction: Compliance with SQLCipher 4
  • Correction: Close SQL database in mmb import
  • Feature: Like on transfer, the ratio is requested when creating a share operation (see https://forum.kde.org/viewtopic.php?f=210&t=155605&p=406979)
  • Feature: Progress bar in taskbar
  • Feature: Support only QT >= 5.7.0 

Get it, Try it, Love it...

Grab Skrooge from your distro's packaging system. If it is not yet included in repositories, go get it from our website, and bug your favorite distro for inclusion.

Now, you can try the appimage too !

If you want to help me to industrialise the windows version, you can get it from here: https://binary-factory.kde.org/job/Skrooge_Nightly_mingw64/

Get Involved

To enhance Skrooge, we need you ! There are many ways you can help us:

  • Submit bug reports
  • Discuss on the KDE forum
  • Contact us, give us your ideas, explain us where we can improve...
  • Can you design good interfaces ? Can you code ? Have webmaster skills ? Are you a billionaire looking for a worthy investment ? We will be very pleased in welcoming you in the skrooge team, contact us !

La premisa de mejora continua es una seña de identidad de la Comunidad KDE, los desarrolladores lanzaron KDE Aplicaciones 18.12 el jueves y desde el blog me estoy dedicando a hablar de ello. Ya he hablado del vídeo demostrativo y de una cuantas mejoras, hoy toca hablar de más novedades de KDE Aplicaciones 18.12 que afectan a programas como Kmail, Gwenview, Ark o Kcal, entre otras.

Lanzado KDE Aplicaciones 18.12

Ayer 13 de diciembre fue lanzado KDE Aplicaciones 18.12, la tercera y última revisión del conjunto de aplicaciones del ecosistema KDE. Han sido 4 meses de trabajo que empezó antes de la versión 18.08 y que nos ofrece mejoras en aplicaciones importantes como Dolphin, Okular o Kate, por nombrar solo unas cuantas.

Los números de este lanzamiento se corresponden a una gran actualización: más de 140 errores resueltos y docenas de nuevas funcionalidades en muchas aplicaciones, gran parte de ellas orientadas a una mejor usabilidad de las mismas.

Más novedades de KDE Aplicaciones 18.12

Más novedades de KDE Aplicaciones 18.12

El número de mejoras de este lanzamiento es bastante alto, el artículo del viernes os presenté las novedades de Dolphin, Spectacle, Okular y Konsole, así que hoy toca hablar de otras aplicaciones que han recibido mejoras.

Empezamos con KMail, el cliente de correo de KDE que ahora:

  • Nos permite tener un buzón de correo unificado, si disponemos de varias cuentas.
  • Ofrece un nuevo conector: generador de correo html a partir de lenguaje Markdown.
  • Mejoras en la lectura de correos html.

El visor de imágenes por defecto, Gwenview tiene mejoras de usabilidad en la herramienta “Reducción de ojos rojos” y una nueva ventana emergente que nos avisa de cómo devolver la barra de menús cuando ésta se oculta.

El gestor de archivos comprimidos Ark, también ha recibido su ración de novedades como:

  • Añadida la implementación para el formato Zstandard (arxius tar.zst)
  • Solucionada la previsualitzación de diversos ficheros como aquellos con formato Open Document, en vez de abrirlos con la aplicación

Por otra parte. KCalc, la sencilla calculadora del KDE, ha ganado la funcionalidad de repetir el último cálculo realizado las veces que sea necesario.

Por otra parte, aplicaciones educativas como Lokalize, KmPlot o Cantor han recibido un importante número de mejoras, casi todas bastante técnicas y específicas.

Como seguimos observando, este KDE Aplicaciones 18.12 nos ha llegado muy cargado de novedades.

Solo me queda dar las gracias a los desarrolladores de KDE y decir…

 

¡KDE rocks!

 

Más información: KDE

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

User Interface Improvements

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.

December 15, 2018

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. Mascot_konqi-support-bughunt.pngCheck 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).

December 14, 2018

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.

toscalix avatar

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.

18.12 release
Kdenlive 18.12 is out. In this version we have fixed some crashes and made some other improvements. 
 
18.12 release notes
  • Backport crash on image sequence import. Commit.
  • Backport fix for titler text gradient. Commit.
  • Add donation url to appdata. Commit.
  • Fix minor EBN issues and typos. Commit.
  • Fix play/pause on Windows. Commit.
  • Sync quickstart manual with UserBase. Commit.
  • Install doc files. Commit.
  • Make it compiles when we use QT_NO_NARROWING_CONVERSIONS_IN_CONNECT. Commit.
  • Fix minor EBN issues. Commit.
 
Refactoring
If you were waiting for the refactoring version, we’re afraid you’ll have to wait a bit longer. We decided to postpone it for the 19.04 release cycle which will give us more time to polish all the edges and add some new nifty features. 
 
  •     We now have a nightly build system so you can try all the latest features;
  •     Among the highlights since the last release;
  •     Added parallel processing feature for render speed improvements;
  •     Added hardware acceleration for proxy clip creation;
  •     Blackmagic Design decklink output is back;
  •     The Speed effect has been reintroduced;
  •     Made keyframe improvements and timeline clip keyframeable GUI.
Please help us test and report your feedback in the comments. Get it!
 
In other news 
After the bug squashing day an interested developer joined the the team and is fixing MOVIT (GPU effects) support. We are very happy to see more people interested in contributing code to the project. Check out our Junior Jobs list and send your patches.
 
On the Windows front, we have implemented many improvements, among them the hanging process on exit is fixed but more on that next week. ��
 
The team has also started brainstorming the interface redesign. You can follow the progress (and contribute) in this refactoring task.
 
 
 

Wayland is a display server protocol used on modern Linux systems, the Qt Wayland platform plugin lets Qt applications run on Wayland display servers (compositors).

Continuing the trend from the Qt 5.11 release, the Qt 5.12 release contains a substantial amount of improvements.

Window decorations

Old window decorations

Old window decorations

We’ve received quite a few complaints about the looks of our window decorations over the last few years. The message is usually: “They are ugly and don’t look native.”

On Wayland, window decorations are supposed to be drawn by the client by default. Consequently, Qt’s window decorations will probably never look identical to what other toolkits draw. I.e. there is no “native” look with client-side decorations. That is, however, no excuse for them to be ugly.

In 5.12, I’ve updated our default decoration plugin so it looks like something from this decade. It still won’t be “native” looking, but it looks closer much closer to what the other toolkits draw.

New window decorations

New window decorations

The default window background color is now used for the decorations, so it should follow your Qt theme quite nicely.

Window with dark theme

Decorations follow the theme of the window.

Furthermore, we’ve now also added support for support for the Wayland extension, xdg-decoration unstable v1. Compositors implementing this extension can now tell Qt clients that decorations will be drawn server-side instead of client-side. I.e. the decorations for Qt applications and other toolkits can be identical after all. This is also good news for people running tiling compositors. It’s no longer needed to set the environment variable QT_WAYLAND_DISABLE_WINDOWDECORATION on compositors that implement this extension. Toggling window decorations at runtime is now also possible.

server-side window dsecorations

The server-side-decoration QtWayland Compositor example. The bar at the top with the close button is drawn and handled by the compositor.

xdg-shell stable

On Wayland, the shell extension is the part of the protocol that gives meaning to surfaces, i.e. it communicates things like: This surface is a popup-menu, this is a toplevel window, this is its window title and application id, this is how it should be maximized, resized minimized etc.

In other words, a pretty important part of the protocol. The problem is that, while Wayland has been stable for many years, there has been no stable shell extension for the desktop. wl-shell is considered deprecated, and development has continued with the unstable xdg-shell. Unstable protocols have backwards incompatible changes in every release, this means that when a new version is released, it’s essentially a new, although similar, protocol. If we were to simply update our code to the protocol described in the new version, Qt clients would stop working on compositors not supporting the new version.

We’ve solved this by using a plugin architecture for loading a shell integration at runtime depending on what the compositor supports. In other words, each time a new breaking version of xdg-shell is released, we create a new plugin for it. The exciting news this time, is that xdg-shell finally turned stable in December last year, and with it broke backwards compatibility for the last time.

Consequently, Qt 5.12 adds the last and final shell plugin for xdg-shell. This means we can finally deprecate the old unstable xdg-shell plugins and concentrate on making the one stable plugin great.

High DPI cursors

Giant cursor

Support for high DPI cursors has been added. Cursors are now also loaded lazily to significantly reduce the memory footprint on embedded devices that don’t really need them.

Handling maximization and fullscreen on xdg-shell

Implementing fullscreen and maximization properly on xdg-shell required a huge refactor in how resizing works in Qt Wayland. That refactor is now in place, and Qt applications on all supported versions of xdg-shell should now properly switch between fullscreen, maximized and windowed mode.

Forcing a logical DPI of 96

window with tiny fonts

Sometimes compositors report 1px=1mm (a DPI of 25.4) when they don’t have better data available, causing physical DPI to be unreliable.

Quite a few things in Qt depend on the logical DPI, most notably point sized fonts. Previously, we’ve calculated the logical DPI using the physical size and resolution of the screen. This works great in most cases, but sometimes the physical dimensions that compositors provide are wrong, which usually results in tiny unreadable fonts. So in Qt 5.12, we switched to forcing a DPI of 96 by default. The old behaviour can still be restored by setting QT_WAYLAND_FORCE_DPI=physical in the environment.

Fractional scaling

Support for xdg-output unstable v1 was added. It’s a protocol extension for communicating additional information about screens and is needed to implement fractional window scaling on the compositor side. Read the details in David Edmundsons blog post.

The post What’s new with the Wayland platform plugin in Qt 5.12? appeared first on Qt Blog.

In Qt for Device Creation 5.12.0, we have enabled additional content installation via QBSPs (Qt Board Support Packages). A QBSP combines toolchain, target device images and set of Qt Creator configurations for particular device into a single file that can be easily shared and installed using the Qt online installer or the Maintenance tool. Technically a QBSP is an archived repository created by the Qt Installer Framework, and it’s creation is now fully integrated into the Yocto builds that are used to create the Boot to Qt Software Stack content.

For all the target devices currently supported in the meta-boot2qt layer, you can create a QBSP simply by issuing a bitbake command:

bitbake meta-b2qt-embedded-qbsp

This will first build both the toolchain and the image, and then package those into a QBSP file with the required Qt Creator configurations. The resulting QBSP file is located in tmp/deploy/qbsp/ folder in your Yocto build environment. The QBSP packaging respects the SDKMACHINE variable, so that if you use environment variable SDKMACHINE=i686-mingw32, a Windows toolchain is packaged into the QBSP.

The Yocto integration is implemented in two classes that can be used even if your target device has not been otherwise integrated into the meta-boot2qt layer. By inheriting the classes and setting up the required variables, you can have a QBSP with your own image for your own target device.

qbsp-image.bbclass

The QBSP will need a suitable device image to include in the package and to achieve this you will need to inherit qbsp-image.bbclass in the image recipe you want to use. You can control the content of the package with variable QBSP_IMAGE_CONTENT. By default Boot to Qt images include a .img file and a .conf file used by the Flashing Wizard.

inherit qbsp-image

QBSP_IMAGE_CONTENT = "\
  ${IMAGE_LINK_NAME}.img \
  ${IMAGE_LINK_NAME}.conf \
  "

qbsp.bbclass

qbsp.bbclass is the main class that handles the creation of the QBSP and you can control the various aspects of it through variables. Most important ones are the dependencies to the toolchain and image task using QBSP_SDK_TASK and QBSP_IMAGE_TASK variables.

For the Boot to Qt Software Stack, this is done in the meta-b2qt-embedded-qbsp.bb recipe:

inherit qbsp

VERSION_SHORT = "${@d.getVar('PV').replace('.','')}"
QBSP_NAME = "Boot2Qt ${PV}"
QBSP_MACHINE = "${@d.getVar('MACHINE').replace('-','')}"
QBSP_INSTALLER_COMPONENT = "embedded.b2qt.${VERSION_SHORT}.yocto.${QBSP_MACHINE}"
QBSP_INSTALL_PATH = "/${PV}/Boot2Qt/${MACHINE}"

QBSP_SDK_TASK = "meta-toolchain-b2qt-embedded-qt5-sdk"
QBSP_IMAGE_TASK = "b2qt-embedded-qt5-image"

Rest of the variables are then used to control how the installer shows the component and where they are installed. You can optionally also, e.g., add an EULA to the package, which the user would need to accept before they can install the components. You can find this and all the other information about the QBSP specific variables in the documentation.

The post How to create QBSPs from Yocto builds appeared first on Qt Blog.

December 13, 2018

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.

Facebooktwittergoogle_pluslinkedinby feather

It's that time of the year again. Everyone is in a festive mood and excited about all the new things they're going to get. It's only natural, since it's the season of the last KDE Applications release for this year!

With more than 140 issues resolved and dozens of feature improvements, KDE Applications 18.12 are now on its way to your operating system of choice. We've highlighted some changes you can look forward to.

Practical File Management with Dolphin

File management encompasses a lot of activities. There's renaming, copying, and moving files around. Perhaps you want to quickly preview a file to make sure it's the right one. You're in luck, because the thumbnail preview experience has been greatly improved in the new version of Dolphin. LibreOffice documents and AppImage applications can now be previewed as thumbnails, and icon thumbnails look much cleaner. If folder thumbnails are enabled, video files larger than 5 MB will be visible in them.

Of course, there is more to Dolphin than just thumbnails. The "Control" menu makes it easier to show hidden places and create new files and folders. After unmounting a storage volume in the Places panel, it can now be remounted. Those who still own audio CDs and use Dolphin to open them will be glad to hear it can now change the CBR bitrate for MP3 files and fix timestamps for FLAC files.

Some security measures have been implemented in Dolphin to prevent users from accidentally losing their data. It no longer allows attempts to unmount the active home directory and the disk where the active OS is installed. When renaming files, Dolphin will warn you if there's an extra dot in front of the filename, which would make the file hidden. Pretty neat, right?

Okular: Annotate ALL the Things

Okular with the new Typewriter tool

Okular has steadily grown from a document viewer into an indispensable assistant in activities such as studying, doing research, or collaborating on text in read-only file formats like PDF and EPUB. Its annotation capabilities were already powerful, but the new version introduces a new tool called Typewriter. With this annotation tool, you'll be able to write text literally anywhere in your files. Whether it's commenting on an image or highlighting a spelling mistake, your hands are now untied, and you can freely express yourself in Okular.

Other improvements in this release include better options to expand and collapse entries in the Table of Contents sidebar. If a file contains links, hovering over them will always display the full URL in a tooltip, regardless of the currently selected Okular mode.

Konsole, Now with More Emotion

Spending hours or even days working in the terminal can get monotonous. Cheer up - the new version of Konsole has full support for emoji! Add a cheeky smiling cat to your commit messages, or insert a facepalm emoji into your shell scripts.

If you're into more serious things, Konsole now makes it easier to reset the font size back to the default. When a bell is triggered in an inactive tab, the tab icon will be highlighted to visually alert you of the activity. Last but not least, if your mouse has back and forward buttons, Konsole is now able to recognize them, and you can use them to switch between tabs.

Usability Improvements for Everyone

If you have been keeping up with KDE-related news, you're probably aware of our community-wide Usability Improvement goal. After all, it's hard to miss the weekly updates from our awesome developers who are dedicated to making the KDE software more accessible and friendlier to everyone.

The KDE Applications 18.12 release integrates all those fruits of labor, and the result is a much more pleasant user experience across the board. KMail now supports a unified inbox display, and emails should now be readable regardless of your color scheme. A small improvement with a big impact is the ability to repeat the last calculation in KCalc multiple times.

Kate comes with new defaults that are meant to help you work more productively right from the start. Specifically, line numbers and the Text Filter plugin will be enabled by default. You can now change the focus of the embedded terminal in Kate by pressing the F4 key, and it will automatically synchronize the location in the terminal with the location of the currently active document.

in 18.12 Kate comes with better defaults

If you are using Gwenview to fix the wretched red-eye effect in your photos, it will now be even easier thanks to the improved Reduce Red Eye tool. When taking screenshots with Spectacle, their filenames will be sequentially numbered by default. You will also notice that saving options in Spectacle are now easier to access from the Save page.

New Spectacle makes it easier to save screenshots

Ark has received support for tar.zst archives, and it's now much smarter when it comes to file previews. Instead of previewing document files as archives, Ark will now launch the appropriate application for the selected file format.

Apart from improving the standard set of applications, we have also made some of our specialized tools more usable. Lokalize, the translation and localization tool, now has a better search functionality that can recognize plural forms of words. If you keep a lot of tabs open in Lokalize, you will be able to navigate between them much faster.

Cantor, the advanced mathematical tool, now offers better visualizations and highlighting of command entries. You can also open multiple files in one Cantor shell. For users who need to draw mathematical functions, we have made Kmplot more stable and improved the SVG export functionality.


As always, check out the full list of changes in KDE Applications 18.12 to find out more.

Our work on KDE Applications continues, and we can't wait to show you what we've created in 2019. Until then, enjoy the Applications 18.12., and let us know which changes made you the happiest!

Today we’re releasing Krita 4.1.7, another bug fix release in the Krita 4.1 series.

The most important fix is a weird one: it might help your wifi connection. The problem is that we started building a widget that would show you the news feed from krita.org. The widget isn’t active, and doesn’t make any kind of network connection… But Qt’s network manager class still checks your wifi settings all the time. See these bugs: https://bugreports.qt.io/browse/QTBUG-46015 and https://bugreports.qt.io/browse/QTBUG-40332.

Apart from that, we’ve worked around a bug in Qt 5.12 that would cause an instant crash when using a tablet. Our own builds do not use that version of Qt, so the Windows builds, macOS build and the Linux appimage are fine, but users of rolling Linux releases like Arch would suffer from this issue.

And there are more bug fixes, of course:

  • Fix showing wrongly that there is no audio support in the animation timeline audio menu
  • Disable the disk-based animation cache rendering backend on Windows: this would give problems with animations bigger than about 150 frames. (BUG 401326)
  • Don’t hang when trying to load recent files thumbnails for files in a location that’s no longer accessible. (BUG:401939)
  • Make it possible to use the LUT docker when Angle is enabled on Windows. We have also updated the OpenColorIO library to the latest release.
  • Remember whether anti-aliasing was enabled in selection tools (BUG:401730)
  • Add a shortcut to activate the text tool (BUG:401655)
  • Make the toolbars movable again
  • Make Select by Color Range check the entire image (BUG:346138)
  • Enable HiDPI support by default: the problems with the canvas scaling have been solved.
  • Allow krita to import more than file at a time when started from a file manager (BUG:401476)
  • Fix using the scrollwheel in comboboxes on Linux (BUG:399379) Patch by Mykola Krachkovsky.
  • Fix the calculation of Average Desaturation (BUG:400493)
  • Do not crash when exporting Compositions (BUG:400627)
  • Make the move tool show the correct cursor in all modes
  • Let the move tool move invisible layers
  • Fix a crash in the artistic color selector (BUG:399860)

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 4.1.7 on Ubuntu and derivatives. We are working on an updated snap.

OSX

Note: the touch docker, gmic-qt and python plugins are not available on OSX.

Source code

md5sum

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here (filenames ending in .sig).

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

December 12, 2018

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.

December 11, 2018

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.

In one of the previous blogs we introduced the new capability of LabPlot to calculate and to draw histograms. Given a data set, the user can calculate the histogram using different binning methods and to visualize the calculated histogram in the new plot type “histogram”. A different workflow is given when the histogram was already calculated in another application and the application like LabPlot is just used to visualize the result of such a calculation and to adjust the final appearance of the plot.

Couple of weeks ago Christoph Roick contributed a new input filter for ROOT histograms. ROOT is a computational environment developed at CERN that is used for data processing, statistical analysis and data visualization, mainly for purposes in the high energy physics community. With the new import filter it is possible now to import ROOT histogram files (custom binary format, compressed) into LabPlot:


Import Dialog


In the import dialog the user can specify which data to import. After the import, the data from “bin center” or from “low edge” can be used together with the bin values from the “content” for x- and y-values, respectively, to plot the data. The result of such a workflow is shown in the screenshot below by means of a very simple example:


ROOT Histogram


In this example taken from ROOT Guide for Beginners, 1000 values for the exponential function are created in ROOT and the histogram is calculated and written to a file. The import of data and the visualization are done in LabPlot as described above. Here, the imported x-y pairs are connected by the “step line” in order to get the common shape of the histogram. Other visualizations with symbols only, etc. are possible, of course, too. The plot on the left hand side was created by the built-in plotter of ROOT and is shown here for comparison purposes.

With this new feature we can utilize the power and speed of ROOT and its ability to work with very big amount of data and to use the flexibility of LabPlot to style the visualization of the calculated data. The code has reached master already and we are going to ship this new feature in the upcoming release 2.6 LabPlot.

In parallel, the work to support also the more general data container “tree” in ROOT is already in progress and we hope to finalize it soon. This would further extend the application area of LabPlot in near future.

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.

December 10, 2018

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.


Older blog entries


Planet KDE is made from the blogs of KDE's contributors. The opinions it contains are those of the contributor. This site is powered by Rawdog and Rawdog RSS. Feed readers can read Planet KDE with RSS, FOAF or OPML.