Category Archives: Developers

Who is Hiring?

Just as quick info: For some time, there is a sticky thread on r/cpp about who is hiring C++ developers. This thread gets cleaned quarterly, so all the open jobs listed there are likely still open. The same was just started on reddit for r/Qt5: Who’s Hiring Qt Devs – Q4 2018: So if you are looking for either C++ or Qt jobs, this is a good place to have a look at from time to time. When I just looked for r/Qt5, the list was still empty, but this hopefully changes soon, given that the post was added just some hours ago. 🙂

Kate projects and out-of-source builds

During Akademy I once more was a bit disappointed how bad the project plugin of Kate can cope with out-of-source builds.

At work, we use in-source-builds, as we normally only build in one configuration and have no issues with left-overs in the source directories locally. For this use-case, the project plugin works really well. You have your project local terminal view and that allows you all normal things you need during work, e.g. building + using the git command line client for the version control work.

On the other side, with out-of-source builds, that no longer is that nice to use. Either you use the .kateproject generated by the “Kate – Ninja” or “Kate – Unix Makefiles” CMake generators, then your terminal defaults to the build directory, which allows building just fine, but no version control stuff, or you use the .kateproject (or auto-project creation) in the source directory, which doesn’t allow you to build nicely inside the terminal prompt of Kate. There are workaround for that, like having shell magic to switch between source and build directory with ease, but that all feels a bit unnatural.

Therefore, I added today a very simple “fix” for the issue: If you have a .kateproject that has a different base directory (the toplevel “directory” entry) than the directory the .kateproject file is located in, you will get two terminal tabs in the project view. One is the “old one” that has the directory of the .kateproject as base, the other has the base directory of the project as base.

With these two views, you can easily switch between build/source directory without any hassle or extra setup for any properly setup .kateproject as generated by CMake.

I hope this improves the usability of the project plugin for the normal setup of out-of-source builds with CMake. If this sparked your interest: any further improvement ideas are welcome, best as patches submitted on phabricator.kde.org.

I think this small change is something that shows how many open source contributions work: You have some itch to scratch and you share your solution to help others that have a similar issue.

If you look at the open bugs & wishes for Kate/KWrite/KTexteditor/… you will see that there are still a lot things that need some scratching. It might look like the developers don’t care for the issues of their users, but that is not correct. We just don’t have the time to scratch all these itches (nor are all that easy solvable). Sometimes we unfortunately did even lack time or motivation to do proper reviews for some proposed solutions, I hope we improve on that in the future. Any volunteers that help us taking care are always welcome. The addition of the inline notes interface is a nice example. Michal Srb provided an initial solution for his own needs to us and sparked some new development with that.

Kate gains Support for Inline Notes

Thanks to Michal Srb and Sven Brauch for pioneering the work an a new KTextEditor interface that allows applications like Kate, KDevelop, etc. to display inline notes in a text document. As demo, we quickly prototyped one application to display colors in CSS documents:

Clicking on the color rectangle will launch the color chooser:

Choosing a color and clicking OK finally adapts the color in the CSS document:

The code for this is just a demo and looks as follows:

class NoteProvider : public KTextEditor::InlineNoteProvider {
public:
    QVector<int> inlineNotes(int line) const override
    {
        if (line == 1) return { 29 };
        if (line == 11) return { 29 };
        if (line == 12) return { 29 };
        if (line == 13) return { 29 };

        return {};
    }

    QSize inlineNoteSize(const KTextEditor::InlineNote& note) const override
    {
        return QSize(note.lineHeight(), note.lineHeight());
    }

    void paintInlineNote(const KTextEditor::InlineNote& note, QPainter& painter) const override
    {
        const auto line = note.position().line();
        const auto color = QColor(note.view()->document()->text({line, 22, line, 29}));
        painter.setPen(color);
        painter.setBrush(color.lighter(150));
        painter.drawRoundedRect(1, 1, note.width() - 2, note.lineHeight() - 2, 2, 2);
    }

