June 17, 2019

Yes, I know. The last post on the assistants is rather boring. And yet these days I have been working on the snapshot docker, though it still seems a little (just a little, you see) unfinished as Dmitry is said to experience a relatively high delay when switching between snapshots. However this is not what I can reproduce on my older laptop, so I am really waiting for his test results in order to further investigate the problem.

But there is something interesting happening just when I am randomly testing things. FromKrita’s debug output, I saw QObject::connect() complaining about the arguments I passed, saying it is expecting parenthesis. “Okay,” I thought, “then there have to be something wrong with the code I wrote.” And that was quite confusing. I remember having used member function pointers in those places, got a compile-time error since KisSignalAutoConnectionsStore did not support the new syntax,then switched back to the SINGAL() and SLOT() macros. KisSignalAutoConnectionsStore is a helper class to quickly (dis)connect a group of connections. One can use the addConnection() method to add a connection, and use clear() to remove all connections made before.

Well, everything good, apart from the fact that I missed the parenthesis, which I did not discover until I looked into the debug output. So I asked Dmitry why not add the new syntax to KisSignalAutoConnectionsStore, and he said we should.

What is good about the new syntax is compile-time checking. We probably do not want our connectionsto fail to be made only when you run the program, just because there is a typo in the signature. That is definitely tiring and hard to catch (hmm, I did not notice the problem until today I randomly glanced at the command line; it might be worse if I shipped the snapshot docker together with those careless bugs).

The modification to the code seems straightforward. All what happens is in the KisSignalAutoConnection class. In its constructor, the connection is made using QObject::connect(); in its destructor, the connection is removed by passing the same sets of arguments to QObject::disconnect() currently in master. The signature is just KisSignalAutoConnection(const QObject *, const char *, const QObject *, const char *), as SIGNAL() and SLOT() macros are but to append their arguments to the string "1" and "2" respectively.

So the problem we have is we do not want the arguments that specify the signals and/or slots to be just strings. We want them to be pointers to member functions, or maybe lambdas. According to QObject document, the signature for new-style connect() is:

1
QMetaObject::Connection QObject::connect(const QObject *sender, PointerToMemberFunction signal, const QObject *context, Functor functor, Qt::ConnectionType type = Qt::AutoConnection)

Okay, so we know that sender and receiver should be pointers to QObjects, and either the type of signal or functor we do not know. Now let’s make our KisSignalAutoConnection constructor a template function:

1
2
3
4
template<class Signal, class Method>
inline KisSignalAutoConnection(const QObject *sender, Signal signal,
const QObject *receiver, Method method
Qt::ConnectionType type = Qt::AutoConnection);

But when these parameters are passed to QObject::connect(), we get a compile-time error, saying there is no matching overload for connect().

Why?

The answer is the Qt documentation is simplifying, if not hiding, the truth. The real definition for connect() is found in Line 227 of qobject.h:

1
2
3
4
template <typename Func1, typename Func2>
static inline QMetaObject::Connection connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal,
const typename QtPrivate::FunctionPointer<Func2>::Object *receiver, Func2 slot,
Qt::ConnectionType type = Qt::AutoConnection)

And tracking down the definition of QtPrivate::FunctionPointer, we get it in qobjectdefs_impl.h:

1
2
3
4
5
template<class Obj, typename Ret, typename... Args> struct FunctionPointer<Ret (Obj::*) (Args...)>
{
typedef Obj Object;
...
};

And seeing what we have passed to KisSignalAutoConnection (in the test code):

1
2
KisSignalAutoConnectionsStore conn;
conn.addConnection(test1.data(), &TestClass::sigTest1, test2.data(), &TestClass::slotTest1);

We can see that Func1 is a member function of TestClass, so QtPrivate::FunctionPointer<Func1>::Object is just TestClass. But the constructor of KisSignalAutoConnection receives a const QObject *. The problem here is that connect() is expecting a const TestClass *, but we give them a const QObject *. A base class pointer cannot be implicitly converted to a derived class pointer, so we have that error.

The resolution seems pretty simple, as we only need to include the types of sender and receiver into the template, and pass everything as-is to QObject::connect():

1
2
3
template<class Sender, class Signal, class Receiver, class Method>
inline KisSignalAutoConnection(Sender sender, Signal signal, Receiver receiver, Method method,
Qt::ConnectionType type = Qt::AutoConnection);

Sounds viable. But how can we store the four parameters? It might be intuitive to make another base class, say, KisSignalAutoConnectionBase(), and make KisSignalAutoConnection a template class, so we can store sender, receiver, etc.

But wait, isn’t this just too complex? First of all, we do not have any overridden functions except for the destructor. What is more, we do not seem to have any valuable things in that base class – it would be an empty class. The use of inheritance here is ugly and useless.

And, we do not need to store the four parameters at all. QObject::connect() returns a QMetaObject::Connection, which can be used later to disconnect() it. So instead of the parameters passed to connect(), we just store the Connection object. And that is not part of the template:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public:
template<class Sender, class Signal, class Receiver, class Method>
inline KisSignalAutoConnection(Sender sender, Signal signal, Receiver receiver, Method method,
Qt::ConnectionType type = Qt::AutoConnection)
: m_connection(QObject::connect(sender, signal, receiver, method, type))
{
}

inline ~KisSignalAutoConnection()
{
QObject::disconnect(m_connection);
}

private:
QMetaObject::Connection m_connection;

And with the test code mentioned above, we do make sure that the new implementation works well with both syntaxes.

So, great, krita developers, we can use the new syntax for auto connections as well.

PS: There will soon be another post on my work of the snapshot docker – it’s almost finished!

June 16, 2019

El verdadero noveno podcast de la quinta temporada de los podcast de KDE España llega justo antes de finalizar el mes. En esta ocasión el tema seleccionado será KDE y software para el arte IV, el cual estará dedicado a la creación literaria de, tanto en la parte creativa como la maquetación. Como siempre, en directo pero que dejaremos grabado para la posteridad, el próximo 17 de junio a las 21:30.

KDE y software para el arte IV: literatura próximo podcast de KDE España

KDE y software para el arte IV: literatura próximo podcast de KDE España

Siguiendo la serie de KDE y software para el arte, los integrantes de KDE España han decidido que su siguiente capítulo estará dedicado a la literatura.

Así que el próximo lunes 17 de junio de 2019 a las 21:30 os esperamos a todos para poder compartir un buen rato.

Como siempre, para poder disfrutar del podcast en directo seguiremos utilizando los servicios de acontecimiento en vivo de Youtube y contestaremos, si podemos, vuestras preguntas en directo

Para los amantes del metapodcasting, este podcast será el cuarto de este 2019 y con él llegaremos al noveno de la quinta temporada.

 

¡Os esperamos el lunes 17 de junio a las 21:30!

Los podcast de KDE España

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

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

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

Finally, KBibTeX 0.9 got released. Virtually nothing has changed since the release of beta 2 in May as no specific bugs have been reported. Thus ChangeLog is still the same and the details on the changes since 0.8.2 as shown on the release announcement for 0.9-beta2.

Grab the sources at KDE&aposs download mirrors.



comment count unavailable comments

KMyMoney as a financial application deals with numbers a lot. As a KDE application, it supports internationalization (or i18n for short) from the very beginning. For accuracy reasons it has internal checks to verify the numbers a user can enter.

