I'm in Madrid since Monday, at the third GNOME+Rust hackfest! The OpenShine folks are kindly letting us use their offices, on the seventh floor of a building by the Cuatro Caminos roundabout.

I am very, very thankful that this time everyone seems to be working on developing gnome-class. It's a difficult project for me, and more brainpower is definitely welcome — all the indirection, type conversion, GObject obscurity, and procedural macro shenanigans definitely take a toll on oneself.

Gnome-class internals

I explained how gnome-class works to the rest of the hackfest attendees. I've been writing a document on gnome-class's internals, so the whiteboard was a whirlwind tour through it.

Error messages from the compiler

Antoni Boucher, the author of relm (a Rust crate to write GTK+ asynchronous widgets with an Elm-like model), explained to me how relm manages to present good error messages from the Rust compiler, when the user's code has mistakes. Right now this is in a very bad state in gnome-class: user errors within the invocation of the procedural macro get shown by the compiler as errors at the macro call, so you don't get line number information that is meaningful.

For a large part of the day we tried to refactor bits of gnome-class to do something similar. It is very slightly better now, but this really requires me to sit down calmly, at home, and to fully understand how relm does it and what changes are needed in the syn parser crate to make it easy to present good errors.

I think I'll continue this work at home, as there is a lot of source code to understand: the combinator parsers in syn, the error handling scheme in relm, and the peculiarities of gnome-class.

Further work during the hackfest

Other people working on gnome-class are adding support for GObject properties, inheritance from non-Rust classes, and improving the ergonomics of class-private structures.

I think I'll stop working on error messages for now, and focus instead on either supporting GTypeInterfaces, or completing support for type conversions for methods and signals.

Other happenings in Rust

Paolo Borelli has been porting RsvgState to Rust in librsvg. This is the big structure that holds all the CSS state for SVG elements. This is very meticulous work, and I'm thankful that Paolo is paying good attention to it. Soon we will have all the style machinery for librsvg in Rust, which will make it easier to use the selectors crate from Servo instead of libcroco, as the latter is unmaintained.

Food

Ah, Spanish food. We have been enjoying cheese, jamón, tortilla, pimientos, oxtail stews, natillas, café con leche...

Thanks

Thanks to OpenShine for hosting the hackfest, and to the GNOME Foundation for sponsoring my travel. And thanks for Alberto Ruiz for putting me up in his house!

Initially, I wanted to blog about my travels. In the end, I refactored old code on my computer to publish eventually my first Ruby gem in the official repo at RubyGems. Welcome now jekyll-onebox on Github and RubyGems! :tada: :clap:

So if you use Jekyll for blogging, you can install this plugin and add HTML previews for links to popular websites very easily.

