January 24, 2018

Ayer martes 23 de enero se emitió en directo y se grabó el quinto podcast de la cuarta temporada de KDE España. Un episodio que llega a su capítulo 25 y que lleva por nombre KDE e.V. y KDE España y donde se analizaron los aspectos de las asociaciones que guían el proyecto KDE.

KDE e.V y KDE España, qué son y para qué sirven

Nuevo mes, nuevo podcast. Los chicos de KDE España nos ofrecieron una nueva edición de su charla mensual sobre aspectos del mundo KDE.

KDE e.V. y KDE España

En esta ocasión tocaba mirarse al ombligo y analizar el funcionamiento interno de la fundación KDE e.V. y de la propia KDE España, dos asociaciones que (atención spolier) tienen como objetivo principal guiar al Proyecto KDE a buen puerto.

Así que la conceptos como socios, miembros de la junta, Akademy, Akademy-es, acciones, patrocinadores, elecciones, compromiso y muchas más se fueron sucediendo en la hora y media que duró el episodio y que os dejo en la parte inferior de este párrafo.

 

 

Los participantes de esta nuevo podcast fueron:

  • Ruben Gómez Antolí, miembro de KDE España y realizó las labores de presentador.
  • Albert Astals (@tsdgeos) ,ex-presidente de KDE España, ex-miembro de la junta de KDE e.V.
  • Antonio Larrosa, presidente de KDE España
  • Baltasar Ortega (@baltolkien), secretario de KDE España y creador y editor de KDE Blog

Espero que os haya gustado, si es así ya sabéis: “Manita arriba“, compartid y no olvidéis visitar y suscribiros al canal de Youtube de KDE España.

Como siempre, esperamos vuestros comentarios que os aseguro que son muy valiosos para los desarrolladores, aunque sean críticas constructivas (las otras nunca son buenas para nadie). Así mismo, también nos gustaría saber los temas sobre los que gustaría que hablásemos en los próximos podcast.

Aprovecho la ocasión para invitaros a suscribiros al canal de Ivoox de los podcast de KDE España que pronto estará al día.

A common user complaint about Discover has been that the design could use some improvement. We set out to remedy this in the soon-approaching release of Plasma 5.12, with the aid of KDE’s Visual Design Group. VDG members came up with endless ideas and mockups, and we spent weeks discussing things and iterating on the design. I wanted to share the evolution of a single view in Discover: the application page.

In Plasma 5.11, here’s what we started with:

Not bad! But there were some rough edges we wanted to address. The header was full of technical information that wasn’t always what you wanted to see first. The screenshots needed polishing. And that toolbar on the bottom used a nonstandard UI convention.

First, we turned the bottom bar into a real toolbar like the kind that appears on the top of a window:

That fixed that problem, but it made the app display on top a bit disjointed, and exacerbated the problem with having the app metadata on top. And having the app name and icon only in the toolbar made it easy to mistake the caption for the name!

We resolved that by moving the entire metadata section below the description to reduce its prominence, and returning the app name and icon to the page itself in a simplified form:

This revision got high marks internally, but we wanted to go further and ensure that users of Discover in 5.12 received a really polished experience. So we further tweaked the header, increasing the size of each element to increase its visual prominence, and adding a bit more padding. Then we made the screenshot thumbnails reflect the aspect ratio of their full-sized images and gave them a drop shadow to make them pop:

Next, we decided to improve the whitespace and padding even more. We moved over the app name and caption a bit, increased the margins on the sides of the page, and made the description text left-justified:

That screen looks really good because Krita provides an even number of screenshots that all have the same aspect ratio, and they fit perfectly in the window size that I’ve chosen here. But for apps and window sizes that deviated from this, it didn’t look as good. We also felt that the shadows provided a bit too much depth, and competed with their content. Finally with more than four screenshots, the text was pushed down so far you needed to scroll just to see it. So we decided to reduce the shadow strength and put the screenshots in a horizontal scrollview:

This helped! We decided to implement a fade effect when a thumbnail is cut off, and we made the them bigger and taller because with the design, there will only ever be one row:

Whaddaya think? I’ll tell you what I think: it’s fantastic, and you guys are going to really love this app view. I’d like to thank KDE contributors Andres Betts, Andreas Kainz, and Thomas Pfeiffer for their help with the design work, and Aleix Pol for technical work–and for letting me work on his baby Discover in the first place!

Here are some more screenshots showing how it looks with other apps, and in the smaller Plasma Mobile view:

There’s always room for incremental improvement, and there are a few more tweaks we’ll probably make before Plasma 5.12 is released. But we don’t currently have plans to make any radical changes here. We think you’re all going to love this design in Plasma 5.12!

If you like this kind of work, consider jumping on board and helping to push KDE software to even higher heights! Donating helps, too, and allows KDE to sponsor more work and help students travel to KDE events.

Another important task is to get your favorite software to improve its AppStream metadata! Version numbers, screenshots, better text… the better the data we get from apps, the better we can make the app look in Discover.

January 23, 2018

Una vez más, el gran Rubén Gómez Antolí, miembro de KDE España, del HackLab Almería y conductor habitual de los podcast de KDE España y ha creado un nuevo artículo “KDE y el Software Libre en la batalla por el futuro”donde reflexiona justamente sobre qué puede devenir en el mundo el Software Libre en los próximos años. Un servidor no ha hecho más que hacer la presente introducción, maquetarlo y difundirlo. Espero que os guste tanto como a mí.

KDE y el Software Libre en la batalla por el futuro

En estos primeros días de 2018 no dejan de sucederse noticias interesantes en el campo de la informática.