The validation routine has a long history (I think it goes back to the KDE3 days) and we recently streamlined it a bit as part of the journey to use more and more Qt standard widgets instead of our own.

This led to the replacement of the KMyMoneyEdit widget with the newer AmountEdit widget. Everything worked great for me (using a German locale) until we received notifications that users could only enter integer numbers but no fractional part. This of course is not what we wanted. But why is that?

The important piece of information was that the user reporting the issue uses the Finland svenska (sv_FI) locale on his system. So I set my development system to use that locale for numbers and currencies and it failed for me as well. So it was pretty clear that the validation logic had a flaw.

Checking the AmountValidator object which is an extension of the QDoubleValidator I found out that it did not work as expected with the said locale. So it was time to setup some testcases for the validator to see how it performs with other locales. I still saw it failing which made me curious so I dug into the Qt source code one more time, specifically the QDoubleValidator. Well, it looked that most of the logic we added in former times is superfluous meanwhile with the Qt5 version. But there remains a little difference: the QDoubleValidator works on the symbols of the LC_NUMERIC category of a locale where we want to use it the LC_MONETARY version. So what to do? Simply ignore the fact? This could bite us later.

So the next step was to check what happens within the testcases: Using the current code base they fail. Ok, good news I caught the problem. Using the plain QDoubleValidator and running the testcases again showed that all were positive. So no problem? What if a locale uses different symbols for the decimal point and the thousands separator? Does such a locale exist? Looking at all of them seemed a bit tedious, but tedious work is something for a computer. Here’s the little script I wrote (for simplicity in Perl):

So, they do exist. Bummer, we need to do something about it. On my box, I collect 484 locales where 110 show differences. That’s close to 25% of the locales, too much to simply ignore the problem. Since some of the locales where present in multiple formats (e.g. br_FR, br_FR@euro and br_FR.utf8) I concentrated on the utf8 versions and the ones that contained an at-sign in their name). This modified the figures to 37 with differing values out of 182 locales checked. Still 20%. Here’s that list. <> denotes an emtpy string, and _ denotes a blank in the locale. If I would not replace those values one could not see a difference in a terminal session.

 Locale          dp      mon_dp  sep     mon_sep
 aa_DJ.utf8      .       .       <>      _
 aa_ER@saaho     .       .       <>      ,
 be_BY@latin     ,       .       .       _
 be_BY.utf8      ,       .       .       _
 bg_BG.utf8      ,       ,       <>       
 bs_BA.utf8      ,       ,       <>      _
 ca_AD.utf8      ,       ,       <>      .
 ca_ES@euro      ,       ,       <>      .
 ca_ES.utf8      ,       ,       <>      .
 ca_FR.utf8      ,       ,       <>      .
 ca_IT.utf8      ,       ,       <>      .
 de_AT@euro      ,       ,       .       _
 de_AT.utf8      ,       ,       .       _
 es_MX.utf8      .       .               ,
 es_PE.utf8      ,       .       .       ,
 eu_ES@euro      ,       ,       <>      .
 eu_ES.utf8      ,       ,       <>      .
 gez_ER@abegede  .       .       <>      ,
 gl_ES@euro      ,       ,       <>      .
 gl_ES.utf8      ,       ,       <>      .
 hr_HR.utf8      ,       ,       <>      _
 it_CH.utf8      ,       .       '       '
 it_IT@euro      ,       ,       <>      .
 it_IT.utf8      ,       ,       <>      .
 mg_MG.utf8      ,       ,       <>      _
 nl_BE.utf8      ,       ,       .       _
 nl_NL@euro      ,       ,       <>      _
 nl_NL.utf8      ,       ,       <>      _
 pl_PL.utf8      ,       ,       <>      .
 pt_PT@euro      ,       ,       <>      .
 pt_PT.utf8      ,       ,       <>      .
 ru_RU.utf8      ,       .                
 ru_UA.utf8      ,       .       .       _
 so_DJ.utf8      .       .       <>      _
 sr_RS@latin     ,       ,       <>      .
 tg_TJ.utf8      ,       .       .       _
 tt_RU@iqtelif   ,       .       .        
 182 locales processed, 37 locales differ.

Next I went in and tried to figure out what differences exist. A bit of UNIX foo (i.e. combining the tools of your toolbox) shows the results:

./checklocales | tr '\t' ':' | cut -d: -f2- | tr ':' '\t' | sort | uniq | grep -v "mon_dp" | grep -v "process"

reveals the following result (I added the header here manually):

 dp      mon_dp  sep     mon_sep
 ,       ,       <>      _
 ,       ,       <>      .
 ,       ,       .       _
 ,       .       .       _
 ,       .       .       ,
 ,       .       .        
 ,       .       '       '
 .       .       <>      _
 .       .       <>      ,
 .       .               ,
 ,       ,       <>       
 ,       .                

Running this additionally through “wc -l” shows 12 different combinations. The last one is strange, because it does not show anything in the last two columns. Looking at the full table shows that this is the entry produced by ru_RU.utf8. Why is this now? Running

LC_ALL=ru_RU.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep

we get

 decimal_point=","
 mon_decimal_point="."
 thousands_sep=" "
 mon_thousands_sep=" "

which looks just fine, but why did we not see the underbar for the blanks in the thousands separator? Running the above output through our friend od we see why:

LC_ALL=ru_RU.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep | od -c
0000000   d   e   c   i   m   a   l   _   p   o   i   n   t   =   "   ,
0000020   "  \n   m   o   n   _   d   e   c   i   m   a   l   _   p   o
0000040   i   n   t   =   "   .   "  \n   t   h   o   u   s   a   n   d
0000060   s   _   s   e   p   =   " 302 240   "  \n   m   o   n   _   t
0000100   h   o   u   s   a   n   d   s   _   s   e   p   =   " 302 240
0000120   "  \n
0000122

Ah, “302 240” octal: that is some UTF-8 encoded character presented as a blank in my default locale. Ok, since it is the same no big deal. But there are two more:

 ,       .       .        
 .       .               ,

Going into the long list we see that these are the results of tt_RU@iqtelif and es_MX.utf8. Looking at od’s output we see:

LC_ALL=tt_RU@iqtelif  locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep | od -c
0000000   d   e   c   i   m   a   l   _   p   o   i   n   t   =   "   ,
0000020   "  \n   m   o   n   _   d   e   c   i   m   a   l   _   p   o
0000040   i   n   t   =   "   .   "  \n   t   h   o   u   s   a   n   d
0000060   s   _   s   e   p   =   "   .   "  \n   m   o   n   _   t   h
0000100   o   u   s   a   n   d   s   _   s   e   p   =   " 342 200 202
0000120   "  \n
0000122
LC_ALL=es_MX.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep | od -c
0000000   d   e   c   i   m   a   l   _   p   o   i   n   t   =   "   .
0000020   "  \n   m   o   n   _   d   e   c   i   m   a   l   _   p   o
0000040   i   n   t   =   "   .   "  \n   t   h   o   u   s   a   n   d
0000060   s   _   s   e   p   =   " 342 200 211   "  \n   m   o   n   _
0000100   t   h   o   u   s   a   n   d   s   _   s   e   p   =   "   ,
0000120   "  \n
0000122

so again just some special chars which are shown as blank, but they differ between numeric and currency representation in the said locales.