    void inlineNoteActivated(const KTextEditor::InlineNote& note, Qt::MouseButtons buttons, const QPoint& globalPos) override
    {
        const int line = note.position().line();
        const auto oldColor = QColor(note.view()->document()->text({line, 22, line, 29}));
        const auto newColor = QColorDialog::getColor(oldColor);
        note.view()->document()->replaceText({line, 22, line, 29}, newColor.name(QColor::HexRgb));
    }

    void inlineNoteFocusInEvent(const KTextEditor::InlineNote& note, const QPoint& globalPos) override
    {} // unused in this example

    void inlineNoteFocusOutEvent(const KTextEditor::InlineNote& note) override
    {} // unused in this example

    void inlineNoteMouseMoveEvent(const KTextEditor::InlineNote& note, const QPoint& globalPos) override
    {} // unused in this example
};

// later in code:
auto provider = new NoteProvider();
view->registerInlineNoteProvider(provider);
// final cleanup
view->unregisterInlineNoteProvider(provider);

As you can see, it’s actually not much code at all: We have to derive a class from KTextEditor::InlineNoteProvider, and then register an instance of our Note Provider in the KTextEditor::View. In a next step, we implement the inlineNotes(), inlineNoteSize(), and the paintInlineNote() functions to get basic visual drawing at the desired location. The above code is just a tech-demo, since it uses hard-coded lines and color positions. Additionally, one can also track mouse events (unused in the example above). On mouse click, we open the QColorDialog to let the user choose a new color.

To give more examples of what’s possible, the initial Phabricator review requests contained many other interesting examples (the examples were really implemented). From review request D12662:

Kate showing additional information for loops and structs.

Or a KDevelop addition that adds a lot of meta information on the current code if desired:

KDevelop showing detailed code meta information

We believe this addition to the KTextEditor component has a lot of potential for nice features and plugins. Feel free to use this interfaces starting with KDE Frameworks 5.50. Happy coding! 🙂

A big thanks also goes to this year’s Akademy organizers. Thanks to this event, we could meet up in person and also finalize the InlineNoteInterface, InlineNoteProvider, and InlineNote class to make it ready for public release. This again shows the importance of the yearly KDE conferences since it enables us to significantly push things forward.

Akademy 2018 Wrap-Up

The Akademy 2018 ends today.

Like each Akademy I attended, it was an interesting experience. As the location switches around each year, so does the set of people attending change every year, too.

That is actually nice, as you get always to meet some of your old “friends” but additionally new members of the KDE community. I think this kind of “conferences” or “meetings” are an important way to get some more cohesion in the community, which is sometimes a bit lacking between people only meeting online via mail/…

Beside the presentation tracks and the e.V. meeting, several of the BoFs did spark my interest.

In the KDevelop BoF, Sven talked about what could be done to give the current KDevelop project a bit more focus on the parts it does well to polish them more for a better user experience. The idea is that if you get KDevelop shining even more in the areas it is good at and perhaps cut off some parts that are really given bad impressions, one might attract more people to both use it and contribute. It is still to be discussed if this idea is shared with the other KDevelop contributors.

In the kdesrc-build BoF Michael talked about the current state and collected pain points from the audience and potential future extensions. For example an API to allow to build a light-weight GUI tooling around kdesrc-build to ease the entry to the KDE development was one topic of interest.

Between the conference/BoF/socializing parts of Akademy, I got plenty of time to finally work again on some KTextEditor/Kate related tasks.

With help of Dominik and Volker I got to integrate the KSyntaxHighlighting framework and we even got at least some initial contact with the QtCreator team about the topic of integrating this framework to replace their own implementation of the Kate syntax definition handling. If you experience any issues with the highlighting or folding in the master branch, please file a bug or even better provide some patch on phabricator.

In addition some small KTextEditor and Kate bugs got either solved or at least started to be worked on again. Help with any bug fixing is always welcome!

As small but perhaps for users important step was to actually link to the new and shiny Windows installers that the Binary Factory for KDE produces. Thanks to the team behind that, once more. Hopefully that will lead to more users and developers for Kate on Windows.

Thanks to the organizers to make this Akademy happen and all people that volunteered! Great job! The sponsors are highly appreciated for their contributions, too.

So, thanks for all the fish (or Krapfen), lets see how Akademy next year will be :=)