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!

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.

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.

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

• When using multiple screens, it’s now possible to configure whether the settings for a particular screen apply to that screen in every arrangement that includes that screen, or only in the current screen arrangement (Roman Gilg, KDE Plasma 5.17.0)

Bugfixes & Performance Improvements

• The Baloo file indexing service now notices when extended attributes on folders change, no longer does unnecessary work when an indexed folder is renamed, is faster to index un-indexed files, is even lighter when run on a laptop on battery power, and terminates its indexer processes when stopped or disabled, and (Stefan Brüns, KDE Frameworks 5.60)
• The screen locker now works harder to lock the screen on X11 when something has grabbed keyboard focus (e.g. when a context menu is open) (David Edmundson, KDE Plasma 5.17.0)
• Settings for font rendering are now saved and retrieved properly in all circumstances (Bhushan Shah, KDE Plasma 5.16.1)
• There is no longer a one-pixel pap between the panel and application windows when using certain 3rd-party Plasma themes with Qt 5.13 (Friedrich Kossebau, KDE Plasma 5.16.1)

User Interface Improvements

• The session and keyboard chooser menus on the SDDM login screen are now visually consistent with everything else (Carson Black, Plasma 5.16.1):
  
• Discover no longer shows huge unnecessary horizontal padding for screenshots on Plasma and apps addons (Aleix Pol Gonzalez, KDE Plasma 5.16.1)
• The System Settings Night Color page received now has a better layout (Filip Fila, KDE Plasma 5.17.0):
  
• Konsole’s settings window has been modernized and given a user interface overhaul (Mariusz Glebocki, Konsole 19.08.0):
  
• Text in Dolphin’s information panel is now mouse-selectable and copyable (Gabriel Felipe Huwe, Dolphin 19.08.0)
• Improved High DPI support in Yakuake (Matthieu Gras, Yakuake 3.0.6)

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.

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

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.

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.

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.

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.

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!

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.

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.

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.

• 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

• The Open/Save dialogs’ toolbar now has buttons to switch between Dolphin-style view modes – icons, Compact, and Details (Méven Car, KDE Frameworks 5.60):
  

Bugfixes & Performance Improvements

• The Trashcan and Icon widgets now have shadows behind their text labels that match other shadows for files and folders on the desktop (Filip Fila, KDE Plasma 5.12.9)
• More notifications bugfixes: the circled number in the system tray is now more centered (though not perfectly centered; still working on that), and notifications with images now have better spacing between the text and the image (Kai Uwe Broulik, KDE Plasma 5.16.0)
• Artwork in the Media Player widget no longer overflows from its bounds under certain circumstances (Kai Uwe Broulik, KDE Plasma 5.16.0)
• The DrKonqi bug reporting wizard no longer always has the “report Bug” button disabled in certain circumstances (Daniel Vrátil, KDE Plasma 5.16.0)
• The SDDM login screen theme now looks good by default on up to 5K displays, while simultaneously using a little less memory for everyone else (Filip Fila, KDE Plasma 5.16.0)
• When switching color schemes, all KDE apps’ user interface controls now change their colors without having to quit and re-open them (Sebastian Kügler, KDE Plasma 5.16.1)
• The Network widget’s System Tray popup can now be closed using the Escape key after having opened the Search bar at least once (Kishore Gopalakrishnan, KDE Plasma 5.16.1)
• Maximized windows on one screen of a multi-screen setup are no longer resizable by their edges that touch any other screen (Hugo Pereira Da Costa, KDE Plasma 5.17.0
• Plugging in an external keyboard no longer resets the list of keyboard layouts when the ~/.config/kxkbrc file is missing (Oleg Solovyov, KDE Plasma 5.17.0
• The Baloo file indexing service now consumes fewer resources on laptops using battery power, no longer crashes when it encounters a file that was deleted between file scanning and indexing, and indexes files more quickly by not unnecessarily looking up files mimetypes until needed and avoiding expensive regular expression matching when there’s an exact text match and matching against a single combined regular expression rather than a ton of individual ones (Stefan Brüns, KDE Frameworks 5.60)
• Gwenview now correctly displays thumbnails created with Sony cameras (Tom Moebert, Gwenview 19.08.0)
• Spectacle now displays the correct filename and location in the save dialog the first time you use it to save an image (David Redondo, Spectacle 19.08.0)

User Interface Improvements

• The “Show Desktop” and “Minimize all” widgets now use a monochrome icon in the panel, matching all other default icons (Noah Davis, KDE Plasma 5.16.0):
  
• The Calculator widget’s button text now gets bigger and smaller according to the widget’s size (me: Nate Graham, KDE Plasma 5.16.0):
  
• The Task Manager’s middle-click behaviors now match those of the Windows 10 version: middle-clicking on an open app’s Task opens a new instance, while middle-clicking on its thumbnail will close that instance (me: Nate Graham, KDE Plasma 5.17.0)
• The System Settings SDDM login screen page’s Advanced tab has been redesigned for greater usability and conformance with the common style (Filip Fila, KDE Plasma 5.17.0):
  
• The Help > Donate menu item now shows local currency icons (Noah Davis, KDE Frameworks 5.60)
• The file open/save dialog now saves any visual changes you made to the current view mode when you switch to another view mode (Méven Car, KDE Frameworks 5.60)
• Okular’s toolbar selection mode button now displays the Text Selection tool by default, opens its pop-up when you click on its arrow, and uses consistent naming for all items (me: Nate Graham, Okular 1.8.0):
  
• Okular’s Text Selection tool now uses the same icon in all places where it appears (Noah Davis, KDE Frameworks 5.60 and Okular 1.8.0)
• Okular’s Browse tool now displays the correct “grabby hand” icon (Noah Davis, Okular 1.8.0):
  
• The Samba share creation window now has a button to display the Samba share monitor (me: Nate Graham, KDE Applications 19.08.0)

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

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

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.

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 Windows, Mac, Linux 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