While trying a few things I stumbled across the following output. See for yourself:

LC_ALL=C.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep
decimal_point="."
mon_decimal_point="."
thousands_sep=""
mon_thousands_sep=""
LC_ALL=C locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep
decimal_point="."
mon_decimal_point=""
thousands_sep=""
mon_thousands_sep=""

What? The C locale (non UTF-8 version) has no monetary decimal point defined? This may end in strange results, but since nowadays we talk about UTF-8 I simply put it aside.

Back to the original problem: the AmountValidator. Looking at the results above, it seems not to make sense to simply use the QDoubleValidator version. Would it make sense to allow both versions? To use the QDoubleValidator we would need to replace the currency versions of the two characters with their numeric version. The question is: would that lead to false strings in any of the locales? Looking at the long list, we find the following where both characters are different:

 Locale          dp      mon_dp  sep     mon_sep
 be_BY@latin     ,       .       .       _ 
 be_BY.utf8      ,       .       .       _ 
 es_PE.utf8      ,       .       .       , 
 ru_UA.utf8      ,       .       .       _ 
 tg_TJ.utf8      ,       .       .       _ 
 tt_RU@iqtelif   ,       .       .         

es_PE.utf8 seems to be the worst candidate. The meaning is simply reversed. Let’s add this locale to the testcases and see how it performs.

Looks like it works out of the box. Strange, I expected a different result. Anyway, the changes to KMyMoney are now committed to the master branch and I can continue with the next problem.

Me complace compartir con vosotros que la capital del Turia se está convirtiendo en una de la ciudades que más eventos relacionados con el Software Libre acoge. Y es que a partir de mañana lunes, la Comunidad KDE celebra en València varios Sprints relacionados con varios proyectos. Para ser más específicos: una reunión de la Junta de KDE e.V., uno de Plasma y otro de Usabilidad y produtividad.

La Comunidad KDE celebra en València varios Sprints

Tal y como podemos leer en el blog de Aleix Pol, Vicepresidente de KDE e.V. y uno de los desarrolladores más activos de la Comunidad KDE, durante los próximos días se van a celebrar varios sprints en València en los locales de Slimbook.

La Comunidad KDE celebra en València varios Sprints

Actual Junta Directiva de KDE e.V.. De izquierda a derecha: Sandro Andrade, Eike Hein, Lydia Pintscher, Aleix Pol i González y Thomas Pfeiffer

Para los que no le sepan, Los sprints de KDE son pequeñas reuniones que se organizan en cualquier ciudad donde se dan cita los desarrolladores para dar un empujón a alguno de los equipos de trabajo de KDE.

Estas reuniones tienen su página oficial y suelen ayudar económicamente a los asistentes. El objetivo principal es que los proyectos KDE sigan creciendo y siguiendo el método combinado de trabajo virtual a lo largo del año con encuentros físicos para unir lazos.

De esta forma, el lunes y el martes se celebrará reuniones de la Junta de KDE e.V., dejando el resto de semana espacio para dos grandes sprints:

  • Plasma: donde planificaremos y trabajaremos en las funciones para el próximo año (¡o más!)
  • Usabilidad y productividad: donde se trabajará en la mejora de diversas aplicaciones y componentes de KDE que necesitan atención para optimizar su rendimiento.

Por otra parte, con el objetivos de acercar a los desarrolladores al público en general, se están organizando cenas abiertas para que puedas unirte y pedirnos cualquier cosa.

Concretamente, la cena de la Junta será el próximo lunes 17 de junio a las 20:30 y la de usabilidad será el próximo sábado 22 de junio a las 20:30.

Para asistir debes enviar un correo electrónico a aleixpol@kde.org para informarte de los detalles.

¡No te pierdas esta gran oportunidad de conocer a algunos de los desarrolladores de KDE!

 

Week 75 in KDE’s Usability & Productivity initiative is here! It’s a little lighter than usual because we’re all feverishly preparing for the dual Plasma and Usability & Productivity sprints nest week in Valencia, Spain. I’ll be there, as well as the whole Plasma team, a bunch of VDG people, and a number of folks who have stepped up to work on apps for the U&P initiative. Sprints like these promise the kind of face-to-face contact needed for big projects, and should be a fantastically awesome and productive time! I’d like to offer a special thanks to Slimbook (makers of the KDE Slimbook II laptop) for hosting the sprint!

Anyway, here’s the week’s report:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

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

If you find KDE software useful, consider making a donation to the KDE e.V. foundation.

We are seeing a strange trend nowadays: The terminal is being more widely used in windows, after they fixed the broken cmd.exe and MS is actually actively promoting their terminal applications like Visual Studio Code and the new Windows Terminal, but on the other hand the Unix world was always terminal based, even if you tend to use the Desktop Environment for your daily needs you probably also had a Terminal open somewhere.

And because we had always been terminal users, there are a lot of terminals for Linux, But it’s not easy to keep a terminal up to date, it’s usually fragile code and hard to maintain, that means that a lot of projects, good projects, are abandoned.

Good terminals that unfortunately didn’t make it

  • Tilix: Is one of the best terminal emulators out there, it’s a shell written in D, on top of VTE, the author lacks the time to continue working on it.
  • Terminator: I don’t know if this one is abandoned as there’s no news on the web about it, the news that I know is that version 2 is scheduled for release in 2017, never happened though.

If you are sad that your favorite terminal is without a maintainer, try to maintain it, free software depends on developers.

The state of Konsole:

  • Konsole is receiving more reviews, more code and more contributors in the last year than it got in the past 10 years.
  • In the past, the project is kept alive by Kurt, and he did an awesome job. But a project as big as konsole needs more people.
  • Three new developers joined konsole and are activelly fixing things over the past year, no plans to stop.
  • Terminator / Tilix split mode is working
  • A few features to be completely equal to minix / terminator is missing, but not hard to implement

Now it has more developers and more code flowing, fixing bugs, improving the interface, increasing the number of lines of code flowing thru the codebase. We don’t plan to stop supporting konsole, and it will not depend on a single developer anymore.

We want konsole to be the swiss army knife of terminal emulators, you can already do with konsole a lot of things that are impossible in other terminals, but we want more. And we need more developers for that.

Konsole is, together with VTE, the most used terminal out there in numbers of applications that integrate the technology: Dolphin, Kate, KDevelop, Yakuake, and many other applications also use konsole, so fixing a bug in one place we are helping a lot of other applications too.

Consider joining a project, Consider sending code.

June 15, 2019

Estas últimas semanas están plagadas de noticias sobre eventos de la Comunidad KDE. Y es que hace unos días hablábamos del programa de Akademy-es 2019 de Vigo, hoy toca hablar de que se ha abierto el registro a Akademy 2019 de Milano, el evento internacional de KDE que se celebrará del 7 al 13 de septiembre.

Abierto el registro a Akademy 2019 de Milano

Como suele ser habitual, los eventos relacionados con el Software Libre, aunque son de entrada libre y gratuita requieren un registro previo para contabilizar participantes y poder prevenir problemas de espacio.

Akademy 2019 de Milano no es una excepción y el pasado 6 de junio abrió su plataforma de registro de asistentes, donde además de proporcionar una estimación de asistentes se suelen preguntar quienes participarán a algunos de los eventos lúdicos o gastronómicos que suelen acompañar a este tipo de eventos.