Por un lado hace pocos días aparecía la noticia sobre la [mejora de la gestión de paquetes Flatpak y Snap en Discover y viene a representar, y a decir, que el futuro de la paquetería en Gnu/Linux son estos dos formatos, que las tiendas de aplicaciones en Gnu/Linux van a levantar el vuelo y, posiblemente, eso llame la atención de las empresas de software propietario para
empezar a trabajar en versiones para nuestro s.o. libre de sus aplicaciones.

Desde luego que nosotros preferimos siempre el software libre pero hay algunas cosas, muy pocas y cada vez menos, para las que ni siquiera existe alternativa.

En cualquier caso, esto no sería sino una buena noticia para el s.o. del pingüino y el ñu porque supondría dar la oportunidad a muchos usuarios que tenían la puerta cerrada a dar el salto; de pronto, podrán tener la posibilidad de hacer el cambio si esas aplicaciones sin alternativa funcionan de forma nativa en Gnu/Linux.

Valve, por ejemplo, está convencida con Flatpak.

A Flatpak y Snap ya le dimos un repaso hace cosa de año y poco en uno de los podcast de KDE España, aquí lo tenéis para que podáis recordarlo:

Por otro lado, tenemos otro tipo de anuncios realmente ilusionantes.

Samsung hace unos meses que anunció DeX, una base para el móvil que permite trabajar con monitor, teclado y ratón: la convergencia.

He de decir que estas pasadas fiestas tuve la oportunidad de cacharrear unos pocos minutos con el ingenio y debo añadir que me gustó, mucho, porque es justo eso -salvando las diferencias-: un móvil que se convierte en ordenador que se convierte en móvil. En segundos. Sin artificios extraños. Sin magia.

También ha mostrado Samsung un interesante proyecto para meter un sistema Gnu/Linux en sus móviles Galaxy, ¿que podemos decir si lo unimos al DeX?

Y no es solo Samsung, Razer, una empresa centrada en el sector del hardware para juegos anunció en el CES de Las Vegas un teléfono convertible en portátil, de nuevo la convergencia, aunque en pequeño.

Incluso Apple, al decir de algunos, también empieza a transitar el camino.

Ya hablamos hace un tiempo de como Plasma Mobile se había posicionado como ¿la única? alternativa desde la posición del software libre. Desde aquello, mucho ha llovido y mucho ha cambiado.

KDE y el Software Libre en la batalla por el futuro

Purism, con su Librem 5, ya se encuentra colaborando con la comunidad KDE para que Plasma Mobile funcione perfectamente en él. Es de suponer que también estarán trabajando en la versión de Gnome (justo es citarlo también).

Plasma Mobile, apoyado en bibliotecas de desarrollo como Kirigami, sobre la que se habló amplió y tendido en un podcast y en el pasado Akademy-ES, es la base sobre la que se asienta todo.

Las tecnologías base de KDE y QT están desde hace tiempo preparadas para su empleo multiplataforma, como también vimos el pasado Akademy-es, y permiten a los desarrolladores empezar a experimentar con esa, para algunos, ansiada convergencia que, en mi opinión, ya esta dando sus primeros pasos y más pronto que tarde estará entre nosotros.

Y, aunque Plasma Mobile no ha sido elegido entre las metas de trabajo de este año de KDE, es seguro que el trabajo sobre el mismo se va a ir acelerando con la entrada de nuevos interesados. Más ahora que se puede utilizar virtualizado.

Por todo ello, es muy posible, que el avance en paralelo de la nueva paquetería -recordemos que Snap es la evolución de Click, que era la base para aplicaciones Ubuntu Phone- junto a los futuros avances de estas bibliotecas de infraestructura posicionen, casi sin quererlo, al software libre y a KDE donde deben estar, en primera línea de la batalla por el futuro: el dispositivo convergente.

Browsing through the list of past donations, I came across this from last December:

This feature was implemented by one of our newer contributors, Andreas Krutzler, who’s already making a name for himself with some high-quality work on Dolphin. Great Job, Andreas!

Sometimes our labors can seem a bit abstract, but as the above screenshot shows, it makes a difference. Our software gets used every day by millions of real people with real needs, frustrations, challenges, and triumphs.

And for potential and current financial contributors: your donations make a huge difference, and we notice these kinds of messages. This support and encouragement is the wind in our sails.

Keep on making the world more awesome, everyone.

Come visit KDAB and join in the fun at the Qt booth: Hall 4-258.

See for yourself our spectacular demos, including our KDAB tools GammaRay, Hotspot and Clazy, and Qt Automotive Suite - taking the hassle out of developing for automotive, using Qt.

The list so far:

CCI 1200 Agricultural Machinery Terminal

  • putting unprecedented analysis and control directly into the driver's cab.

- find out more

Qi - Cellular Tissue Imaging in Qt 3D

  • taking the hunt for a cure for cancer to new levels.

- find out more

KDAB GammaRay

  • the software introspection tool for Qt applications, developed by Volker Krause* of KDAB - look out for next month's release of v. 2.8.

- find out more

Qt Automotive Suite

  • integrating GammaRay deeply into Qt Creator and providing a comprehensive package for automotive needs, including the powerful Qt3D framework, also developed by KDAB.

- find out more

KDAB Hotspot Profiler 

  • the GUI for Linux perf profiler. Look out for next month's new Hotspot release from KDAB's Milian Wolff!

 - find out more

Clazy

  • the open source Qt-oriented code checker and clang plug-in supported by KDAB

- find out more

 

Meet Volker at Embedded World!

Find out more about nanoquill - the innovative coloring book KDAB designed and co-sponsored, allowing all of us to contribute to cancer research.

Other exibitors at the Qt booth include Qt partners basysKom, E-GITS and froglogic, as well as brightONE and Luxoft Global Operations.

Save the dates and book yourself a meeting with one of our Qt, C++ or OpenGL experts on-site. continue reading

The post KDAB at Embedded World 2018 appeared first on KDAB.

I am pleased to inform that Qt 5.9.4 is released today. As a patch release Qt 5.9.4 does not add any new functionality, but provides many bug fixes and other improvements.

Compared to Qt 5.9.3, the new Qt 5.9.4 contains nearly 200 bug fixes and in total more than 500 changes since Qt 5.9.3. For details of the most important changes, please check the Change files of Qt 5.9.4.

Qt 5.9 LTS is soon moving to ‘Strict’ phase (after Qt 5.11 is branched from dev). It continues to receive important bug fixes and significant performance fixes still during the ‘Strict’ phase. We also continue to create new Qt 5.9.x patch releases. Next patch release, Qt 5.9.5, is planned to be released end of March 2018.

Qt 5.9.4 can be updated to using the maintenance tool of the online installer. For new installations, please download latest online installer from Qt Account portal or from qt.io Download page. Offline packages are available for commercial users in the Qt Account portal and at the qt.io Download page for open-source users.

The post Qt 5.9.4 Released appeared first on Qt Blog.

Do you like to use nice bitmap pattern in LibreOffice for area fill. So if you draw a rectangular, a start, … whatever you can use this bitmaps.

With the help of designers from openclipart, pixabay, publicdomainpictures, … I made 42 seamless area bitmap pattern but only 50% are needed. So which one do you like which one can be dropped.

image3851.jpg

Please comment to the bug reportt tdf#114817 or in the comment section. If you’d like to test them feel free to download the LibreOffice writer dokument.

January 22, 2018

Today I had to repair my most important debugging tool. Here’s the result:

That’s three strands (red, white, black) from a USB-to-serial converter, soldered on to a 3-pole screw-tightened connector. Clamped into that are the serial lines (red, green and blue) which were originally crimped straight to the lines. After a few months of use, the crimping failed and the red cable (RX) broke off.

So I had to fix it, and in the process decided to make it more sturdy, more ugly, but also easier to use.

The three grey wires clamped into the connector are part of a 10-pin flat cable which I scavenged out of a 9-pin serial connector I had left in the box-of-old-parts.

The flatcable, and especially the 10-pin connector at the end, is nice and sturdy for connecting to the headers on single-board-computers, like here:

That’s why I need a serial cable for debugging. The frontmost board is a Pine64+. It runs FreeBSD and Linux; in Linux it will drive a full Plasma 5 desktop at FHD and acceptable responsiveness; FreeBSD is limited to serial console and ssh access. I use this board to test aarch64 support in FreeBSD and to test our KDE-FreeBSD packages on yet-more-unusual platforms. This turns up occasional issues in KDE code.

(The other two boards are a switch I had left over, and there’s an Odroid C2 at the back; together they form my little ARM rack, along with two planks they’re screwed on to and a power supply. Did you know the Palm m500 used the same size barrel jack for power as the Odroid C2? Yet another reason to keep old parts lying around.)

Source of infinity

Could you tell us something about yourself?

Hey! My name Is Baukje Jagersma, I’m 22 years old and live in the Netherlands. I studied game design and recently started doing freelance, to try and make a living out of something I enjoy doing!

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

Both: I’ve always enjoyed creating my own stories and worlds with drawing and recently started doing freelance work as well.

What genre(s) do you work in?

Most if not all of my work has something to do with fantasy. To me that’s the best part of drawing, you can create things that don’t exist and make them look believable. Besides that I mostly work as an illustrator and concept artist.

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

There are a lot of sources where I get inspiration from, art in games for example, movies or art sites.

A few artists that are really worth mentioning would be Grzegorz Rutkowski, Ruan Jia and Piotr Jablonski.

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

Probably when I first discovered Deviantart. I was already familiar with GIMP, which I used to create photo-manipulations with. But seeing all the amazingly talented artists on there made me want to try out digital painting for myself.

What makes you choose digital over traditional painting?

I feel like traditional has more limitations and can get messy. In digital you can easily pick any color you like, or undo something that doesn’t work. For me it just works a lot faster.

Forest elf and her kitty

How did you find out about Krita?

Somewhere around 2013-2014 when an artist posted his Krita art on a GIMP forum.

What was your first impression?

I really didn’t know where to start, haha! There were just so many more options than I was used to in GIMP, especially with all the individual brush engines. It really took me a while to get comfortable with the program.

What do you love about Krita?

Now I’ve just grown to love the multiple brush engines! The wrap-around mode, animation tool, brush smoothing options, symmetry options, assistant tool and the different layer and mask options are probably the key features that I love about it. It’s a program that just has so much to offer which makes it a lot of fun to explore with!

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

Probably the only thing that really bugs me is the text tool, which seems to have a few weird issues right now. I’d also love to see the possibility to import and use vector layers and an alternative to the pattern brush option to make it work less repetitive (something similar to Photoshop’s dual brush perhaps).

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

Kinda mentioned it earlier already, it has a lot to offer which makes it fun to explore with! Besides that it’s available to everyone and works just as well as any other ‘professional’ digital painting program.

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

Probably one of my few non-illustrative works. I really wanted to try out the animation tool so I decided to try out a run cycle. I had little knowledge of animating beforehand- but I like how the animation and design turned out in the end.

Tiger run cycle animation

What techniques and brushes did you use in it?

I made a few different style concepts beforehand, where I chose a design from and later on used as a reference. I first made a sketch version of the animation which I then refined and colored. I actually made a little video about it which I posted on youtube.

Where can people see more of your work?

Deviantart: https://baukjespirit.deviantart.com/
Artstation: https://www.artstation.com/baukjespirit
Instagram: https://www.instagram.com/baukjespirit/
Twitter: https://twitter.com/BaukjeJagersma
Youtube: https://www.youtube.com/user/baukjespirit

Anything else you’d like to share?

I’d like to thank the Krita team for developing this amazing program and making it available to everyone! I’m very excited to see how Krita will further develop in the future!

¿He dicho alguna vez que no hay mejor aplicación para gestionar fotografías que digiKam? La respuesta es si, en cada una de las entradas en las que anuncio una versión de este increíble programa. Y, además, digiKam no deja de evolucionar, el mejor síntoma de que goza de buena salud. El pasado 14 de enero fue lanzado digiKam 5.8, que ahora viene con exportación a UPNP/DLNA. Un suma y sigue en una Killer App de KDE.

 

Lanzado digiKam 5.8, ahora con exportación a UPNP/DLNA

La primera gran actualización de digiKam de 2018 viene con la versión 5.8, una versión que viene con mucho trabajo “bajo el capó”, es decir, resolución de errores y optimizaciones que no aparentemente un usuario estándar apreciará pero sin saberlo.

No obstante, también hay algunas novedades como las siguientes:

  • Mejoras en las versiones empaquetadas de digiKam, tanto para Linux con AppImage, Windows con NSIS y MacOs con Packages.
  • Mejoras en el soporte de la base de datos Mysql.
  • Añadida la exportación de las colecciones de imágenes vía UPNP/DLNA para los dispositivos compatibles. Muy útil para usuarios que tengan una red local de ordenadores y quieran compartir las imágenes desde uno central. Hay que destacar que esta funcionalidad fue desarrollada en los Sprints de Randa, que como se puede comprobar dan sus frutos.
  • Después de implementar la exportación de imágenes a Flickr y Imgur llega el turno al servicio privativo DropBox, una opción más para facilitar la vida a los usuarios.

Lanzado digiKam 5.8, ahora con exportación a UPNP/DLNA

Todo esto junto a la resolución de unos 231 errores resueltos hacen de digiKam 5.8 una actualización muy recomendada para todos loa amantes de la fotografía o a aquellos que les guste tener  su colección de imágenes ordenada

Puedes descargar el código fuente de digiKam software collection source code, los instaladores para OSX (>= 10.8) y para Windows 32/64 bits en este repositorio.

Más información: digiKam

January 20, 2018

This is your weekly status update for the KDE community’s progress in the Usability and Productivity initiative. KDE contributors have been busy, and here’s a sampling of features, improvements, and bugfixes relevant to the initiative that KDE developers landed over the past week-and-a-half (subsequent reports will be weekly, but I wrote the first one in the middle of a week):

  • KIO file copy speed (e.g. in Dolphin) is now 4.5x faster (KDE bug 384561)
  • Fixed a layout glitch in Open & Save file picker dialogs (KDE bug 352776)
  • KMail gained the ability to badge its Task Manager app icon with the count of unread emails (KDE Phabricator revision D9841)
  • Notification badges on Task Manager app icons now show up in Task Manager tooltips, too (KDE Phabricator revision D9825) and look better for huge numbers (KDE Phabricator revision D9827):
  • The Audio Volume widget now looks good with Dark themes (KDE bug 388766)
  • KSysGuard’s CPU column now has a pretty little CPU use graph in the background for each process (KDE Phabricator revision D9689):
  • Every KDE app’s “Settings > Configure [app]” menu item now has a universally consistent keyboard shortcut: Ctrl+Shift+Comma (KDE Phabricator revision D8296)
  • The PDF thumbnailer is able to generate thumbnails in Dolphin for more types of PDFs (KDE bug 388288)
  • Dates are no longer formatted like numbers (i.e. as “2,018”) in some places in Dolphin (KDE Phabricator revision D9887)
  • The menu you get when right-clicking on KAddressBook’s icon now includes a “New Contact…” item (KDE Phabricator revision D9926)
  • Dolphin’s main view now properly regains focus after you close the inline terminal pane (KDE bug 298467)
  • Window titlebar buttons now show tooltips (KDE bug 383040)
  • Plasma’s notifications no longer leak memory when created (KDE bug 389132)
  • Baloo indexer now actually excludes directories that are marked as excluded from indexing (KDE bug 362226)
  • A whole class of app crashes caused by typing or deleting characters in search fields using Qt QML components (such as in Discover and System Settings) was traced to a Qt bug–and KDE developer Aleix Pol has submitted a patch!

There’s also been a ton of work in Discover, particularly in Snap and Flatpak support. You can read about it here.

If any of this seems cool or useful, consider helping us out by becoming a KDE contributor yourself. If donating time isn’t your cup of tea, we always appreciate donations of money, too. We can’t do this without your support!

January 19, 2018

KDE Project:

In the last days I had to deal with loading plugins via dlopen.
I learned so far already a lot about symbols on Linux.

I expected, that if I have an executable, and load a plugin into it, that the stuff inside the executable (i.e. object files and static libraries) won't be used to resolve missing symbols in the plugin.
But that's wrong, by default, all symbols are visible, and so all the symbols in your executable are visible to a plugin.
I didn't find the relevant blogs or mailing list entries from the KDE devs, back in the KDE2 days when all the plugin-infrastructure was added to kdelibs. But also others had to find out:
http://hacksoflife.blogspot.de/2012/12/static-libraries-and-plugins-glob...

So, even if your executable links a library as static, its symbols are visible to plugins.
This can be fixed by setting the visibility to hidden, which can be done either using -fvisibility=hidden or the visibility-attribute.

One more thing I didn't expect, is that even if no shared library is involved, the symbols, i.e. code in your executable is still visible to a plugin. Assume your plugin defines a class with the same name and the same method name, i.e. the same symbol.
You create an instance of that class in your plugin and call some function from it.
I didn't expect that at runtime the plugin might call code from the executable instead of the class just built into the plugin (i.e. not being pulled in from a shared lib).
Again, making symbols hidden helps, in general.
Here's something related:
https://stackoverflow.com/questions/8851931/shared-vtables-between-class...

Today I once ended up in a state where all the correct functions from the plugin were called, e.g. the correct ctor, but later on, when a virtual function of that object was called, it was the virtual function from the executable and not from the plugin. Weird. How could that happen ?

I added a little project in github for playing around with such stuff:
https://github.com/neundorf/libstuff

My conclusion so far is that in general you probably always want to build executables and static libraries with visibility=hidden. Not sure why this is not the default...

For anyone around the Gothenburg area on Feb 1st, you are most welcome to the Automotive MeetUp held at the Pelagicore and Luxoft offices. There will be talks about Qt/QML, our embedded Linux platform PELUX and some ramblings about open source in automotive by yours truly ;-)