{% onebox https://github.com/rriemann/jekyll-onebox/blob/master/README.md %}

The previews are rendered using the gem onebox that powers link previews for Discourse forums.

Have fun with it and let me know if you encounter problems!

I am happy to announce the release of the stable Kraft version 0.80 (Changelog).

Kraft is desktop software to manage documents like quotes and invoices in the small business. It focuses on ease of use through an intuitive GUI, a well choosen feature set and ensures privacy by keeping data local.

After more than a dozen years of life time, Kraft is now reaching a new level: It is now completely ported to Qt5 / KDE Frameworks 5 and with that, it is compatible with all modern Linux distributions again.

KDE Frameworks 5 and Qt5 are the best base for modern desktop software and Kraft integrates seamlessly into all Linux desktops. Kraft makes use of the great KDE PIM infrastructure with KAddressbook and Akonadi.

In addition to the port that lasted unexpectedly over 12 months, Kraft v. 0.80 got a whole bunch of improvements, just to name some examples:

More Flexible Addressbook Integration

As Akonadi is optional now, Kraft can be built without it. Even if it was built with, but Akonadi for whatever reason is not working properly, Kraft still runs smoothly. In that case it only lacks the convenience of address book integration.

The Address book access was also nicely abstracted so that other Addressbook backends can be implemented more easily.

GUI Improvements

Even though the functionality and GUI of Kraft was not changed dramatically compared to the last stable KDE 4 version, there were a few interesting changes in the user interface.

• A new, bigger side bar simplifies navigation.
• In the timeline view, a click on years and month in the treeview show summaries of the selected time span, ie. the number of documents with financial summaries per month or year.
• A filter allows to limit the view on the current week or month.

Reduction of dependencies

Kraft makes broad use of the core Qt5 libraries. The required KDE dependencies were reduced to a bare minimum. Akonadi libraries, which enable KDE PIM integration are now optional. The former dependency on heavyweight web browser components were completely removed and replaced by the far more simple richtext component of Qt.

These changes make it not only easier and more transparent to build Kraft but allow make a port to other platforms like MacOSX more easy in the future.

Under the Hood

A countless number of bugfixes and small improvements went in. Also updates to the newer C++ concepts where applicable make the rather mature code base more modern and better maintainable.

The Reportlab based PDF document creation script was updated and merged with a later version for example.

Deployment

Installing Kraft is still a bit complicated for unexperienced users, and distributions sometimes haven’t made a good job in the past to provide the latest version of Kraft.

To make it easier to test, there is an AppImage of Kraft 0.80 available that should be runable on most modern distributions. Just download a single file that can be started right away after having added the executable permissions.

Linux packages are already built for openSUSE (various versions) or Gentoo.

Kraft’s website will contain a lot more information.

Heute wurde Kraft Version 0.80 herausgegeben.

Nach mehr als zwölf Jahren Lebenszeit beginnt für Kraft heute eine neue Ära: Kraft ist jetzt auf Qt5/KDE Frameworks 5 portiert und damit wieder problemlos auf modernen Linux Distributionen lauffähig.

KDE Frameworks 5 und Qt5 sind die beste Basis für einen modernen Desktop, aber Kraft integriert gut mit allen verfügbaren Linux Desktop Systemen. Mit KDE kann Kraft das Akonadi-basierte Adressbuch zur Adressverwaltung nutzen.

Zusätzlich zur Portierung, der mehr als die letzten 12 Monate in Anspruch nahm, beinhaltet Kraft V. 0.80 eine große Menge an Verbesserungen, zum Beispiel:

Weniger Abhänigkeiten

Kraft verwendet vor allem die Qt5 Bibliotheken. Die verwendeten KDE Frameworks Abhängigkeiten wurden bewusst auf das nötige Minimum reduziert. Die Akonadi-Bibliotheken, die die KDE-Adressbuch-Integration ermöglichen, sind jetzt optional. Die vorherige Verwendung von einer schweren Webbrowser-Komponente wurde komplett entfernt und von einer viel simpleren, in Qt integrierten Richtext-Komponente ersetzt.

Alle diese Änderungen machen es nicht nur einfacher, Kraft zu übersetzen, sondern vereinfachen einen möglichen Port auf andere Platformen wie MacOSX oder Windows.

Adressbuch-Integration

Da Akonadi nun optional ist, kann Kraft ohne es übersetzt werden. Selbst wenn es mit gebaut wurde, aber Akonadi aus irgendwelchen Gründen nicht funktioniert, läuft Kraft ohne Probleme weiter. Es fehlt dann lediglich der Komfort der Adressbuch-Integration und Adressen müssen manuell eingetragen werden.

Die Empfehlung ist weiterhin, die gute Integration mit dem Akonadi-basierten Adressbuch zu verwenden.

Benutzeroberfläche verbessert

Auch wenn die Funktionalität von Kraft in diesem Release im Vergleich zum letzten KDE4-basierten Release nicht wesentlich verbessert wurde, sind doch einige interessante Veränderungen passiert.

• Eine neue, größere und vereinfachte Seitenleiste erleichtern die Bedienung
• Im Zeitverlauf kann jetzt auf ein Jahr oder einen Monat geklickt werden und es wird eine Übersicht der versendeten Dokumente in dem Zeitraum angezeigt.
• Ein Filter erlaubt die Reduzierung der angezeigten Dokumente auf die aktuelle Woche oder den letzten Monat.

Unter der Haube

Zusätzlich wurden eine große Menge weiterer Fehlerbehebungen und Verbesserungen eingebracht. Ausserdem erleichtert der Umstieg auf modernere C++ Standards die Weiterentwicklung und Pflege der Software.

Installation

Kraft zu installieren ist nicht einfach, und Linux-Distributionen haben in der Vergangenheit nicht immer einen guten Job gemacht, die aktuelle Version von Kraft zu liefern.

Um es einfacher zu machen, Kraft auszuprobieren, wird ab jetzt ein sog. AppImage von Kraft angeboten, das auf den meisten modernen Linuxen lauffähig sein sollte. Dazu muss nur ein einziges File heruntergeladen werden.

I have started porting the code in librsvg that parses SVG's CSS properties from C to Rust. Many properties have symbolic values:

stroke-linejoin: miter | round | bevel | inherit

stroke-linecap: butt | round | square | inherit

fill-rule: nonzero | evenodd | inherit

StrokeLinejoin is the first property that I ported. First I had to write a little bunch of machinery to allow CSS properties to be kept in Rust-space instead of the main C structure that holds them (upcoming blog post about that). But for now, I just want to show how this boiled down to a macro after refactoring.

First cut at the code

The stroke-linejoin property can have the values miter, round, bevel, or inherit. Here is an enum definition for those values, and the conventional machinery which librsvg uses to parse property values:

#[derive(Debug, Copy, Clone)]
pub enum StrokeLinejoin {
    Miter,
    Round,
    Bevel,
    Inherit,
}

impl Parse for StrokeLinejoin {
    type Data = ();
    type Err = AttributeError;

    fn parse(s: &str, _: Self::Data) -> Result<StrokeLinejoin, AttributeError> {
        match s.trim() {
            "miter" => Ok(StrokeLinejoin::Miter),
            "round" => Ok(StrokeLinejoin::Round),
            "bevel" => Ok(StrokeLinejoin::Bevel),
            "inherit" => Ok(StrokeLinejoin::Inherit),
            _ => Err(AttributeError::from(ParseError::new("invalid value"))),
        }
    }
}

We match the allowed string values and map them to enum values. No big deal, right?

Properties also have a default value. For example, the SVG spec says that if a shape doesn't have a stroke-linejoin property specified, it will use miter by default. Let's implement that:

impl Default for StrokeLinejoin {
    fn default() -> StrokeLinejoin {
        StrokeLinejoin::Miter
    }
}

So far, we have three things:

• An enum definition for the property's possible values.
• impl Parse so we can parse the property from a string.
• impl Default so the property knows its default value.

Where things got repetitive

The next property I ported was stroke-linecap, which can take the following values:

#[derive(Debug, Copy, Clone)]
pub enum StrokeLinecap {
    Butt,
    Round,
    Square,
    Inherit,
}

This is similar in shape to the StrokeLinejoin enum above; it's just different names.

The parsing has exactly the same shape, and just different values:

impl Parse for StrokeLinecap {
    type Data = ();
    type Err = AttributeError;

    fn parse(s: &str, _: Self::Data) -> Result<StrokeLinecap, AttributeError> {
        match s.trim() {
            "butt" => Ok(StrokeLinecap::Butt),
            "round" => Ok(StrokeLinecap::Round),
            "square" => Ok(StrokeLinecap::Square),
            "inherit" => Ok(StrokeLinecap::Inherit),

            _ => Err(AttributeError::from(ParseError::new("invalid value"))),
        }
    }
}

Same thing with the default:

impl Default for StrokeLinecap {
    fn default() -> StrokeLinecap {
        StrokeLinecap::Butt
    }
}

Yes, the SVG spec has

default: butt

somewhere in it, much to the delight of the 12-year old in me.

Refactoring to a macro

Here I wanted to define a make_ident_property!() macro that would get invoked like this:

make_ident_property!(
    StrokeLinejoin,
    default: Miter,

    "miter" => Miter,
    "round" => Round,
    "bevel" => Bevel,
    "inherit" => Inherit,
);

It's called make_ident_property because it makes a property definition from simple string identifiers. It has the name of the property (StrokeLinejoin), a default value, and a few repeating elements, one for each possible value.

In Rust-speak, the macro's basic pattern is like this:

macro_rules! make_ident_property {
    ($name: ident,
     default: $default: ident,
     $($str_prop: expr => $variant: ident,)+
    ) => {
        ... macro body will go here ...
    };
}

Let's dissect that pattern:

macro_rules! make_ident_property {
    ($name: ident,
//   ^^^^^^^^^^^^ will match an identifier and put it in $name

     default: $default: ident,
//            ^^^^^^^^^^^^^^^ will match an identifier and put it in $default
//   ^^^^^^^^ arbitrary text

     $($str_prop: expr => $variant: ident,)+
                       ^^ arbitrary text
//   ^^ start of repetition               ^^ end of repetition, repeats one or more times

    ) => {
        ...
    };
}

For example, saying "$foo: ident" in a macro's pattern means that the compiler will expect an identifier, and bind it to $foo within the macro's definition.

Similarly, an expr means that the compiler will look for an expression — in this case, we want one of the string values.

In a macro pattern, anything that is not a binding is just arbitrary text which must appear in the macro's invocation. This is how we can create a little syntax of our own within the macro: the "default:" part, and the "=>" inside each string/symbol pair.

Finally, macro patterns allow repetition. Anything within $(...) indicates repetition. Here, $(...)+ indicates that the compiler must match one or more of the repeating elements.

I pasted the duplicated code, and substituted the actual symbol names for the macro's bindings:

macro_rules! make_ident_property {
    ($name: ident,
     default: $default: ident,
     $($str_prop: expr => $variant: ident,)+
    ) => {
        #[derive(Debug, Copy, Clone)]
        pub enum $name {
            $($variant),+
//          ^^^^^^^^^^^^^ this is how we invoke a repeated element

        }

        impl Default for $name {
            fn default() -> $name {
                $name::$default
//              ^^^^^^^^^^^^^^^ construct an enum::variant

            }
        }

        impl Parse for $name {
            type Data = ();
            type Err = AttributeError;

            fn parse(s: &str, _: Self::Data) -> Result<$name, AttributeError> {
                match s.trim() {
                    $($str_prop => Ok($name::$variant),)+
//                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expand repeated elements

                    _ => Err(AttributeError::from(ParseError::new("invalid value"))),
                }
            }
        }
    };
}

Getting rid of duplicated code

Now we have a macro that we can call to define new properties. Librsvg now has this, which is much more readable than all the code written by hand:

make_ident_property!(
    StrokeLinejoin,
    default: Miter,

    "miter" => Miter,
    "round" => Round,
    "bevel" => Bevel,
    "inherit" => Inherit,
);

make_ident_property!(
    StrokeLinecap,
    default: Butt,   // :)

    "butt" => Butt,
    "round" => Round,
    "square" => Square,
    "inherit" => Inherit,
);

make_ident_property!(
    FillRule,
    default: NonZero,

    "nonzero" => NonZero,
    "evenodd" => EvenOdd,
    "inherit" => Inherit,
);

Etcetera. It's now easy to port similar symbol-based properties from C to Rust.

Eventually I'll need to refactor all the crap that deals with inheritable properties, but that's for another time.

Conclusion and references

Rust macros are very powerful to refactor repetitive code like this.

The Rust book has an introductory appendix to macros, and The Little Book of Rust Macros is a fantastic resource that really dives into what you can do.

Following my last blog about Krafts upcoming release 0.80 I got a lot of positive reactions.

There was one reaction however, that puzzles me a bit and I want to share my thoughts here. It is about a comment about my announcement that I prefer to continue to develop Kraft on Github. The commenter reminded my friendly that there is still Kraft code on KDE infrastructure, and that switching to a different repository might waste peoples time when they work with the KDE repo.

That is a fair statement, of course I don’t want to waste peoples time. What sounds a bit strange to me is the second paragraph, that says that if I decide to stay with Github, I should let KDE people know that I wish Kraft to not be a KDE project anymore.

But … I never felt that Kraft should not be a KDE project any more.

A little History

Kraft has come a long way together with KDE. I started Kraft in (probably) 2004, gave a talk about Kraft at the Akademy Dublin 2006, maintained it with the best effort I could contribute until today. There is a small but loyal community around Kraft.

During all the time I got little substancial contribution to the code directly, with the exception of one cool developer who got interested for some time and made some very interesting contributions.

When I asked a for the subdomain http://kraft.kde.org long time ago I got the reply that it is not in the interest of KDE to give every little project a subdomain. As a result I reserved http://volle-kraft-voraus.de and run it since then, happily showing a “Part of the KDE family” logo on it.

Beside the indirect contributions to libraries that Kraft uses, I shipped Kraft with the translations made by the KDE i18n team, for which I always was very grateful. Otherwise I got no other services from KDE.

Why Github?

Githubs workflow serves me well in my day job, and since I have only little time for Kraft, I like to use the tools that I know best and give me the most efficiency.

I know that Github is not free software and I am sceptical about that. But Github also does not lock in, as we still are on git. We all know the arguments that usually come on the table at this point, so I am not elaborating here. One thing I want to mention though is that since I moved to Github publically I already got two little pull requests with code contributions. That is a lot compared to what came in the last twelfe years when living on KDE infrastructure only.

Summary

Kraft is a small project, driven by me alone. My development turnaround is good with Github as I am used to it. Even if no KDE developer would ever look at Github (which I know is not true) I have to say with heavy heart that Kraft would not take big harm by leaving KDEs infra, based on the experience of the last 12 years.

If the KDE translation teams do not want to work with Github, I am fine to accept that, and wonder if there could be a solution rather than switching to Transifex.

One point however I like to make very clear: I did not wish to leave KDE, nor aimed to move Kraft out. I still have friends in the KDE community, I am still very interested in free software on desktop and elsewhere, and my opinion is still that KDE is the best around.

If the KDE community feels that Kraft must not be a KDE project any longer because it is on Github, ok. I asked KDE Sysadmins to remove Kraft from the KDE git, and it is already done.

Kraft now lifes on on Github.

Gitlab has a fairly conventional Continuous Integration system: you push some commits, the CI pipelines build the code and presumably run the test suite, and later you can know if this succeeded of failed.

But by the time something fails, the broken code is already in the public repository.

The Rust community uses Bors, a bot that prevents this from happening:

• You push some commits and submit a merge request.

• A human looks at your merge request; they may tell you to make changes, or they may tell Bors that your request is approved for merging.

• Bors looks for approved merge requests. It merges each into a temporary branch and waits for the CI pipeline to run there. If CI passes, Bors automatically merges to master. If CI fails, Bors annotates the merge request with the failure, and the main repository stays working.

Bors also tells you if the mainline has moved forward and there's a merge conflict. In that case you need to do a rebase yourself; the repository stays working in the meantime.

This leads to a very fair, very transparent process for contributors and for maintainers. For all the details, watch Emily Dunham's presentation on Rust's community automation (transcript).

For a description of where Bors came from, read Graydon Hoare's blog.

Bors evolved into Homu and it is what Rust and Servo use currently. However, Homu depends on Github.

I just found out that there is a port of Homu for Gitlab. Would anyone care to set it up?

Update: Two people have suggested porting Bors-ng to Gitlab instead, for scalability reasons.

Hi! I am running as openSUSE Board member and I would like to let you know more about me, my view of what openSUSE is and why I want to be in the Board. :raised_hands:

About myself

I’m Ana María Martínez, 24 years old, from Madrid, Spain and living in Nuremberg, Germany. I studied Computer Science Engineering and Mathematics in Madrid. During my last year at university, I started in open source development contributing to a local open government project. At the end of my university studies (2016), I participated in Google Summer of Code (GSoC) as a student for openSUSE. I fell in love with the open source development and the openSUSE community. Because of that, after GSoC, I moved to Nuremberg to work as a Software Engineer at SUSE in the Open Build Service frontend team.

I’m currently writing a lot of Ruby code. As I can not avoid taking a look to every code that crosses my path, apart from my work at SUSE, I contribute to several open source projects inside and outside openSUSE. In some cases becoming active contributor, or even maintainer, for some of them. Some people say I am addicted to GitHub! :wink: In openSUSE, I maintain projects like Open Build Service (build.opensuse.org), OSEM (events.opensuse.org), Trollolo, mentoring (101.opensuse.org) and software-o-o (software.opensuse.org). Outside openSUSE, I have recently contributed to Jekyll, the Ruby core, Rubocop, Rantly, etc.

What I like the most of openSUSE and working in open source is that it is fun, I learn a lot and I have the chance to work with a lot of talented people interested in the same things as me all around the world. I think it is really important that everybody who is interested can join openSUSE development and community. Because of that I help newcomers to open source, for example by participating as a mentor and organization admin in GSoC for openSUSE.

I have also happily spoken at openSUSE events (openSUSE conference, openSUSE.Asia Summit) about topics like mentoring and Open Build Service and I try to contribute to make those events as fun as possible.

You will find me in Github, IRC and some other places as @Ana06. You can contact me in Twitter as well (@anamma_06).

Goals and values

I have heard from previous Board members that the board needs to become more approachable and improve communication. I also think this is important and that there is still room for improvement in this regard. In addition, I find really important that the board works as transparent as possible, so that every openSUSE member is aware of the things that are done and the decisions that are made and how they are made. In openSUSE we like to say that those who does, decide. And I also think that those who does, should be as informed as possible. I consider really important as well that openSUSE contributors are valued and have fun, and we should promote this fun spirit from the board. Last but not least, I think we have to improve as a community on encouraging new people to join us, keeping always fun and advertising openSUSE as much and spread as possible.

Why should you vote for me?

I think it is important that there are openSUSE developers in the board and openSUSE developer is a term that defines myself quite well. :joy: Most of the candidates to the board will probably mention here that they are using openSUSE since more than a decade. This is not something I can say. I am using openSUSE distribution and contributing to openSUSE since less than 2 years. Without forgetting that there are people in openSUSE that know much more than me, that I need to hear and learn from, I think that my point of view can be really valuable for the board. I bring new ideas and energy and a great desire to learn and improve things. And of course the reason why you should vote me is because you share my ideas and concept of what openSUSE is and the things that need to be improved.