Si eres simpatizante del Proyecto KDE y puedes asistir, no te la puedes perder. Conocer cara a cara a los principales desarrolladores KDE no tiene precio y es una experiencia única.

Además, no olvidemos que después de los dos días de charlas, se celebran 5 días de intenso trabajo de hacking donde además de picar código se realizan talleres donde se enseña, se discute, se alinean posturas y se fijan las bases del desarrollo de partes de KDE, como Plasma, que se seguirán a lo largo de un año.

Así que si lo tienes claro, no lo dudes y regístrate. Estoy seguro que no te arrepentirás.

¿Qué es Akademy?

Para los que no lo sepan, Akademy es el evento de la Comunidad KDE que aúna en una gran conferencia todo tipo de simpatizantes de KDE como desarrolladores, diseñadores, usuarios, traductores, promotores. Allí se reunirán a lo largo de una semana para compartir charlas, cenas, ponencias, talleres y, en definitiva, para trabajar juntos.
Es una gran semana que sirve para unir más fuerte los lazos que unen nuestra Comunidad, así como para crear nuevos.

Akademy lleva realizándose anualmente bajo este nombre desde 2004, en la página web oficial o en la wikipedia podéis encontrar los nombres y fechas anteriores eventos.

Para que os hagáis una ligera idea de la magnitud del evento, os dejo una imagen de grupo de Akademy 2017 de Almería en la que tuve la suerte de participar.

Abierto el registro a Akademy 2019 de Milano

In the last week, there have been various small improvements to the kde.org website.

Search bar in kde.org/applications

KDE has a lot of applications and with the last update to kde.org/application made by Jonathan Riddell, all these applications are now displayed on the website.

The problem is that it’s now difficult to search for a specific application, so I added a search bar to this page. See Merge request 5 kde-org-applications

Search bar in kde.org/applications

Support multiple screenshots per application

According to the AppStream specification, an application can have multiple screenshots. If before only the first screenshot was displayed, now all screenshots are displayed in a carousel. See Merge request 3 kde-org-applications

Adding schema.org information

The application page now contains some additional metadata information. This can help search engines to better understand the content of the webpage. See Merge request 7 kde-org-applications

Improving the Plasma product page

With Plasma 5.16, we now have a new wallpaper, so I changed the wallpaper displayed at kde.org/plasma-desktop. Problem: the contrast between the text and the background wasn’t great. So I added a small breeze like window, created only with CSS and HTML.

Window breeze like with only CSS

Junior jobs

There still are a lot of things that can be improved, and we would appreciate some help to do it. If you always wanted to contribute to KDE, but don’t have any knowledge in Cpp and Qt, then you can also help with web development.

If you are interested, I listed some junior jobs.

  • The carousel used to display the application screenshots still has some problems. The next and previous buttons don’t use the same theme as the carousel shown on the homepage. Also, when screenshots have a different size, the transition is not perfect. For more information, see bug 408728.

  • We need to add a description for each page in kde.org. This will improve the SEO used for KDE. First we need to define the new variable in aether, use it, and then we can start adding descriptions. This task needs to be done in cooperation with kde-promo and this should help with Search Engine Optimization (SEO).

I wrote a small installation instruction on how to setup your local development environment. And if you need any help, you can as always contact me in Mastodon at @carl@linuxrocks.online or with matrix at @carl:kde.org.

June 14, 2019

During the next days, we’ll be having several sprints in València.

First we’ll be having the KDE e.V. Board on Monday and Tuesday then we’ll be having two big sprints:

  • Plasma, where we’ll be planning and working on the features for the next year (or more!)
  • Usability & Productivity goal’s that will look into different applications and components in KDE that need attention to work properly and improve them.

If you are around and you’d like to meet the different groups, we’ll be having open dinners so you can join and ask us anything.

  • The Board dinner will be next Monday 17th June at 20:30.
  • The Plasma & Usability dinner will be next Saturday 22nd June at 20:30.

Send me an e-mail to aleixpol@kde.org saying when you’d like to come.
The location will be decided depending on the amount of people who ends up coming.

Last but not least, big thanks to Slimbook for hosting us for this sprint! ��

This would start with a quote: Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing.

The KDE Applications website was a minimal possible change to move it from an unmaintained and incomplete site to a self-maintaining and complete site.  It’s been fun to see it get picked up in places like Ubuntu Weekly News, Late Night Linux and chatting to people in real life they have seen it get an update. So clearly it’s important to keep our websites maintained.  Alas the social and technical barriers are too high in KDE.  My current hope is that the Promo team will take over the kde-www stuff giving it communication channels and transparancy that doesn’t currently exist.  There is plenty more work to be done on kde.org/applications website to make it useful, do give me a ping if you want to help out.

In the mean time I’ve updated the kde.org front page text box where there is a brief description of KDE.  I remember a keynote from Aaron around 2010 at Akademy where he slagged off the description that was used on kde.org.  Since then we have had Visions and Missions and Goals and whatnot defined but nobody has thought to put them on the website.  So here’s the new way of presenting KDE to the world:

Thanks to Carl and others for review.

 

June 13, 2019

Time for another development update. The last one was in April. We skipped reporting on May, because doing a release takes a lot of time and effort and concentration! And then we had to do a bugfix release in the first week of June; the next release, Krita 4.2.2, will be out by the end of this month.

We’re still fixing bugs like crazy, helped by long-standing community member Ivan Yossi, who started fixing bugs full-time in May, too.

But then, we’re also getting a crazy number of bug reports. Honesty compels us to say that many of those reports are not so very valuable: there are many people with broken systems who report problems that we cannot solve in Krita, and many people report bugs without telling us anything at all. Hence we created a manual page on reporting bugs! But there are also many helpful bug reports that give us a chance to improve things.

So, how does Krita’s development work these days? Well, there are the many people who work on Krita as volunteers, which has always been the mainstay of Krita development. Then there are this year’s four Google Summer of Code students, who are all making good progress in their projects.  Krita has participated in every edition of Google Summer of Code since the beginning.

But these days, there are four people working on Krita full-time, thanks to donations, the development fund (which we’re working on to revamp a bit and make it more useful to supporters, too), the Windows Store and the Steam Store. None of us is exactly getting rich, but we’re getting by. And we’re doing stuff that would otherwise be hard to do: projects that take several weeks or months to complete, fixing lots of bugs all over the place, doing janitorial stuff like fixing warnings and so on.

Since this is a development update, we’ll just in passing mention all the great work that’s been done on this website, the manual, and all the work supporting our users on places like the forum or reddit.

We’re all hanging out on the Krita IRC channel, which is the main place where contributors to Krita come together to discuss whatever needs to be discussed. We have a weekly meeting every Monday from 14:00 to 15:00 CE(S)T — which means that if you’ve got a question about Krita, that’s probably not the right time to join the channel.

In August, we’ll have another Krita Sprint, a big one, with 25 people attending. Half of the people coming to the Sprint are contributors, half are artists and half are both.

So, that’s how our community in general works — but what did we do specifically, since the release? Since 4.2.0, we released 4.2.1 with a bunch of bug fixes already, and the fixing has not abated. Tiar has finished most of the work on making Krita report back any and all failures when saving an image. Dmitry has been fixing some severe issues in the layer stack, GPU canvas and tool handling, Boudewijn has been fixing bugs all over the place and Ivan has been busy with animated brush tips (that is, Gimp Image Hose files).