If you want to come, please register here.

I see a lot of people asking about state of AppImage support in Discover.

It’s non-existent, because AppImage does not require centralized software management interfaces like Discover and GNOME Software (or a command-line package manager). AppImage bundles are totally self-contained, and come straight from the developer with zero middlemen, and can be managed on the filesystem using your file manager

This should sound awfully familiar to former Mac users (like myself), because Mac App bundles are totally self-contained, come straight from the developer with zero middlemen, and are managed using the Finder file manager.

It’s the same model. For 20 years, there was no centralized Mac App Store because this distribution model doesn’t require it. Apple did eventually create one, but it’s a shadow of the iOS version, and a lot of popular Mac developers never got on board, continuing to distribute software themselves and update it in the way they choose (often with Sparkle).

When a format’s primary advantage is decentralization and independence, you don’t need a centralized piece of software like Discover do manage it. Of course, it would be nice to be able to have a centralized location to browse AppImage vendors, but a simple website could accomplish that.

AppImage isn’t currently a part of our design because Software Stores aren’t a part of AppImage’s design. We don’t oppose it–nothing of the sort! But the format isn’t relevant to what Discover does. If you want to use AppImage, go ahead! It’s a great format, and you don’t need our help to do it.

January 18, 2018

Probably most of you will understand me if I tell you I consider my laptop almost like a partner, like my father feels about his car, or kind of. I cannot help but feeling attached to a machine I use many hours a day. So when you have to change it, it is kind of a drama.

It is also a risky decision. I travel quite often and work from home. I have no workstation. This means that I need a powerful and lightweight machine, with high-resolution but also high autonomy, good keyboard and the right combination/amount of outputs… in summary, a good machine.

After a happy journey with Dell, I switched to Lenovo which has been my choice for some years. Not just my former working laptop was a Lenovo but my personal one and my tablet as well.

Why Slimbook

I have been following Slimbook for some time now. As you probably know, they ship a KDE laptop that is very cool, with KDE Neon pre-installed. They have attended to a couple of events I have attended to so I have been able to test their laptops, get feedback from buyers and ask them questions directly. The fact that they are a Spanish company was a beautiful surprise, We do not have that many hardware integrators and vendors in Spain.

But what definitely caught my attention was the fact that they pay a lot of attention to the software. They ship the laptops with Linux pre-installed. Ok, that is not new any more. But they do pre-install several different distros. Now, that’s uncommon. But news do not stop there.

They have created a community of customers that help each other to ensure that you get help beyond their contract responsibilities. They pay attention to this point which makes the pre-sales decision easier, by the way. They also sell peripherals that work on the chosen distro and they welcome tests and reports about them from customers who has installed Linux distributions they do not pre-install.

On the hardware side, Slimbooks are powerful, with a modern look and many cool features.

Based on the above in addition to my KDE colleagues feedback, I decided in October 2017 to go for one. I bought a PRO2 with customised high end components. A machine to work with the coming years.

You need to consider that Slimbook is not a big corporation so they do not have much stock. If you want something special, it will take them some days to ensemble it, test the hardware, install and configure the chosen distro and deliver it.

Evaluation… so far.

Let me start by saying I have no commercial relation with them. I write this post as a way to support the effort Slimbook and some of my colleagues are doing to bring KDE to the hands of Slimbook customers.

The purchase process in my case required some back and forth because I wanted to install openSUSE and it was not by then in the list of officially supported distros. They were kind enough to take the opportunity to install it for me and check that everything worked fine. It did. A different story was the dock station available in their store, which I bought. They reported me they could not make it work at 100% with openSUSE Leap 42.2 before sending it so I ended up not buying it.

So as outcome of this process, Slimbook now supports openSUSE Leap and they do not recommend this dock station to buyers that request the camaleon pre-installed. This was a a huge time saver for me. Also, I was travelling during the arrival date of the laptop. They managed to ship it so it arrived when I was at home, in between trips, the day I requested.

Slimbook demonstrated they understand what customer service really means.

Sadly I completely forgot to mention to them I needed the hard disk encrypted so I had to reinstall the OS again. This time I went directly for openSUSE Leap 42.3. Everything worked out of the box or was trivial to fix:

  • As usual, the high-resolution of the screen provides some headaches when booting the KDE desktop for the very first time (everything is tiny) which is a plus for having the distro pre-installed.
  • I had to go to Yast to finish the configuration of the sound card. Another reason for buying a machine with the distro pre-installed.

On a side note, I will highlight how painful it is to manage resolutions and font dpi when working with a dual screen configuration with a big resolution difference between screens (laptop vs monitor). This is the first time I have a laptop with a very high-resolution screen so it was like going back to the bad old days when Linux users had to manually configure screens, projectors… This has nothing to do with Slimbook though.

As usual, configuring a working machine takes quite a long time. There are so many things to install and configure… I am still discovering small pain points and highlights of my PRO2 in working conditions.

I have written to Slimbook a couple of times with suggestions to consider for their store and future high-end models. Nothing really important except maybe the battery capacity, which I consider short for heavy travellers (not for occasional ones).

This point was  not a surprise for me though. Based on the info provided by Slimbook on their website, I could research about it up front. tlp is something you might consider to install and learn how to manage in order to significantly increase the working time with your laptop while on battery.

I get very pity with the location and number of outputs in every laptop I’ve ever had. I must say they are not too bad on this PRO2. Or maybe it is just that I am usually so annoyed that not being too disappointed this time seems like a good sign.

The laptop has so many highlights that I will not go over them. Take it as a good sign.

Veredict

Do I recommend you the PRO2 with my configuration?

No. My needs might not be yours. You have to get what you need/want. Slimbook allows you to customise your machine which in my case it is a good thing. I considered other laptops from Lenovo or Dell, by the way. I even considered a MacBook.

Do I recommend you Slimbook?

The purchase of a laptop has to be evaluated after a couple of years to be absolutely fair. I am confident about this purchase though based on the customer support I have already received, which is more than what I can say in other cases with well established vendors.

So if you require a good-looking and powerful laptop, you have many options. If you also want to customise it with different components, then the options get reduced. If on top of that, you are looking for a machine with a Linux distro pre-installed, the number of possibilities are small and, depending on the distro you want, close to none.

If on top of all the above, you want a healthy community of consumers that help each other, well supported by the vendor itself, then Slimbook becomes a good option. An if in addition, you want to work with people that understands how important it is your laptop for a professional, the machine you work with everyday, which necessarily means the vendor must provide a good customer support, then I recommend you to talk to these guys. You will find them, for instance, in most major Open Source events that take place in Spain.

As I have said before, the times for hardware/electronic vendors to “fire & forget” are over, or will be shortly. Updating the software and providing maintenance and support to your consumers, way beyond the law obligations, is not just a differentiation factor any more, but a must.

Based on my experience so far, Slimbook gets it.

January 17, 2018

A longstanding complaint about KDE Plasma is that it’s a pain in the butt to stream videos that are located on Samba shares. It’s a usability issue for sure. I’d like to talk a bit about the origins of the problem and how I helped drive a solution.

Background