Color is random, left and right hands come one after the other, and hand direction  is dependent on drawing direction. Image by Ivan Yossi.

Not for 4.2.2, but 4.3 (which should be out in September) are two new features already: the palettize filter by Carl Olsson, still work in progress, but that’s fine, 4.3 isn’t done yet, and the High Pass filter by Miguel Lopez:

Allows interactively painting in truecolour while viewing matched to palette, with optional pattern-based dithering. Image by Carl Schwan

At the Libre Graphics Meeting, which was attended by Boudewijn, Wolthera and Tiar, several projects presented the history of their project with cool graphs. Well, since Krita officially turned twenty on June 8th (which we completely forgot to celebrate, because of all the release work), we thought it might be interesting to analyze the history of Krita’s codebase a bit as well.

Interestingly, this commit isn’t even in Krita’s git repository anymore: a lot of history was lost over the years. Krita started out as KImageShop in KDE’s CVS repository. Then, after KImageShop had been renamed to Krayon and Krita, the CVS repository was converted to Subversion. Then the subversion repository was converted to git, and the git repository split into a KOffice, a Calligra and a Calligra-History repository.  And then the Krita repository was extracted from the Calligra repository. Still, let’s take a look at what we found out.

We used theseus-of-git to analyze the repository. Here’s the number of lines of code written by the top twenty-five developers.

Another interesting graphic shows how long code survives over the years. Just as in the previous graph, there’s a huge peak of code that quickly disappears, and that’s when KOffice/Calligra was being developed together with Nokia for the Maemo document viewer application. When Krita was separated from Calligra, all that code was no longer necessary.

The type of files in the repository is pretty constant: it’s .cpp and .h files, meaning, that Krita is and always has beem mostly C++. The funniest thing is maybe the enormous number of lines of code in .xmi files. That’s Umbrello‘s file format, and it represents UML diagrams of Krita’s codebase. Those had to be updated manually, and at one point, we just deleted them because they had gotten useless.

June 12, 2019

This month of June I have started a new adventure. I have joined MBition, GmbH, a 100% owned subsidiary of Daimler AG focused on …

“MBition focuses on Infotainment-Software, Navigation-Software, Cloud-Software and UI-Software. ” (extracted from the MBition website).

Automotive is one of those industries that is going through disruptive changes. I think it is a very interesting place to be right now if you are looking for some excitement.mbition_black

Back in 2018, I did a talk at the Autonomous Vehicle Software Symposium, in Stuttgart, Germany, where I said something like this, when referring to software platforms for automotive in the autonomous driving era:

  • What the industry is doing today will not work then.
  • What the industry knows today in this field will not be enough.
  • Learning fast becomes the only suitable strategy to succeed.

Then I asked if OEMs and Tier 1s were learning fast enough. I still believe today that in general no they are not.

Will we at MBition be able to make a positive impact in the way Daimler is learning about how to design, develop, deliver and maintain a software stack that meets the current and future industry requirements, providing at the same time a premium experience to customers, developers and partners?

I will work to answer YES to that question. It will be an outstanding challenge to face during the coming months. I am very excited about it.

Thanks Gregor, Johan and the rest of the MBition crew for giving me this opportunity. A new journey begins.

I will remain in Málaga working remotely for now but visiting Berlin frequently since MBition’s office is located there.

Hello again!

In the last week, I gained progress with the QML rendering library (see the code here)

It is doing what it is supposed to do – it renders an input QML file to output frames of a specified format and renders it as quick as possible (with QQuickRenderControl). If you want to test it out – there is CLI access to it through an executable (which is one of the things I’ve been working in the last week) for the library in the test directory here (make sure you read the READMEs along the way!)

So let’s try to understand what really happens at the core of the library i.e. the rendering part.

To render QML, the obvious approach is to take ‘screenshots’ of each frame using a grab() method which would grab all the pixels at each instant of time and then render it – not only is this darned slow and expensive, it is also not possible to render at a custom frame rate that way.

Here’s where QQuickRenderControl comes into the picture. QQuickRenderControl is used for rendering Qt Quick content (read QML) onto something in a very controlled manner. If you read the official documentation, that ‘something’ is an ‘offscreen render target’ – emphasis on ‘offscreen’ – which means we can tell our dummy window or surface to render our QML onto something else (a QOpenGLFramebufferObject to be specific) and that too, in a very quick process as well!

That was in words, now let’s see some code – I do not want to confuse you (further) but this is essential because at the core of this library is this rendering.

Before we start rendering, we need to setup QQuickRenderControl :

1) Set up the the format of the surface on which we will be doing the rendering on.

QSurfaceFormat format;
format.setDepthBufferSize(16);
format.setStencilBufferSize(8);

2) Set up the OpenGL context

m_context = std::make_unique<QOpenGLContext>();
m_context->setFormat(format);
m_context->create();

3) Set up the surface (dummy)

m_offscreenSurface = std::make_unique<QOffscreenSurface>();
m_offscreenSurface->setFormat(m_context->format());
m_offscreenSurface->create();

4) Set up RenderControl and target window (dummy)

m_renderControl = std::make_unique<QQuickRenderControl>(this);
m_quickWindow = std::make_unique<QQuickWindow>(m_renderControl.get());
m_context->makeCurrent(m_offscreenSurface.get());
m_renderControl->initialize(m_context.get());

5) Create frame buffer object, and tell QuickWindow to render to this object

m_fbo = std::make_unique<QOpenGLFramebufferObject>(m_size * m_dpr, QOpenGLFramebufferObject::CombinedDepthStencil);
m_quickWindow->setRenderTarget(m_fbo.get());

And with that, we can begin rendering but there’s a catch – we cannot render at a custom frame rate yet, as I said before (and that is exactly what the blog that I had earlier mentioned was trying to primarily address). To achieve this, we need to tweak the animation driver – we create our own animation driver and advance frames at our own pace:

void advance() override
{
m_elapsed += m_step;
advanceAnimation();
}

With that, and the next 4 lines (in an event driven loop, of course)

m_renderControl->polishItems();
m_renderControl->sync();
m_renderControl->render();
m_context->functions()->glFlush();

You’re rendering frames! (if you want to see this code in practice, please have a look at root/QmlRenderer/src/)

That’s how it works – in my work so far here, I have made the above mentioned code, almost production ready.

For the next week, I’ve already started writing unit tests to make sure the library works fine at all points in the future. And after that, I’ll start tinkering with MLT and writing a MLT producer.

And here’s a question you might be having by now, why develop this as an independent library? Why not just directly integrate it with MLT?

Because
a) Modularity : Easier to test an independent piece of code and make sure it works.
b) Easy integration : It’s easier to integrate a module with a framework – as there are discussions regarding MLT’s future in Kdenlive.

That’s it for this week, let’s hope for the best!

June 11, 2019

KDE neon 5.16 is out featuring Plasma 5.16. Download the ISO now or upgrade your installs.

With Diversity in mind this edition features an Ice Cold themed wallpaper to make those in the southern hemisphere feel included.

We are pleased to announce that Plasma 5.16, is now available in our backports PPA for Disco 19.04.

The release announcement detailing the new features and improvements in Plasma 5.16 can be found here