For KDE Plasma and apps, the KIO framework is responsible for file access and I/O–including files on Samba shares. Software that uses KIO gets this for free; for other software, KIO can either download the file locally before giving it to the program, or else give the program a Samba URL (e.g. smb://share/path/to/file.avi) and let the program figure out what to do.

KDE does have a KIO-aware video player that could do the job: DragonPlayer. Unfortunately, it’s not actively developed, and a bug prevents this from working.

That leaves 3rd party software, like VLC and MPV. These two don’t use KIO, but they do have Samba clients built in, so they’re able to handle the Samba URLs that KIO gives them!

The problem

…Unless the share is password-protected. In this case, the password must be added to the URL, like this: smb://user:password@share/path/to/file.avi. KIO won’t do that because tossing around user passwords in plaintext is an obvious security problem. So it’s up to the video players to either ask the user for the password to the Samba share, or look it up in the user’s KWallet.

The solution

Ideally, KIO would mount remote locations like Samba shares to a local path using FUSE, and then provide that path to non-KDE apps, which is what GNOME’s GVFs does (and why it works without drama in most GTK-based desktop environments). This would let any video player work with with no modifications, but that’s a task I’m not qualified to tackle, so I decided to attack the problem from another angle: make the most popular video players integrate with KWallet so they can prompt for the password and store it in the user’s wallet.

Unfortunately (but understandably), the MPV developers denied the request. But the VLC developers didn’t, and actually implemented KWallet support in VLC 3.0! But when I tested it using nightly builds of VLC 3.0, I found that it didn’t work, and had even regressed from version 2.

Apparently I was the first person to test the feature in VLC 3.0 beta builds. The VLC developers were a joy to work with, and soon enough, both issues were resolved! I re-tested with later builds and verified the fixes.

Behold, the power of QA!

Once VLC 3.0 is out, KDE Plasma users should be able to play videos located on Samba shares accessed with Dolphin. The first time you do it, VLC will ask you for the Samba share’s password:

After that, VLC will look up the password in your KWallet and you’ll never need to think about it ever again.

Lessons learned

QA is important. If people don’t test features, apps could ship broken.

Users like us are the QA. Most Linux software is not developed and sold commercially, and even distros with commercial backing do not have the resources to test most pre-release software. If we don’t test beta versions of our favorite software, we’ll end up doing it after the release once users are disappointed by bugs and broken features.

The easier you make it to test pre-release builds, the more people will do it and the better your volunteer QA will be. All of this was made possible because the VLC developers provide an Ubuntu PPA with nightly builds, so testing pre-release versions was easy and painless. This is great for Ubuntu users like me, but what about users of Debian, Arch, openSUSE, Fedora, or distros based on them? Had I been one of those users, I probably would have given up on doing this kind of testing.

This is why our work in Discover to make it easy to switch app versions is so important for the future. When every app has beta builds available with only a few clicks in a centralized location with a consistent interface, any user can easily become a beta tester.

Like what you see? Please consider testing beta builds of your favorite software and filing high-quality bugs if you find any issues–even ones that seem so obvious that you can’t imagine that the developers could have missed them. They might only be obvious on your hardware or with your use case! We may not pay for most of our software with money, but that just means developers need our time instead. The price of freedom is eternal QA.

Here’s a list of KDE-related stuff (mostly official FreeBSD ports) the KDE-FreeBSD team handled recently. You could call it “a week in the life of some packagers”, packagers who are also otherwise busy with $work-work.

  • Updated otter-browser (a Qt webengine-based browser) to latest version 0.9.94
  • Added a GTK QPA
  • Updated latte-dock to latest released version 0.7.3
  • Clang6 fixes to older KDE and Qt software (out favorite #define nullptr NULL)
  • Reworked packaging of Qt 5.9 to fix a broken (generated) qconfig.h

And in area51, the unofficial ports tree where we do preparatory work (use the branch kde5-import, which supercedes the plasma5 branch; this one contains the current plan for adding Plasma5 to the ports tree and updating all the KDE Applications), we’ve also got:

  • Updated digikam to 5.8
  • Updated KDE Frameworks to 5.42 (this is waiting on an exp-run to move to official ports)
  • Improved powerdevil backend, thanks to Henry Hu
  • Added plasma5-browser-integration
  • Support Qt4 on aarch64, thanks to Fedora

As usual: you can run a full modern KDE desktop system with Plasma 5 and KDE Applications, from the area51 repository, from the kde5-import branch; official ports have the latest Qt and KDE Frameworks, but not the desktop.

January 16, 2018

As you probably know by now, I have been involved in the Civil Infrastructure Project (CIP), a Linux Foundation Initiative formed in 2016, representing Codethink, a founder Member and coordinating the engineering work in two areas within the project:

  • CIP Kernel maintenance
  • Testing strategy and kernel testing tooling.

In the first front, Ben Hutchings, the Debian Kernel maintainer, a colleague at Codehtink, has been labelled as CIP Kernel maintainer until August 2018. Ben has released in December the latest version of the CIP Kernel 4.4.105-cip15 Currently he is working on releasing a new version, including fixes for Meltdown.CIP Initiative logo

During 2017 until a little after ELCE, I have worked on defining the testing strategy for the CIP kernel and coordinating the efforts towards creating a tool to test it, based on kernelci.org. Robert Marshall has been leading the technical efforts the last few months. The tools was finally called Board at Desk (B@D). Some days before ELCE 2017 CIP released first version of the tool, which is nothing but an integration in a VM of the kernelci.org infrastructure that allow testers to test kernels locally in a board connected directly to their machines. There is no need for a remote centralised infrastructure to collect, process and visualise the results. You can read more about it in the B@D 1.0 Release announcement.

A lot of the work my colleagues and I did for CIP got its visualization at the Embedded Linux Conference Europe 2017, that took place in Prague during the third week of October. A couple of articles summarise the activity:

Codethink’s involvement the last few weeks of 2017 and the beginning of 2018 is reduced to the CIP kernel maintenance so in parallel, I have also reduced my involvement to focus more in customer’s work. I plan to attend to the Open Source Summit Japan 2018 to support again CIP activities.

If you are interested in following the work the CIP is doing to bring Linux based systems to Industrial Grade products, I recommend you join the cip-dev mailing list. You can read a previous post I wrote about my CIP related activity.

Yesterday the KDE Community released the Beta for Plasma 5.12 LTS. With that release the feature freeze for 5.12 is in place and also an eternal feature freeze for KWin/X11. To quote the release announcement: “5.12 is the last release which sees feature development in KWin on X11. With 5.13 onwards only new features relevant to Wayland are going to be added.” This raised quite some questions, concerns and misunderstandings in the social networks. With this blog post I try to address those question and explain why this change in policy is done.

Is KWin/X11 still maintained?

Yes! We are just in the process of releasing an LTS. Of course KWin is fully maintained in the LTS life time. While in 5.8 only X11 was maintained, now we are able to offer maintenance for both X11 and Wayland. For the maintenance we do not differentiate between windowing systems.

Will X11 bugs still be fixed?

As X11 is under maintenance, I expect bugs to still get fixed.

Does this mean that in 5.13 X11 will be unmaintained?

We are going to forward port bug fixes from the 5.12 branch to master. Thus any release after 5.12 will get all bug fixes from 5.12. Given that I would say 5.13 will also be maintained on X11.

Does this mean that in the next LTS X11 will be unmaintained?

We will decide when the time comes. Currently I do not expect that we would drop maintenance.

Does this mean Plasma 5.13 will default to Wayland?

This is about feature freeze for X11. Whether Wayland will be the default or not is completely unrelated to this.

Will X11 users not get any new features in KWin?

Of course there will be new features! Most functionality in KWin is independent of the windowing system. Any improvement to those areas benefit Wayland and X11 users. Currently we have a few improvements in the pipeline, for example tooltips on decoration buttons, improved blur effect, a rework of slide desktop effect, improvements to the cube effect and a few more. All of them will be available to both X11 and Wayland users.

How do you decide whether it’s an X11 only feature?

In the case of KWin this is very simple. There are areas in our code structure which are only get pulled in if run on X11, other areas are marked in an if (x11) section. If the new feature touches this code, it’s probably not going to be added.

Does this feature freeze also apply to other KDE software?

No, but personally I would recommend any maintainer to apply a similar feature freeze. I personally will not help developing any X11 specific feature any more and resigned as maintainer of various X11 specific frameworks this week.

What are you going to do if someone present a feature for X11?

It won’t be merged.

But why?

This requires a little bit more explanation. I had a look at the most prominent issues we had over the last years. Where are our stability problems, where are our quality problems, what costs most development time? I observed that it was always in new features specific to X11. Very often even for features we added to Wayland without causing problems.

So I started to look into why that’s so. The obvious answer that we don’t get bugs for Wayland because nobody uses is, is not the case. We get many bug reports for Wayland and many users are nowadays running Wayland. So the reason must be somewhere else.

On Wayland we are able to test the code. Let’s take an example: we get input events through libinput. For this we have unit tests through mocking. Thus we can automate the testing of the lowest layer. From libinput events are sent into KWin core through an internal API and that we can also use in the integration tests. So we can simulate everything from the point where libinput events would hit KWin core. We can test this properly, we know that we get all events (because KWin is the display manager) and we can test every aspect. We can lock the screen and verify how it works, we can make applications grab the pointer or keyboard and test this. We can invoke global shortcuts, etc. etc. It’s all just as if we get the events through libinput. The quality of these new areas in KWin feels really good.

A few weeks ago some commits I did hit the Linux media about KWin/Wayland without X11 starting too fast and due to that causing bugs. These issues were found through our test suite, before any user would ever be exposed to them.

What we did in the past was taking these new features and bring them to X11. But there we cannot test. There is no way on X11 to e.g. fake a touch screen. On X11 we cannot test how this behaves if we lock the screen or used Alt+Tab. We can write the code and manually test it. Hey it works, awesome! But that was mostly not the case. There were corner cases which caused trouble. And to this comes that the main devs run Wayland instead of X11. If features break they are not exposed to the bugs.

Could you give some examples of things that broke?

Sure! The first feature we backported to X11 was “modifier only shortcut”. We spent months fixing the fallout because of X11 weirdness. Another feature backported was panels on shared screen edges. It worked great for Wayland, but on X11 some corner cases were overseen and caused issues, which affected our users and required time to fix. We backported the touch screen swipe gesture on X11 which was a mess. On X11 touch screens are also mouse events, that made it difficult and created many corner cases.

The problem is not adding the feature. The problem is fixing the bugs created by the new features.

But if a new foo requires adjustments?

KWin won’t be adjusted to any new requirements in the XServer, Mesa, input stack, proprietary drivers, etc. If something breaks it’s the fault of those components which broke it.

Adventurous users, testers and developers running Artful 17.10 or our development release Bionic 18.04 can now test the beta version of Plasma 5.12 LTS.

An upgrade to the required Frameworks 5.42 is also provided.

As with previous betas, this is experimental and is only suggested for people who are prepared for possible bugs and breakages.

In addition, please be prepared to use ppa-purge to revert changes, should the need arise at some point.

Read more about the beta release at: https://www.kde.org/announcements/plasma-5.11.95.php

If you want to test then:

sudo add-apt-repository ppa:kubuntu-ppa/beta

and then update packages with

sudo apt update
sudo apt full-upgrade

A Wayland session can be made available at the SDDM login screen by installing the package plasma-workspace-wayland. Please note the information on Wayland sessions in the KDE announcement.

Note: Due to Launchpad builder downtime and maintenance due to Meltdown/Spectre fixes, limiting us to amd64/i386 architectures, these builds may be superseded with a rebuild once the builders are back to normal availability.

The primary purpose of this PPA is to assist testing for bugs and quality of the upcoming final Plasma 5.12 LTS release, due for release by KDE on 6th Febuary.

It is anticipated that Kubuntu Bionic Beaver 18.04 LTS will ship with Plasma 5.12.4, the latest point release of 5.12 LTS available at release date.

Bug reports on the beta itself should be reported to bugs.kde.org.

Packaging bugs can be reported as normal to: Kubuntu PPA bugs: https://bugs.launchpad.net/kubuntu-ppa

Should any issues occur, please provide feedback on our mailing lists [1] or IRC [2]

1. Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net

I guess I’m becoming a Discover developer, since it’s where I seem to spend most of my time these days. It’s just so darn fun since the lead Developer Aleix Pol is super easy to work with, there’s a lot of low-hanging fruit, and with Kirigami, it’s very simple to make consequential changes even when you’re a novice programmer and not very familiar with the codebase. That said, Aleix is still making about 99% of the code changes, and I’m mostly doing UI tweaks, bug screening, promotion, strategy, and work with apps to get their houses in order.

Anyway, here are the user-facing highlights of what we’ve done in the last week or so. There was a lot of work on Snap and Flatpak in particular.

  • Snaps now show their size correctly once installed (KDE bug 389024)
  • During installation of Snaps, the Install button changes so you can’t click it multiple times (KDE bug 388916)
  • Discover now shows the license for Snaps (KDE bug 388735)
  • Discover now shows the size for Snaps that aren’t installed (KDE bug 388734)
  • Discover no longer shows duplicate information in package changelogs for Debian-based distros (KDE bug 387041)
  • Discover now shows the version number for Flatpak apps that define information in their AppStream files (KDE Bug 388968)
  • Discover’s Home page now communicates that it’s a list of featured apps (KDE Phabricator revision D9868)
  • Discover now correctly removes the Tasks entry for an app if you cancel the installation (KDE bug 388915)

Let me share a video that shows a lot of the highlights:

We’ve got Kdenlive available from three sources. Version 17.08.3 is available from a distro, and version 17.12.1 is available straight from the developers via Flatpak. You can also get bleeding-edge development builds if you’d like to follow or participate in the development, or verify that a bug is fixed before the next release. You can install the one that suits you best, and change your selection as your needs and preferences evolve over time. It’s your choice.

You’re looking at the future of software delivery, folks.

Do you want to help make this happen? Instead of my usual spiel about becoming a KDE contributor or donating, consider helping app developers correct and expand their AppStream metadata. The video you just saw isn’t possible without it. Let’s go build the future.

Please read Part 1 of this Blog series about sharing Files on Android and iOS where I wrote about my experiences how to share Files or Content from your Qt App with native Android or iOS Apps.

In the meantime I did some UI tuning and added more info to make it easier to understand and to manage some more use-cases, so expect some more parts of this series next weeks.

Also I found out that not all Android Apps are good citizens of ACTION_EDIT – Intents with ResultCode. After editing and save per ex. Google Fotos sends correct RESULT_OK where other Apps are giving you RESULT_CANCEL. For our workflows it‘s important to know if a File was modified, so as a workaround I store the last-modified-Timestamp before starting the Intent and compare with current Timestamp when Result was handled. All of this is done under the hood and you‘re always getting the correct result code back from EDIT Action.

Some preliminary notes

  • Try it out: all sources are available at GitHub
  • Permissions not checked in Example App: enable WRITE_EXTERNAL_STORAGE manually
  • Current release is for Target SDK 23 ! (Android 7 requires FileProvider – will add later)
  • All Use-Cases are implemented to be used x-platform – currently Android and iOS

If you‘re looking for an Android-only solution please also take a look at AndroidNative project.

Android / iOS

First part covers sharing Files from your App with other Apps on Android and iOS.

This Blog Post is about sharing Files with your Qt App on Android (iOS will follow soon):

  • Use your App as Share Target to receive Content or Files from other Android Apps
  • Impacts on „Sharing Files from your App with other Apps“ (see Part 1)

Intent Filter

To tell the Android OS what kind of Files our App can handle we must add an Intent Filter to AndroidManifest.xml:

<activity … >
        <!-- Handle shared incoming urls -->
        <intent-filter>
            <action android:name="android.intent.action.SEND"/>
            <category android:name="android.intent.category.DEFAULT"/>
            <data android:mimeType="*/*"/>
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.VIEW"/>
            <category android:name="android.intent.category.DEFAULT"/>
            <data android:mimeType="*/*"/>
            <data android:scheme="file"/>
            <data android:scheme="content"/>
        </intent-filter>
</activity>

Now the App can receive Intents for all kind of MimeType using ACTION_VIEW or ACTION_SEND.

Custom Android Activity

To be able to get the Intent we must add some code to our main Activity, so extend the default QtActivity. To do so create a QShareActivity.java at this location:

<project>/android/src/org/ekkescorner/examples/sharex

public class QShareActivity extends QtActivity
{
    @Override
    public void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
    }
}

As next change the Name in AndroidManifest.xml:

<activity ... android:name="org.ekkescorner.examples.sharex.QShareActivity" ...>

Get the incoming Intent

Now the interesting part:
Our App can be opened by other Apps – how do we get the Intent data and read or copy the ‚foreign‘ File ?

This depends from current ApplicationState:
if the App is already running, Android OS will call onNewIntent() – if not our App will be launched and the Intent comes in from onCreate(). The best way is to check the Intent from both methods and then call another method to process the Intent.

Attention: there are some traps to watch !

To inform the UI about an incoming File as usual we want to use a SIGNAL.

If the App is already running we want to open our App exactly on the current Page. Imagine a DropBox-like App where you navigate deep into your File hierarchy and now you want to upload a new Presentation File into the current Folder, but you must edit the Presentation before. So you open PowerPoint or something else, create/edit the presentation and then want to share that File with your App. Of course the User wants to be exactly where he was before without the need to do deep File navigation again.

If our App will be launched by the incoming Intent, onCreate() was called from Android OS to deliver the Intent. Unfortunately at this moment the Qt App isn‘t ready and the SIGNAL will be lost. To avoid this don‘t process the Intent from onCreate() but remember that there‘s a pending Intent.

Later when the Qt App is ready check for pending Intents. HowTo know if the App is ready to process Intents ?

In our Example App we‘re checking the ApplicationState and first time the State becomes Active we ask for pending Intents.

In a real-life business App probably you must at first Login to your Server or get some data from Server, so you‘ll do the check for pending Intents later.

LaunchMode ‚singleInstance‘ vs ‚singleTask‘

As next I found out that the last opened Page wasn‘t shown – instead a white Screen comes up and an error was logged: ‚Surface1 null‘.

Reason was the Launch Mode. Most Android Intent examples are using ‚singleTask‘ so I also did it. Changing the LaunchMode to ‚singleInstance‘ in combination with ‚taskAffinity‘ works better for Qt Apps: now the App opens correct the last opened Page.

Here are the changes to AndroidManifest.xml:

<activity ... android:launchMode="singleInstance" android:taskAffinity="">

Some code snippets:

QShareActivity.java:

public class QShareActivity extends QtActivity
{
    public static boolean isIntentPending;
    public static boolean isInitialized;
    public static String workingDirPath;

    @Override
    public void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
          // now we're checking if the App was started from another Android App via Intent
          Intent theIntent = getIntent();
          if (theIntent != null){
              String theAction = theIntent.getAction();
              if (theAction != null){
                  // delay processIntent();
                  isIntentPending = true;
              }
          }
    }
    // if we are opened from other apps:
    @Override
    public void onNewIntent(Intent intent) {
      super.onNewIntent(intent);
      setIntent(intent);
      // Intent will be processed, if all is initialized and Qt / QML can handle the event
      if(isInitialized) {
          processIntent();
      } else {
          isIntentPending = true;
      }
    }
    public void checkPendingIntents(String workingDir) {
        isInitialized = true;
        workingDirPath = workingDir;
        if(isIntentPending) {
            isIntentPending = false;
            processIntent();
        }
    }
    // process the Intent if Action is SEND or VIEW
    private void processIntent(){
      Intent intent = getIntent();
      // do something with the Intent
    }
}

Check ApplicationState in ApplicationUI.cpp:

#if defined(Q_OS_ANDROID)
void ApplicationUI::onApplicationStateChanged(Qt::ApplicationState applicationState)
{
    if(applicationState == Qt::ApplicationState::ApplicationActive) {
        // if App was launched from VIEW or SEND Intent
        // there's a race collision: the event will be lost,
        // because App and UI wasn't completely initialized
        // workaround: QShareActivity remembers that an Intent is pending
        if(!mPendingIntentsChecked) {
            mPendingIntentsChecked = true;
            mShareUtils->checkPendingIntents(mAppDataFilesPath);
        }
    }
}
#endif

Process the incoming Intent

Now let‘s take a look at processIntent() from QShareActivity.java to see how to read the File from the other Android App.

We‘re listening for VIEW and SEND Intent Actions. The ways to get the Uri are different:

Uri intentUri;
String intentScheme;
String intentAction;
if (intent.getAction().equals("android.intent.action.VIEW")){
       intentAction = "VIEW";
       intentUri = intent.getData();
} else if (intent.getAction().equals("android.intent.action.SEND")){
       intentAction = "SEND";
        Bundle bundle = intent.getExtras();
        intentUri = (Uri)bundle.get(Intent.EXTRA_STREAM);
} else {
        return;
}

As next we must check the Scheme to know if it‘s a ‚file‘ or ‚content‘ Scheme.

// content or file
intentScheme = intentUri.getScheme();
if (intentScheme == null){
      return;
}
if(intentScheme.equals("file")){
      // URI as encoded string
      setFileUrlReceived(intentUri.toString());
      // we are done Qt can deal with file scheme
      return;
}
if(!intentScheme.equals("content")){
        return;
}

To get the real FilePath from a Content Uri isn‘t so easy. Found many complicated examples and finally I got a great solution to extract the absolute FilePath from the Content Uri ��

Please take a look at QSharePathResolver.java:

<project>/android/src/org/ekkescorner/utils/

public class QSharePathResolver {
    public static String getRealPathFromURI(final Context context, final Uri uri) {
		// ...
	}
}

QSharePathResolver.java checks if the content Uri comes from

  • ExternalStorageProvider
  • DownloadsProvider
  • MediaProvider: Images, Video, Audio
  • GoogleFotosUri

and tries to calculate the real path. Now it‘s easy to get the File from an Intent providing a Content Uri:

filePath = QSharePathResolver.getRealPathFromURI(this, intentUri);
setFileUrlReceived(filePath);
// we are done Qt can deal with file scheme
return;

If the Uri couldn‘t be resolved from QSharePathResolver.java we try to read the InputStream. Please take a look at QShareUtils.java: createFile(ContentResolver cR, Uri uri, String fileLocation)

filePath = QShareUtils.createFile(cR, intentUri, workingDirPath);
setFileReceivedAndSaved(filePath);

01_new_intent_from_other_app

Ok – we received the File from our custom Activity – how can we provide this to our QML UI where we‘re waiting for a SIGNAL from C++ ?

From Java (Activity) to C++ to emit the SIGNAL for QML

The methods setFileUrlReceived() and setFileReceivedAndSaved() are native methods:

public class QShareActivity extends QtActivity
{
    // 'file' scheme or resolved from 'content' scheme:
    public static native void setFileUrlReceived(String url);
    // InputStream from 'content' scheme:
    public static native void setFileReceivedAndSaved(String url);
}

Native Methods are implemented in C++ via JNICALL – see all details in AndroidShareUtils.cpp:

#ifdef __cplusplus
extern "C" {
#endif
JNIEXPORT void JNICALL
  Java_org_ekkescorner_examples_sharex_QShareActivity_setFileUrlReceived(JNIEnv *env,
                                        jobject obj,
                                        jstring url)
{
    const char *urlStr = env->GetStringUTFChars(url, NULL);
    Q_UNUSED (obj)
    AndroidShareUtils::getInstance()->setFileUrlReceived(urlStr);
    env->ReleaseStringUTFChars(url, urlStr);
    return;
}
JNIEXPORT void JNICALL
  Java_org_ekkescorner_examples_sharex_QShareActivity_setFileReceivedAndSaved(JNIEnv *env,
                                        jobject obj,
                                        jstring url)
{
    const char *urlStr = env->GetStringUTFChars(url, NULL);
    Q_UNUSED (obj)
    AndroidShareUtils::getInstance()->setFileReceivedAndSaved(urlStr);
    env->ReleaseStringUTFChars(url, urlStr);
    return;
}
#ifdef __cplusplus
}
#endif