Released along with this new version of Plasma is an update to KDE Frameworks 5.58. (5.59 will soon be in testing for Eoan 19.10 and may follow in the next few weeks.)

To upgrade:

Add the following repository to your software sources list:

ppa:kubuntu-ppa/backports

or if it is already added, the updates should become available via your preferred update method.

The PPA can be added manually in the Konsole terminal with the command:

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

and packages then updated with

sudo apt update
sudo apt full-upgrade

IMPORTANT

Please note that more bugfix releases are scheduled by KDE for Plasma 5.16, so while we feel these backports will be beneficial to enthusiastic adopters, users wanting to use a Plasma release with more stabilisation/bugfixes ‘baked in’ may find it advisable to stay with Plasma 5.15 as included in the original 19.04 Disco release.

Issues with Plasma itself can be reported on the KDE bugtracker [1]. In the case of packaging or other issues, please provide feedback on our mailing list [2], IRC [3], and/or file a bug against our PPA packages [4].

1. KDE bugtracker: https://bugs.kde.org
2. Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
3. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net
4. Kubuntu ppa bugs: https://bugs.launchpad.net/kubuntu-ppa

The first two weeks of the GSoC coding period are now over.

Firstly, a mapping between KIO errors and FUSE errors has now been established. Previously all KIO Job errors were simply sent back to FUSE as EIO, which isn’t entirely accurate. The mapping now provides more accurate error replies.

A major new addition is 32-bit support. KIOFuse did not compile on 32-bit but these compilation errors have now been alleviated. They mostly stemmed from the fact that size_t has a different size on different architectures, and that file sizes should always be represented as off_t anyway.

Another big question was whether files larger than 4GiB could be sent without data corruption. A switch from the C standard I/O functions to UNIX I/O functions was necessary to avoid data corruption. However, this alone was not sufficient. On 32-bit files larger than 4GiB I noticed that no write call was occurring, although it occurred on 64-bit and on 32-bit with smaller files. I couldn’t point this down to anything in KIOFuse (seeming as KIOFuse simply responds to requests passed by FUSE, what can we do if we don’t receive the necessary request?). Luckily one of my mentors, fvogt, spotted a kernel bug report, which fortunately was fixed about a month ago. This bug was the cause of the problem I was seeing. This means that transferring of files larger than 4GiB via KIOFuse is now supported on distros running kernels 5.1.5+ only. Because of this, we do not recommend packaging or using KIOFuse on kernels less than the mentioned version, due to likely data corruption when transferring large files. This patch is still not in master and is under active review. It is being looked into whether adding a unit test is feasible.

I’d like to thank my mentors, fvogt and chinmoy for their help and guidance so far and look forward to improving KIOFuse further. Over the next week, signal handling and password change/unmount (if necessary) support are the features that will be worked on.

With the completion of my first milestone for my GSoC project: Nextcloud Integration on Plasma Mobile, plasma mobile accounts settings now enables the users to add their nextcloud accounts via webview.

Well! didn’t accounts setting already provide the method to add nextcloud/owncloud accounts? Yes, this functionality was already implemented by the owncloud plugin in kaccounts-providers project. Then, why did I re-implement the same thing?
As I mentioned, now accounts can be added via webview.

Why using WebView approach for login is better?
This approach is not only more convenient to implement but, it also makes sure that the application never stores the user’s password. The users can be ensured that their credentials can’t be misused.

Work Flow
Clicking on Add new Account button shows all the accounts plugin options declared by .provider.in files in providers folder of kaccounts-providers.


On choosing nextcloud option, Nextcloud Wizard shows up. On clicking the login option, the server address entered by user is checked and then the WebView is initiated.


On the final login the server redirects to a url of the following format:
nc://login/server:<server>&user:<loginname>&password:<password>
From this URL login name and password that the application must use to login and store securely is fetched. The control is passed back to the wizard. The user is given option to choose whether or not (s)he wants to synchronize the contacts from the server. This is further facilitated and managed by kaccounts-mobile. Once the login is complete, the username, the password and the other data stored in json object is passed to kaccounts-integration. It manages storing all the accounts and displaying saved accounts on plasma-settings Accounts.

Say hello to Plasma 5.16, a the newest iteration of KDE's desktop environment, chock-a-block with new features and improvements.

For starters, check out the new notification system! Not only can you mute notifications altogether with the Do Not Disturb mode, but the system also groups notifications by app. Like this, when you run through the history of past notifications, you can see all the messages from KDE Connect in one category, the download information in another, email alerts in a third, and so on.

Discover, Plasma's software manager, is also cleaner and clearer as it now has two distinct areas for downloading and installing software on the Update page. Besides, when updating, the completion bar now works correctly and the packages disappear from the list as the software manager completes their installation.

With each new version, we make Plasma safer, and protect your data better. In 5.16 we have made using Vaults easier and more convenient. Vaults are a built-in utility to encrypt folders, installed by default on Plasma, and you can now open them directly from Dolphin.

Protecting your privacy requires that we focus on the small details, too. When any application accesses the microphone, an icon will pop up in your system tray, showing that something is listening. It doesn't matter whether it is graphical application, a web app or a process started on the command line - the icon will show up alerting you to the fact. You can deactivate your mic by clicking the icon with the middle button on your mouse.

Plasma 5.16 is also spectacular to look at, with our new wallpaper called Ice Cold. Designed by Santiago Cézar, it is the winner of a contest with more than 150 entries. Ice Cold will keep you cool and feeling fresh for the upcoming summer months. Again, giving you options is what Plasma is all about, so we have included a few other contest submissions for you to choose from.

Talking of options, many of the pages in the System Settings have been redesigned, with clearer icons and friendlier layouts. Getting back to wallpapers: the Wallpaper Slideshow settings window displays the images in the folders you selected, and lets you select only the graphics you want to display in the slideshow. To improve visibility, window and menu shadow colors are pure black - something that works especially well when using dark themes.

And if creating themes is your thing, many of the hard-coded look and feel options are gone know, allowing you full freedom to design widgets to your liking. You'll notice it in the small things, like the analog clock handles: Plasma themes now let you tweak their look by adjusting the offset and toggling the blur behind panels.

For a more comprehensive overview of what to expect in Plasma 5.16, check out the official announcement or the changelog for the complete list of changes.

Functional, feature-rich, privacy-protecting and beautiful... What else could you ask for? Look out for Plasma 5.16 in a distribution near you!

June 10, 2019

While browsing the ISO C++ homepage I stumbled over the results PDF of the Second Annual C++ Foundation Developer Survey “Lite”.

I was astonished that Kate made it into the “Which development environments (IDEs) or editors do you use for C++ development?” results.

;=) Seems not only I use it as my normal editor for working on C++ code.

And heads up, KDevelop is there, too!

This is actually the second survey, I missed to notice the first one last year. The results PDF from last year shows Kate did show up already there.

We shouldn’t be that proud of only having less than three percent usage, but still, we are there at all. I hope we can rise here a bit in the future.

At least we work on supporting modern C++ standards in the highlighting, e.g. see the recent C++20 improvements (Phabricator + Commit). Thanks to Jonathan Poelen for the patch!

Language Server Protocol (LSP) would help, too, but my initial work is far from usable, help appreciated. Beside a hacked “goto definition” nothing works at the moment (and it is hardcoded to just start clangd, no other LSP server).