If you want to learn more about JNICALL and other ways to manage them, here‘s a great Blog Post from BogDan Vatra : qt-android-episode-5.

JNICALL is like a bridge from Java to C++:

void AndroidShareUtils::setFileUrlReceived(const QString &url)
{
    QString myUrl;
    if(url.startsWith("file://")) {
        myUrl= url.right(url.length()-7);
    } else {
        myUrl= url;
    }
    // check if File exists
    QFileInfo fileInfo = QFileInfo(myUrl);
    if(fileInfo.exists()) {
        emit fileUrlReceived(myUrl);
    } else {
        emit shareError(0, tr("File does not exist: %1").arg(myUrl));
    }
}

This JNICALL enables us to emit the SIGNAL that we received an Intent from another Android App providing access to a File.

02_process_intent_from_other_app

Test it !

Now it‘s a good point to test it. Open Google Photos, select an Image and ShareWith shows ‚ekkes SHARE Example‘ App as target:

03_see_our_app_as_target

Select ‚ekkes SHARE Example‘ and Android will open our App. If the App already was opened, the current Page will be displayed and include the Image:

04_our_app_received_image_from_other_app

onActivityResult() (JAVA) vs QAndroidActivityResultReceiver (JNI)

While writing Part 1 of this Blog series I didn‘t found a way to get the Result back if Intent was started with Result from QShareUtils.java (Workflow ‚A‘ – the JAVA way)

QtNative.activity().startActivityForResult(Intent.createChooser(viewIntent, title), requestId);

@hamalaiv comment pointed me to the right direction: to get the Result back a Custom Activity must be used.

Ok – we‘re now using a custom Activity (QShareActivity.java) – let‘s test it.

To get the Result back, we must be implemented this JAVA code:

public class QShareActivity extends QtActivity
{
    public static native void fireActivityResult(int requestCode, int resultCode);

    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        fireActivityResult(requestCode, resultCode);
    }
}

and this C / C++ Code:

JNIEXPORT void JNICALL
  Java_org_ekkescorner_examples_sharex_QShareActivity_fireActivityResult(JNIEnv *env,
                                        jobject obj,
                                        jint requestCode,
                                        jint resultCode)
{
    Q_UNUSED (obj)
    Q_UNUSED (env)
    AndroidShareUtils::getInstance()->onActivityResult(requestCode, resultCode);
    return;
}
void AndroidShareUtils::onActivityResult(int requestCode, int resultCode)
{
    processActivityResult(requestCode, resultCode);
}
void AndroidShareUtils::processActivityResult(int requestCode, int resultCode)
{
    if(resultCode == RESULT_OK) {
        emit shareEditDone(requestCode);
    } else if(resultCode == RESULT_CANCELED) {
		if(mIsEditMode) {
			// check Timestamp and
			emit shareEditDone(requestCode);
			// or
			emit shareFinished(requestCode);
			return;
        }
        emit shareFinished(requestCode);
    } else {
        emit shareError(requestCode, tr("Share: an Error occured"));
    }
}

05_overview_share_files_with_other_apps_v2

Testing the JAVA way sharing Files with other Android Apps now works as expected with or without ResultCode. I removed the workaround code from ApplicationUI.

But there‘s a Drawback: Testing the JNI way (Part 1, Workflow ‚B‘) using QAndroidActivityResultReceiver only works without ResultCode. If starting the Intent with ResultCode

QtAndroid::startActivity(jniIntent, requestId, this);

the QAndroidActivityResultReceiver wasn‘t called for the Result: instead the Result comes back via our custom Activity onActivityResult() method using a wrong RequestId.

Lesson learned: never use QAndroidActivityResultReceiver (C++, JNI) and onActivityResult() (JAVA Activity) together in one App.

To test this please comment or rename onActivityResult() and you‘ll see the JNI implementation alone works well.

There‘s another problem if we want to share one of our Files with other Apps, because now we‘re source and also target for same MimeTypes. This means: our own App will be listed as a target:

06_own_app_is_target

Tried some ways to workaround, but doesn‘t work well and selecting the own App as Target with Result crashed the App because there was a collision with LaunchMode ‚singleInstance‘.

Unfortunately there‘s no way to exclude targets using Intent Filter. So we have to create a custom Chooser without listing our own App as Target. Thanks to this thread at StackOverFlow I found a way to solve this. Please take a look at QShareUtils.java

public static boolean createCustomChooserAndStartActivity(Intent theIntent, String title, int requestId) {
	// ...
}

Here‘s a short summary:

  • Create Intent as before and use as template
  • Context is QtNative.activity()
  • Get packageManager from context.getPackageManager()
  • Retrieve all Apps (List) for Template – Intent: packageManager.queryIntentActivities()
  • Sort Apps (List) by Label
  • From Apps (List) create List
    • Create Intent as Copy from Template – Intent
    • Add setPackage(targetPackageName)
    • Don‘t add Intent to list if Target PackageName equals own PackageName
    • If needed also watch a Blacklist

We created a List of Intents, where all Intents are based on our previously created Template – Intent with an extra PackageName added. This means each Intent will only detect one specific App as Target.

Now the tricky part:

We want to all collected Intents as EXTRA_INITIAL_INTENTS and we‘re using the last one from list of Intents as initializing Intent because the Chooser adds its initializing Intent to the end of EXTRA_INITIAL_INTENTS ��

Intent chooserIntent = Intent.createChooser(targetedIntents.remove(targetedIntents.size() - 1), title);
if (targetedIntents.isEmpty()) {
    Log.d("ekkescorner", title+" only one Intent left for Chooser");
} else {
    chooserIntent.putExtra(Intent.EXTRA_INITIAL_INTENTS, targetedIntents.toArray(new Parcelable[] {}));
}

QtNative.activity().startActivityForResult(chooserIntent, requestId);

07_own_app_excluded_from_targets

Now it works as expected: our own App doesn‘t appear in list of target Apps.

Attention: onActivityResult() (JAVA) sometimes is too fast compared with QAndroidActivityResultReceiver (JNI)

While testing Action SEND I noticed that Files are not copied to other Apps or not printed, because ‚File does not exist‘. This happens only if going the JAVA way getting the Result back from onActivityResult(), but not if using JNI and QAndroidActivityResultReceiver.
When getting the Result back I‘m deleting the File from Documents Folder (see Part1) and it seems that onActivityResult() sends the Result before File was fully copied / printed.
As workaround I added a Timer with 500ms delay in QML before deleting the File.

From now on I‘ll use the JAVA way (Workflow ‚A‘ in Overview) as default to share Files with other Apps, because it‘s much easier to implement specific behaviour (as our Chooser Intent) using JAVA instead of JNI. The pure JNI way still remains in the code to get a feeling HowTo solve it without JAVA code.

Share from other iOS Apps with our Qt App

As next I want to implement the same functionality for iOS – so stay tuned for Part 3.

My goal is always to provide easy-to-use x-platform solutions for Android and iOS. That‘s why I‘m using Qt ��

Some years ago I developed mobile business Apps for BlackBerry10 (BB10) where the InvocationFramework makes it easy to share content or files between Apps.

BB10 Customers are now (and next years) in transition from BB10 to Android, iOS or both and of course I want to motivate them to use Qt as their new Framework. Last two years I implemented most of my patterns using Qt and QtQuickControls2 for Android and iOS. Having features only for one platform is like having no solution. Step-by-step I‘m reaching feature-parity with BB10.

I‘m also blogging about all of this to make it easy for mobile devs to start with Qt.

Back to Sharing Example.

Need Help – offer Bonus

As I understand it right, iOS Extensions should be used to share Files or Content from other iOS Apps to our Qt App and it seems that this isn‘t supported yet our of the box from QtCreator. If there are some manual steps needed I need a description HowTo do this.

Remember: I‘m a mobile Business App Developer, not a Xcode expert and not an Obj-C expert and I‘m doing all my work from QtCreator – not commandline.

I‘m open for all tips and any help HowTo …

  • Open Qt App from other iOS Apps sharing Text Content or Files
  • Reopen Qt App from other iOS Apps at current Page if Qt App is already running
  • Emit SIGNAL about received Files or Text and copy Files into AppData location
  • Development workflow to solve this from QtCreator / Xcode

Bonus: If someone can provide a small sample project before I found out all the steps and blogged about, the first one will get a Bonus of 500 € from me. Please be aware that I‘ll modify and include code into my Share Example as Open Source code.

Have Fun

Now it‘s time to download current Version from Github, build and run the Sharing Example App.

The post Sharing Files on Android or iOS from or with your Qt App – Part 2 appeared first on Qt Blog.

Despite the security meltdown that swept over the tech community, our 2018 started out great - and it's all thanks to you. Your donations helped us reach the goal of our end-of-year fundraiser.

We would like to thank everyone who participated in the fundraiser, and also to all our community members who spread the word about it on social media and their blogs. You are all a wonderful community, and we are proud to be a part of this journey with you.

With our funds recharged and our hearts full of gratitude, we are ready to take on the new year and all the challenges it brings. The work is already in full swing - we released a bugfix update for KDE Applications and a new version of KDE Frameworks. But what else is there to look forward to in 2018? Read on to find out.

Plasma 5.12 Puts the "S" in Speed (and Stability)

Having released an update for Plasma 5.11 just at the beginning of 2018, Plasma developers are now gearing up for the first major release of the year. Plasma 5.12 will be the new LTS (Long-Term Support) version, replacing Plasma 5.8.


Discover, now with better application screenshots.

Since many Linux distributions will rely on this version of Plasma, the developers wanted to make it as stable and fast as possible. Startup speed and memory usage will be visibly improved, particularly on low-end devices.

The KScreen utility will allow Wayland users to adjust the output resolution as well as enable and disable selected outputs. Discover, the software management application, will support the dist-upgrade command for new major releases of distributions. Application screenshots will look better than ever, and support some useful options such as navigation between images. A lot of work has been done on Flatpak support in Discover, and plenty of critical, usability-impeding bugs have been fixed.

It is important to note that new features for KWin on X11 will no longer be developed after Plasma 5.12. Moving forward, only the features relevant to Wayland will be added.

Krita Paints Masterpiece Features


Krita 4.0 is almost here!

Digital artists, rejoice! A major Krita release with big, beautiful changes is coming this year. With Krita 3.3.3 released just recently, all the attention is now shifting towards Krita 4.0. This version will bring improved integration with Inkscape, allowing the users to copy and paste shapes directly between the two applications.

Krita 4.0 supports Python scripting, comes with a new text tool, and allows bigger brush sizes. Expect two major changes related to file formats, too - instead of ODG, SVG will be the new default vector format. Additionally, the file format for color palettes will change, and the new one will let users create their own color groups.

If you're feeling brave enough, you can already try Krita 4.0 Beta today, and don't forget to report bugs if you find any!

New Apps Take the Stage

We're always happy when new or small projects take off and grow to become an important part of the KDE Community. Here's a small selection of some interesting KDE applications to keep an eye on:

Atelier

If you're into 3D printing, you should try Atelier. Along with its backend, AtCore, Atelier allows you to control your 3D printer, calibrate printer settings, check its status, and send print jobs to the printer. Although the application is still in beta, you can use it on Linux, macOS, and Windows, and there is even an AppImage if you'd prefer not bother with dependencies.

A major redesign of the user interface is in progress, so you can expect better views and multiple workspaces that will allow you to manage more than one 3D printer using one instance of Atelier.

Zanshin


With Zanshin, you'll never forget to buy those kiwis.

Productivity isn't such a hot buzzword anymore, but people are still looking for better ways to organize their tasks. Enter Zanshin, a small but powerful app grounded in the philosophy of simplicity. It allows you to sort your tasks into projects and divide them into different contexts.

Zanshin integrates with the KDE PIM suite and KRunner, making it easy to add new tasks from incoming email or display them in your calendar. A new version of Zanshin just came out, with features such as recurrent tasks, support for attachments, and the ability to focus on the currently active task to minimize distraction.

Latte Dock

Latte Dock officially became a KDE project (as part of our Extragear collection) at the end of 2017, but it has been a community favorite for a long time.

This highly configurable dock allows you to organize your launchers and running applications, and new features are added constantly. Recent changes made it possible to share custom dock layouts with other users (and download theirs), and improved dynamic backgrounds for application windows that interact with the dock.

Elisa


Elisa is simple by default, powerful when needed.

A new music player on the KDE stage, Elisa is still in development, but it's an exciting project to follow. One of its main features is music indexing, which optimizes the speed of your music collection. Elisa allows you to browse music by artist and album, or display all tracks, as well as create custom playlists. The developers are currently focused on improving the interface. You can try Elisa on Linux and Windows.

Akademy on the Blue Danube

August may seem far away, but we're already preparing for the biggest KDE Community event of the year - Akademy 2018! The annual gathering of KDE community members will take place in Vienna, Austria, from the 11th to the 17th of August at the University of Technology (TU Wien).

The call for participation is now open, and you can send your proposals for talks, panels, and workshops until March 12th, 2018. Of course, you can also simply come as an attendee -- after all, there is no admission fee, and everyone is welcome. Whether you're a seasoned KDE contributor or someone who just started using KDE software two days ago, we would like to meet you!

More Ways for You to Contribute

During our end-of-year fundraiser, many people asked us about using cryptocurrency to support KDE. We listened, and we made it possible - now you can donate Bitcoin using bitpay. You can also donate directly from our Facebook page, or participate in our Join the Game project, where you can become a supporting member of KDE and take part in our General Assembly meetings.

Of course, it's not all about the money. If you would like to contribute to KDE as a developer, take a look at our Season of KDE mentorship project. Want to write articles about KDE for this website? Get in touch with the KDE Promo team, and they will help you get started. There are so many venues to becoming a KDE contributor, and as part of our long-term goals, we will work on making the process of joining easier.

Let's konquer 2018 together!

Dot Categories:

For the past year at Blue Systems my colleagues and I have been working on getting Plasma 5 ready for ARMv8 systems such as the Pinebook. If you were at QtCon this year, you might have also seen our awesome team demo’ing these systems at the KDE booth along with Plasma on ARMv7 systems such as the ODROID C1.

A year ago, the state of Plasma on ARMv8 looked somewhat like this bench, covered in snow, not particularly inviting. Things worked, or at least appeared to, only to break as soon as you started digging deeper into the innards of the system. One of the biggest hurdles in the ARM space right now is getting graphics working on a Linux system. Working with the Pine64 and Pinebook was no exception.

While the X11 and DRM stacks are open source, the OpenGLES implementation is only provided as a proprietary blob. Better than nothing, but still not quite up to the quality that we were looking for.

Once we figured out where we could improve things, we started getting our hands dirty and improving things as best as we could and learning more about the graphics stack as a whole. This lead to improvements such as getting a working hwcursor (thanks David!) for the Pinebook, making sure we don’t have garbage on the screen when X11 gets started and a failed attempt to get Debian to rebuild Qt on ARM64 systems with GLES instead of OpenGL ( since there is no OpenGL on the Pinebook ).

We also bench marked important metrics that would affect our users such as time to login manager, time to desktop and the time it took to launch a file manager such as Dolphin. With these metrics in hand, the Plasma team at Blue Systems set out to improve these metrics by improving the various bits and pieces within the KDE product ecosystem. It’s important to note that all of the improvements that have been made will also benefit x86 users, though the impact will really be seen on ARM devices.

The future for Plasma on ARMv8 looks pretty bright from here on out to me. There’s still a lot of work to be done, but we’ve got a pretty good handle on it for now. There were massive improvements once we identified major pain points such as Qt using OpenGL instead of GLES and fixing issues within Qt itself.

I’d also like to take a moment and say a massive thanks to the Pine community as well. They’ve been an amazing group of people to work with. They even released a Wayland driver that could potentially become the building block to deliver a ARMv8 laptop that can run Plasma atop Wayland in the future! Thank you so much, it really is appreciated.

January 15, 2018

Just when I thought to have missed yet another Plasma feature freeze deadline with the one for Plasma 5.12 LTS and thus a good(?) excuse to re-decrease priority of some planned work on the Plasma Addons Weather applet (from the kdeplasma-addons repo, not to be mixed up with clearmartin’s one from github/store.kde.org) once more and thus delay things even further to a day that may never come, the Plasma team found they need to shift the deadline by some weeks to be after the KDE Frameworks 5.42.0 release.
So excuse gone, no other quickly found… time to do a git pull and open the editor.

It’s almost two years ago that the old Plasma Addons Weather applet got ported to Plasma 5 with an initial release in Plasma 5.6. That activity resulted in some plans for further work, which then though met a sad fate of plans… staying on paper to some degree. Let’s revisit the points of the plan and their state:

  • Breeze-style weather state icons: done -> hurra for hard-working Ken
  • Overhaul of look: only cosmetic changes applied, bigger redesign never turned into code -> FAIL
  • support for more weather data providers: a template for provider plugins has been done and added, but no-one ever contributed a plugin for a new provider -> FAIL so far
  • also temperature displayed in compact widget variant, like on panel: got lost in layouting code -> FAIL
  • privacy control which weather data providers are queried on finding weather stations: never worked on -> FAIL

Add to that a Plasma 5 Porting TODO item from the code:

  • Restore night-style icons for observation weather conditions at night: never worked on -> FAIL

Living in some slightly northern of the northern hemisphere, right now the days are short and the temperature is often around the freezing point. Which makes the weather applet look slightly broken and useless: not showing the temperature directly on the panel for a quick glance to check whether it is slippery outside, but showing the weather observation report with the sun symbol in the icon when it is dark outside… who needs or wants that. Still the applet is working too well for just proposing to wipe it from the repos in favour of one of the alternative ones out there. Of course there is also that tiny bit of pride in the porting work done, which begs for throwing more good time after it… ��

So motivation collected, some coding time shuffled free: the fight against the new Plasma 5.12 feature freeze deadline was picked up. And to make the already too long story short, I can now happily report that with the help of Kai Uwe and some further random Plasma developers the last three items can now be checked off as Done starting with Plasma 5.12 ��
(Well, almost, truth is that proper night-style icons are still not available for some stations/providers or delivered data, fixing needs a bigger redesign, which is left for another time)

Selecting which weather service providers to query for a location in the Plasma Weather applet. Spot also the optional temperature shown on both panels next to the weather state icon, as well as proper night-style weather state icon for England’s London during current CET night (sorry for German/English mix in UI, too sleepy for proper setup)

So some 2018 FLOSS contributions of mine done. Now I can slack off the rest of this year! ��
And watch you doing yours by implementing a plugin for your favorite weather data provider?
Which, BTW, will be also useful to any other Plasma applet which makes use of the Plasma Weather dataengine from the plasma-workspace repo.

With all the happiness after being selected for SoK 2018, I was looking forward to start working on my project with whole dedication. My project aims to complete port of a brain-boosting memory activity called “Railroad” (in which kids have to observe the given train and memorize it within given time and then try to rebuild it) from Gtk+ to Qt version. It is a part of project GCompris(a high-quality educational software suite, including a large number of activities for children aged 2 to 10). My mentors are Timothée Giet and Rudra Nil Basu, along with them I’d like to thank a lot to Johnny Jazeix and Divyam Madaan for helping me with my project. My SoK proposal can be found here –> SoK Proposal. And my progress can be tracked at –> Railroad branch.

I started with introducing myself to the GCompris community and discussing my implementation plans with the mentors. My mentors helped me to get my KDE developer account and setup git. First error which I encountered was during git clone, after googling about it and discussing with mentors I got to know that it was due to the firewall(thanks to my college).

My main task for first two weeks was to create a new layout for the activity, make the activity look better in small screen devices and remove horizontal scrolling. This activity was already started during previous SoK, so most of the code was already written. I compiled the activity and started understanding its code, my previous contributions on GCompris helped me to understand the code fastly. Previously it was hard-coded to have a fixed no. of wagons in fixed no. of rows which caused horizontal scrolling. I implemented a GridView based layout which helped to remove the need for horizontal scrolling and made UI look more beautiful.


1. For Horizontal Screens

2. For Vertical Screens

After working on UI, I created five levels based on increasing difficulty and fixed some issues in UI based on reviews from my mentors. Every error opened an opportunity for me to learn something new. I’ll be working on implementing keyboard navigations next week.

Some of the new things which I learned during this project so far
> Importance of Version Control System.
> Quality of code is more important than Quantity of code.
> Dividing a big task into small tasks and then proceeding.
> Using SSH keys.
> An image when opened with a text editor shows real mystery behind it.

In conclusion, SoK proves to be a great experience thus far, being a pleasure to work on a project focused mainly on Education. For further updates, stay tuned!

What happens in Discover in when an app is available from multiple sources–say, Flathub as well as your distro’s packages?

As long as both versions of the app provide the same AppStream ID, Discover will show a single entry and let you choose which one you want to install, like this:

But if any of the available versions use a different AppStream ID, they’ll show up separately:

Uuurgh, how awful. Which GIMP is the real GIMP? And why do they all have different names?! Flathub uses org.gimp.GIMP as the AppStream ID, while The GIMP developers provide gimp.desktop for distros to use as the AppStream ID. And the Snap version provides no AppStream ID, sadly.

So we need the GIMP developers to change their AppStream ID to the same one that Flathub uses (which actually follows the AppStream spec). I submitted a patch to fix it that was recently accepted, so this should be resolved with the next GIMP release. That will unify the first two, but the third–which comes from Snap–won’t get rolled up into it until Snap uses AppStream IDs. The Snap folks are on the case, but it’s still a work in progress.