Hi! Last week was start of the GSOC coding period. So I started my project. Also I opened my code on the KDE git. https://cgit.kde.org/scratch/songeon/kmarkdownparser.git/

If you are interested in my project feel free to look and give me some advices.

Parser using Spirit::x3

First, I started to make the markdown parser using the Boost Spirit X3.

Spirit makes easy to express grammar using the PEG. But it’s templet based library so it was hard to find out which part is wrong. Also documentation of spirit was limited.

So I had a lots of trial and error to get compilable source code.

http://becpp.org/blog/wp-content/uploads/2019/02/Ruben-Van-Boxem-Parsing-CSS-in-C-with-Boost-Spirit-X3.pdf

https://ciere.com/cppnow15/using_x3.pdf

this two slides was really helpful for me.

Markdown AST Structure

if we type markdown document like this

# hello
> > 1. - **sadf** - 
> > 
> > sadf
> 
> asdf

we will get result like this.

Markdown document’s can be splited in each lines. line is the smallest unit of the markdown document. Also line can be expressed attributes, string, emphasizes.

  • attributes : Line’s attribute that change the block style. There are two types of attribute.
  • Single Attribute : # header. Style applied only once.
  • Multiple Attributes : > BlockQuote, Lists. Sytle applied recursively.
  • String : Content of the document. It contains only string.
  • Emphasize : Bold, Cancleline, Underline… It contains index of string to be emphasized

All line can be parsed in parallel on multiple threads. Because each line is independent from other lines. After parsing seperatly it can be reassembled after parsing phase.

So we can express this grammar with the Spirit grammar like this

    auto const Line_def= 
        Header[pushFunc] >> String[setContent]
        | (MultipleAttribute)* >> EmphasizeString[getEmphStr];

Piece Table

I had a hard time to implementing the Emphasize String.

All String Emphasize token should be paired. If tokens not paired it should be inserted in original points

    **this is paired example**
    
    **This token -> -- is not paired**

Like this exampled -- should be inserted in middle of the string as the normal character.

We can simply using insert method but it has performance issue.

If there is a original string length N and another string length M to be inserted in position P.

First split the original string at position P and shift the splited string as mush as M.

Then put the string length M in position P. It takes almost O(N).

If there are alot of non-paired tokens, It will consume more time.


So I found the VSCode team’s article about reimplementing text buffer using the Piece Table.

https://code.visualstudio.com/blogs/2018/03/23/text-buffer-reimplementation

The main idea of the Piece Table is seperate the original buffer and added buffer.

And split the strings in a small pieces containing position to insert and the string length.

Make a table about how to make new string using each pieces.

So I applied this structure in appending non-paired emphasize tokens.

    const auto EmphasizeString_def = 
      +(omit[Emphasize[setEmp]] | Content[setEmpText]); 

In my grammar definition, it do not check the pairness of Emphasize token.

Basically Emphasize token are temporary stored in Emphasize Stack to check pairness.

First If there is token can be paired, add token in Emphasize vector and clean the non-paired tokens.

Or there are not tokens can be paired just push the token in the Emphasize Stack and push token’s string value in the buffer vector.


Strings are also added in the buffer vector and inserted in the Piece Map.

Piece Map works same as Piece table but effective on find the piece on some position.

Piece Map is multimap that use Piece’s index and Piece as key value.

So we can iterate whole pieces and make new string with non-paired tokens.

    namespace AST {
      struct Piece {
        int start = 0, len = 0;
        int bufIdx = 0;
      };
    
      struct Emphasize {
        int start = 0, end = 0, bufIdx = 0;
        EmphasizeType empType = EmphasizeType::DEFAULT;
      };
    
      using PieceMap = std::multimap<int, Piece>;
      using PieceMapIter = PieceMap::iterator;
    
      class EmphasizeString {
        private:
          int currPos = 0, addedTokenLen = 0;
          std::vector<std::string> buffer;
          std::vector<Emphasize>  empSt, emps;
          PieceMap pieceMap;
    
        private:
          int clearNonComplete(std::vector<Emphasize>::iterator );
        public:
          EmphasizeString();
          void addEmphToken(EmphasizeType empt);
          void appendText(const std::string& text);
          std::string getString();
          const std::vector<Emphasize> &getEmphasizes() const;
      };
    };

You can check my whole code on KDE git.


After first week

I think it was good starting for me. But this week and next week is my final exam in the school.

So me and my mentors Eike and SungJae planned to refactor the code and make view of markdown.

They also mentioned adding the licensing policy and following the KDE’s codding convention.

Thank you for reading my article and I’ll write next article after my final finish.

As part of GSoC 2019, I am working on KDE ISO Image Writer which is a tool to write ISO images to USB flash drives.

The main goals that I set for this GSoC are:

  • Rework the user interface (following this design).
  • Improve and extend the ISO verification mechanism.
  • Thoroughly test the software to identify bugs.
  • Package the application for Linux, Windows and macOS.

First Attempt at Revamping the UI

When I first looked at the design, I thought I would rewrite the UI in the shape of a wizard using QWizard.

The application would have three main screens that would guide the user through the process of writing an ISO image into a USB flash drive:

  • Select an ISO image
  • Select a USB flash drive
  • Write to USB flash drive

I made the following sketches to illustrate my idea for the user interface:

Select ISO image
Select USB flash drive
Write to USB flash drive

I started implementing this idea using Qt’s QWizard with the idea of having a QWizardPage for each of the above screens:

KDE ISO Image Writer using QWizard

The Way Forward

I had a discussion with my mentor Jonathan Riddell and Nate Graham who is part of the KDE VDG about my plans on the user interface. They provided valuable comments about my approach. It was then clear to me that a wizard is not suitable for this use case and we agreed on the way forward, which is to implement the initial design.

Could you tell us something about yourself?

My name is Asja Flaim and I am 13 years old. I am from Italy. I love to draw and to put my thoughts to paper. Especially when I am sad, drawing helps me feel much better.

How did you find out about Krita?

When I got my PC and my Huion 191 tablet as a Christmas gift, Krita was installed on the PC.

Do you draw on paper too, and which is more fun, paper or computer?

Yes I draw on paper, too. Often it’s much easier to draw on paper, because digital art is still quite complicated for me. Drawing is fun anyways, doesn’t matter where ��

What kinds of pictures do you draw?

I love to draw persons in manga style, but recently I like to draw realistic things, like eyes and faces.

What is easy to do with Krita? What is difficult to do?

It’s easy to find all the brushes and things you need to draw. I find it quite difficult to use my drawing tablet properly, I don’t have the precision like when I am drawing on paper. But this isn’t Krita’s fault.

I even used Krita to make an animation for my Youtube channel. That was quite hard, but I think the result was good and I had much fun.

What is the best thing about Krita?

It is easy to use, everything you need is easy to find and I can adapt my work space like I need it, with all my tools in place.

Is there anything in Krita that you’d like to be different?

That’s a hard question. I only use Krita and I think it is great as it is. All the stuff about animation and how fast the frames are displayed, when you export the animation could be easier to set up. Or maybe I just don’t understand how it works properly.

What is your favourite picture that you made with Krita?

The cupcake �� It is a picture that I make for the birthday of my little sister and I love it.

How did you make it?

Of course with Krita and on my drawing tablet.