But adopting AppStream only work as long as developers are populating their AppStream files with valid IDs! An AppStream ID is supposed to look like com.myurl.NameOfMyApp, not NameOfMyApp.desktop or com.myurl.NameOfMyApp.desktop. Flathub gets this right, but a lot of app developers themselves get it wrong, and it’s up to us to help them, and make sure the AppStream IDs in their files match those on Flathub.

I’ve started to submit patches for apps that unify their AppStream IDs:

What can I do to help?

See all those patches I submitted? You can do the same! If you use any apps that have AppStream IDs in their distro packaging that are incorrect and different from what’s in Flathub, then submit a patch to fix it! Keep in mind the following guidelines:

  1. Dashes/hyphens must be replaced with underscores: com.shutter-project.shutter is wrong and should be com.shutter_project.shutter
  2. Leading digits in the app name are not allowed: com.wildfiregames.0ad is wrong and should be com.wildfiregames._0ad
  3. If the AppStream ID used for Flathub is wrong, don’t replicate that wrongness with your patches; encourage developers to use correct AppStream IDs and file a bug for the app on Flathub, like this one.

For extra credit, you can also submit patches that add <release> information, too. This will make the app’s version string show up in Discover:

And here’s the properly formatted <release> information in HexChat’s AppStream file that provides it: https://github.com/hexchat/hexchat/blob/master/data/misc/io.github.Hexchat.appdata.xml.in#L29

I know this isn’t the most immediately rewarding work, but it’s super important to make Flatpak (and later Snap) work properly in a mixed environment where you also have distro packages available. If you want the world to be Snappier or more Flatpacked, this is probably the easiest way to make it happen if you’re not a programmer or a packager. If you need a hand, you can email flatpak@lists.freedesktop.org or check out the #flatpak IRC channel on freenode.org.

As always, if you find this work useful or valuable, please consider becoming a KDE contributor or donating to KDE! But do consider submitting patches for Apps that have sparse or incorrect AppStream data. You’ll be doing your part to pull Linux software distribution into the future.release

January 14, 2018

People often ask about the state of Flatpak in Discover, so today I’m going to write about that. Thew good news is that Discover’s Flatpak support is very good and getting better all the time. It’s fully production ready and we encourage you to use it!

To download Flatpak apps in Discover, you need to have the Flatpak backend installed. In many distros, it’s a separate package that doesn’t come installed by default. In Ubuntu-based distros, you can install it by running sudo apt install plasma-discover-flatpak-backend. in Discover 5.12, you’ll even be able to install different backends from within Discover itself, by searching for “Flatpak” or “Snap”. If you want faster Flatpak adoption, please petition your distros to install the Flatpak backend by default!

Once the Flatpak backend is installed, you need to add at least one Flatpak repo. Distros can provision this with default entries, but most don’t. Bug your distro if you want a better experience here! Until then, you can go to Discover’s Settings page and click the “Add Flathub” button to add Flathub as a source. After that, you can access Flatpak apps by browsing or searching through the app lists as normal. You can also go to the settings page and click on the Flatpak entry, which will show you just the Flatpak apps from that repo:

You can add multiple Flatpak repos; to do so, go to the Settings page, click the Hamburger menu button next to the text “Flatpak”, and click “Add Source…” Then enter the URL of the Flatpak repo you want to add. Discover also handles this properly when you click on a repo URL in your web browser.

Multiple Flatpak repos enable users to effortlessly switch between stable and up-to-date versions of apps, each version provided by a different repo. Right now, we’re generally stuck with one or the other, according to our distro’s packaging policy: Arch and other rolling distros say that you always get the latest version; Debian and Ubuntu and other stable release distros say that you always get a specific version that’s frozen in time. Sometimes that’s not right for you, because maybe the latest version has a bad bug, or an old stable version is missing features you want that were implemented in a later version.

Flatpak liberates us from this. You could add Flathub (https://flathub.org/repo/flathub.flatpakrepo) and also KDE’s nightly testing repo (https://distribute.kde.org/kdeapps.flatpakrepo). Then when you go to install a KDE app that’s present in both, you can choose the source! Maybe you want to live on the bleeding edge, but if you run into an issue, you can easily revert your installation to the stable version. It’s pretty awesome.

If any of this seems cool and useful, please don’t hesitate to join our team or make a donation to KDE. My next post shares some specific things you can do to help push Flatpak adoption, even without being a programmer.

Lac Mirroir, Le Melezet, Ceillac, French Alps

Following the release of 5.7.0 published in September 2017, the digiKam team is proud to announce the new release 5.8.0 of the digiKam Software Collection. In this version a lot of work has happened behind the scenes and in fixing bugs as usual, which does not mean there are no enhancements: a new tool to export collections to UPNP/DLNA compatible devices has been introduced.

Bugs Triage

Following the large update of bug categories processed before the previous release, we have been able to reassign entries to the right components. With the help of pre-release bundles computed each day, we have been able to provide a digiKam test version along with the fixes applied to close reports in bugzilla. The result with this release is a set of more than 200 entries officially closed.

Application Bundle Improvements

MacOS and Windows digiKam Installers in Action

For each platform supported by the digiKam project, we propose a bundle package ready to use, which embed all the needs to have a suitable application. digiKam project confirm the support of The AppImage format as the best Linux bundle, which has been updated to last SDK available in build virtual machine based on Linux Centos. This one now permits to run the bundle under Firejail sandboxing technology for a better security level..

Showfoto Running Under Windows

The Windows installer is now built with the latest NSIS version to be compatible with Windows 10. The installer code has also been cleaned to remove obsolete packaging plugins and to prevent false virus detections while installing. Note that all digiKam Windows bundles are fully built under Linux with the MXE cross-compiler and there is no risk to inject Windows viruses in the application.

Showfoto Running Under MacOS

All bundles, including the MacOS package build with the latest Packages, now include more optional features available on digiKam and also Showfoto, as some new low level libraries have been ported to pure Qt5, such as digital scanner support and events file support with export to Calendar tool.

Mysql Support Improvements

Mysql Config Panel and Migration Tool

A lot of work has been done around the Mysql support with the help of end users testing step by step progress and the relevant fixes applied daily. For these hacking stages, the pre-release bundles have really helped a lot, by providing a ready to use beta version of digiKam including all debug statements necessary to investigate the dysfunctions, especially for the database schema update performed on older collections hosted on a Mysql or Mariadb server. The migration tools have also received many fixes, especially to move from Sqlite databases, when collections grow substantially and over time become more and more slow. Now, the migration tool can import and export better from/to Mysql or Sqlite without data-loss while databases are being converted.

Export to UPNP/DLNA devices

New Tool to Share Collections With DLNA Devices

In September 2017, the digiKam team has been invited to take part in the Randa Meetings. In this tiny town in the Swiss alps a lot of KDE developers work on improving their software. We have focused the reunion on including the new media server dedicated to sharing collection contents on local networks with compatible DLNA devices or applications, such as tablets, cellulars, TV, etc. This tool is now available in all digiKam views through the main Tools menu and also in Showfoto.

Showofoto DLNA Server Visible into VLC

There are plenty of DLNA applications available in digital stores like iTunes or GooglePlay. As the DLNA and UPNP protocols are standardized, we don’t need to develop dedicated applications for each client device that wants to access the digiKam/Showfoto contents.

Port DropBox Export Tools to OAuth2

digiKam DropBox Export Tool Running Under Windows

Concerning digiKam export tools to remote Internet services, the port to OAuth version 2 is advancing steadily with more work planned in the course of the year. After porting the Flickr and Imgur export tools with the 5.7.0 release, the DropBox export tool is now ported to the new authentication API, so after a short time of dysfunction the tool is back and ready for use in production. In the future other tools, such as Facebook and GPhoto export, will be ported to OAuth version 2. This will probably be a subject for the students working with us for the upcoming Google Summer of Code 2018.

Final Words

As always, but especially noteworthy this time, you can look at the list of 231 resolved issues for detailed information.

digiKam 5.8.0 Software collection source code tarball, Linux 32/64 bits AppImage bundles, MacOS package, and Windows 32/64 bits installers can be downloaded from this repository.

Happy new year 2018 and happy digiKaming!

January 12, 2018

Elisa is a music player designed to be simple and nice to use. It allows to browse music by album, artist or all tracks. You can build and play your own playlist. We aim to build a fluid interface that is easy to use.

We are preparing for the next alpha release when the following features will be done. Alexander is working on a metadata view for tracks. I am working on cleaning the different grid views into a generic one.

Diego Gangl did several modifications of the interface as part of the interactions with KDE VDG.

All in all, Elisa now looks like that:

Screenshot_20180112_174013Snapshot of album view including the changed application menu

The following things have been integrated in Elisa git repository:

  • Fix modification of files with DatabaseInterface::modifyTracksList by Matthieu Gallien ;
  • This patch increases the blur in the headerbar background, increases contrast
    between background and text, and brings the labels closer together by Diego Gangl ;
  • Tune appearance of all albums and all artists views by Matthieu Gallien ;
  • Fix wrong id reference in FilterBar by Matthieu Gallien ;
  • In all models, calls base class roleNames before adding new role names by Matthieu Gallien ;
  • Simplify the definition of custom roles in all models by Matthieu Gallien ;
  • Allow MusicArtist to be stored in a QVariant by Matthieu Gallien ;
  • Allow to enqueue artist in MediaPlayList by using MusicArtist objects by Matthieu Gallien ;
  • Change height of delegate in GridView by Matthieu Gallien ;
  • Fix a typo in the imported tracks notification by Diego Gangl ;
  • Make shadows centered and slightly larger. Fits better with other shadows in the
    desktop (like dolphin and widgets), and it also aligns with the new shadows for
    breeze (D9549) by Diego Gangl ;
  • Fixes key arrow navigation in list and gridviews and implements enter and return key actions for delegates by Alexander Stippich ;
  • Allow elisa to open any external files, scan them and enqueue them by Matthieu Gallien ;
  • Syncs the windows theme file with the current main theme file. Removes bundled icons for windows which are not needed as proven by ViewSelector.qml, but also tested on windows by Alexander Stippich ;
  • Make the delegates more appealing when using a dark theme also add hover animations while keeping the loader component by Alexander Stippich ;
  • Fix keyboard navigation for album artist view too by Alexander Stippich ;
  • Move all icon and image definitions to theme file and make some consistency fixes. In anticipation of a colorized version of the artist image, there are two definitions which currently hold the same icon. Also enables the display of a default cover in context view by Alexander Stippich ;
  • qml profiler shows a few percent of cpu time spent just for the creation for simple buttons for the delegates. cut this by loading on demand by Alexander Stippich ;
  • Try to find png files for covers if jpegs do not exist can probably be made a lot smarter than this, but kept it simple for now by Alexander Stippich ;
  • Try to fix build (as seen on binary-factory.kde.org) by Matthieu Gallien ;
  • Re-order menu items to fit better with the order used in other KDE applications by Diego Gangl.

 


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.