Is there somewhere we can see more of your work?

I am a little embarrassed, but yes, on Instagram.

Is there anything else you’d like to tell us?

My dad told me, that other drawing programs cost very much. The possibility to use a program that doesn’t cost anything and that you can use to draw almost anything is incredible.

Thank you for letting me make this interview.

June 09, 2019

In 2017 we discussed what goals the KDE community should focus on in order to get closer to our vision of a world in which everyone has control over their digital life and enjoys freedom and privacy. We went through a process of submitting and discussing proposals and then voting on them. The result were 3 clear goals that KDE focused on over the past 1.5 years: top-notch usability and productivity for basic software, streamlined onboarding of new contributors and privacy. The focus the goals gave us have led to significant progress in all 3 areas. Check out Nate’s and Neofytos’ summary! But not only that. We got fantastic new people on board and our larger community and users understood that we care about and make progress in areas that matter to them. Thank you to everyone who has and continues to put work into these. Your contributions make KDE better every single day.

The goals we had set were ambitious and in some sense they can never be completed. However after 1.5 years the large initiatives behind them are well underway and the ideas behind them have become part of our daily routine. This means it is time to think about the next goals (or decide to double down on any of the current goals) to focus our collective attention on. So today we are starting the next round of KDE community goals.

The timeline:
  • June: Anyone can submit draft proposals
  • Beginning of July to middle of August: We discuss and improve proposals together
  • Second half of August: We vote on the finalized proposals
  • At Akademy in September: We announce the new goals

Do you have an idea for a goal for KDE? Get a small group of people together and propose it today by adding it to this board on Phabricator. Do you need some inspiration? Have a look at last round’s proposals. If you have any questions please send an email to the kde-community mailinglist.

<prelude> In the previous post, I discussed boost::astar_search and ignored the most important part of the whole setup, the graph itself. This I would say is a little harder to comprehend than boost::astar_search.

Week 74 in Usability & Productivity initiative is here!

Now that Plasma 5.16 is frozen and almost out the door, we’ve started turning our attentions to Plasma 5.17. One of the big features I’m pushing on is a visual evolution of the Breeze theme. The first component just landed: KWin-generated window borders are now off by default for the Breeze theme! Don’t worry, this doesn’t mean you have to aim for a single pixel to to resize windows; there are virtual resize areas just the same size as the old window borders so the behavior is unchanged. It also has no effect on other themes, many of which have big, beautiful borders that stand out as part of the theme’s design. But Breeze is a minimalistic theme, and this is the first step towards modernizing the look and feel of KDE apps. We think you’re really going to love the final result!

In the meantime, take a look at all the other cool stuff that got done this week by KDE’s awesome contributors:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

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

If you find KDE software useful, consider making a donation to the KDE e.V. foundation.

The KDE Community welcomes our Google Summer of Code students for 2019!

These students will be working with our development teams throughout the summer, and many of them will join us this September at Akademy, our annual community meeting.

Krita will have four students this year: Alberto Flores will work with the SVG pipe/animated brush, Kuntal M. is porting the magnetic lasso, Sharaf Zaman will port Krita to Android, and Tusooa Windy will bring a better undo/redo for Krita.

digiKam will mentor three students this year. Thanh Trung Dinh will bring AI Face Recognition with the OpenCV DNN module to digiKam, Igor Antropov will improve the Faces Management workflow, and Ahmed Fathy will make a zoomable and resizable brush for Healing Clone Tool.

Labplot gets attention from two students in 2019. While Devanshu Agarwal will provide statistical analysis for Labplot, Ferencz Kovács will work on the support for importing educational data sets available on the Internet.

Another two students - Piyush Aggarwal and Weixuan Xiazo - will work on KDE Connect. Their projects are quite exciting: Piyush will be porting KDE Connect to Windows, while Weixuan brings KDEconnect to MacOS.

Akshay Kumar will bring Gcompris one step closer to version 1.0, and Akhil K Gangadharan will revamp the Titler tool for Kdenlive. Prasenjit Kumar Shaw will make data sync for Falkon a thing, and Rituka Patwal will bring Nextcloud integration to Plasma Mobile.

João Netto will improve JavaScript support on Okular, and Karina Pereira Passos will improve Khipu and Analitza. Nikita Sirgienko will implement the import/export of Jupyter notebooks in Cantor.

Atul Bisht will create a barcode scanning plugin in Purpose. Filip Fila will work on ensuring consistency between the SDDM login manager and the Plasma desktop, and SonGeon will focus on integrating kmarkdown-qtview with WYSIWYG markdown editor for KDE as a whole.

KDE neon will get a KDE ISO image writer courtesy of Farid Boudedja, while Caio Tonetti will make an improved graph theory IDE for Rocs. Alexander Saoutkin will be polishing KIOFuse, and Shubham will port authentication to Polkit-qt for KDE Partition Manager.

We look forward to our students' contributions, and we're excited to share their progress with the rest of the world. As Google Summer of Code moves forward, you'll be able to read detailed reports from our students, and find out how their work will impact your favorite KDE software. Stay tuned, and wish them luck!

June 07, 2019

And you should too!

Akademy is free to attend however you need to register to reserve your space, so head to https://akademy.kde.org/2019/register and press the buttons.

Akademy is very important to meet people, discuss future plans, learn about new stuff and make friends for life!

Note this year the recommended accomodations are a bit on the expensive side, so you may want to hurry and apply for Travel support. The last round is open until July 1st.


I'm going to Akademy 2019

KNotifications ❤ Windows 10


After a couple weeks of discussions, bug reporting, fixing and coding with lots of people from the KDE Community, KNotifications can now be used for applications targeted towards the Windows 10 OS. Yes! KNotifications could well be supporting Windows 10 native notifications within the next couple releases.

Any and all KDE applications using KNotifications need not change their code base to enjoy this new feature! More details follow:-

The SnoreToast Backend

The in-development branch brute4s99/snore-withactions in the KNotifications code base implements a new SnoreToast backend that kicks in when KNotifications is compiled for Windows 10 using the MSVC compiler. The changes done, in a simplified manner, are:-
1. Adding a back-end- SnoreToast
2. Creating a plugin for the new back-end – notifybysnore

This new feature comes with a caveat though 
the SnoreToast back-end needs to install a shortcut
to the application's .exe file in the Windows Start Menu folder
with the Application ID of the application that wishes to use
KNotifications. This is, once again, handled by 
the SnoreToast back-end itself! �� 


The apps just need to install the shortcut with the right parameters and they should be ready to rock!
P.S: We have an example for you to build upon; no need to reinvent the wheel! ��

What the Application Developers Gotta Do

KDE Connect uses Craft as its dev – build system on Windows.

Craft is an open source meta build system and package manager. It manages dependencies and builds libraries and applications from source, on WindowsMacLinux and FreeBSD.

The shortcut installation step is fairly easy, and a straightforward example has been demonstrated by KDE Connect at this diff. Most Important -> Line 35 and 39 .
The diff demonstrates how the Craft blueprint of any application can be modified accordingly to use the SnoreToast back-end.

KNotifications picks up the application ID from here. Use whatever it contains for your own application, and replace org.kde.kdeconnect.daemon with that on Line 39 here.

A small demonstration for the SnoreToast backend with KNotifications:-

Happy KDEing ��

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.