Nacho's Blog

Wing is a library which provides GLib-like API to some Windows API.

The goal of this library is twofold:

• provide GLib-friendly integration points with Windows specific concepts
• be a testing ground for API that may be included in GLib/GIO/Gtk+ once they are proven to be generally useful

Currently it already provides api for:

• Named pipes
• Windows services
• A GSource to poll from windows handles
• Utilities to get the type of operating system and the version.

You can find the git repository in: https://git.gnome.org/browse/wing

As usual if you are interested in this library, patches are very welcomed.

As you may know gtk-win32 is our build system that makes it easy to build all the GTK+ stack with Visual Studio. This blog will try to sum up some of the changes and updates that happened during the last few months:

• gettext has been updated to the version 0.19.7. It is still a bit of a pain to get it updated but Fan provided the new visual studio projects and the downstream patches required for it to build properly. He also told me that things are changing upstream so soon we will probably be able to build it directly from an upstream tarball.
• We have added the possibility to build Debug or Release versions of the projects. Before only release versions were built, but as you may know Visual Studio will use different runtimes depending on whether you have release or debug so to avoid problems it is suggested to always use the same runtime for all the dependencies of your project.
• cairo, pixman, libxml2, harfbuzz, libpng are now using the upstream build system. This makes our life easier to update them.
• We have updated to the last version all the projects.
• Added support for Git projects. This allows to build from a clone instead of from a tarball.
• Created a new library called Wing. It provides utilities that are windows specific. To highlight some of them, Named pipes or Windows services.
• New projects have been added: json-glib, grpc, json-c, leveldb, libmicrohttpd, libssh, libssh2, protobuf, protobuf-c, x264, FFmpeg, lz4, adwaita-icon-theme, cogl, clutter, gtksourceview, libjpeg-turbo, libcurl, libuv, libyuv, libzip.

Feel free to give it a try and make a pull request if there is any library or application that you are missing on gtk-win32. Specially I would really like to see there GStreamer.

In march, NICE was acquired by Amazon, as part of that I became an Amazon employee and since then with my colleagues we kept improving our High Performance Computing and remote visualization technologies. If you would like to get an opportunity developing one of the most innovative and performant remote desktop solutions in the market and help us to make 3D applications first class citizens in the Cloud, please have a look at our offers and please do not hesitate to contact me or Paolo if you need more information.

Our current offers can be found here: https://www.amazon.jobs/it/locations/asti-italy

In addition to the skills listed in the announcements, a deep knowledge of the Linux graphic stack (X, OpenGL, Wayland, etc.) will be very appreciated.

Apart from the release of gedit introduced on the previous post. Here you can see the last release of gitg running on Windows. There are still some minor problems with it but it is already working good enough for a daily usage. Also, it integrates with the context menu so you can right click on a folder and open it with gitg which will open the repository if it is a repository or fallback to the dash if it is not.

Download the the installer of gitg from this link.

It wasn’t without time but I am finally proud to say that we have a new version of gedit for Windows. This was a long road getting GTK+ 3 and all the dependencies properly working and there are a lot of people behind this, so thanks to all of them for the hard work.

To download the new installer follow up this link.

Following up with Emmanuele’s blog posts about GTK+ being “dead” or “dying” I wanted to point out about the status of the MSVC builds for the GTK+ stack. Refer to my previous post to understand how to build it. During this cycle quite a few things have been done in order to further improve the status of the Visual Studio builds.

• The packages have been updated in order to build GTK+ 3.18. This took longer than expected since we actually had to stick with 3.14 until we are finally able to build libepoxy which was the missing dependency in order to build GTK+ > 3.14
• The builder is slowly starting to get support for VS 2015. This is not so easy since we had to fix glib to not use constructors but to use a DllMain. We added a patch to this bug to finally support this properly.
• GTK+ 3.18 depends on an unreleased version of cairo. This means that we had to put some patches downstream in order to be able to build this last version of GTK+. We hope to have a new version of cairo soon though.
• libsoup has got support for msvc projects as well as gsettings-desktop-schemas. A release is needed in order to get them into the builder.
• glib-networking has a wip branch that adds support for msvc projects as well as TLS support for windows using openssl. For more details on this you can refer to my previous post about this.
• libepoxy was fixed upstream in order to build with msvc, although there are still no msvc projects upstream so we had to add them to the builder.
• We are still using an old version of harfbuzz but we are working in order to get new projects that will build the last version. This should also improve the situation for other projects depending on it, like mozilla projects or libreoffice.
• librsvg got support for msvc projects and Federico already made a new release. Now it is just a matter of integrating it in the builder.
• libdb and cyrus-sasl have been added to the builder.
• libffi is now up to date on the builder.
• gobject-introspection got also support for msvc. This is a bit more problematic to get integrated in the builder but we hope to get it done soon.

As usual Chun-wei Fan is the one to thank for keeping the msvc projects up to day and for adding the new ones.

I would like to officially announce that at NICE we have been working on a TLS backend for glib using Openssl. This still lives on the wip/openssl branch of glib-networking but hopefully next cycle we will manage to merge it to master.

Why are we not using the gnutls that is already implemented? There are a few reasons for it:

• We needed TLS support on Windows. You may say, but gnutls is built on windows with mingw! Well, we are using Visual Studio and it does not build with it.
• Our product has to run at least on RHEL 6, which means, we would have needed to port the current gnutls backend to the old version shipped there, it would have been possible but at the end of the day we wanted to have the same code base on both platforms.
• We depend also on cyrus-sasl which already depends on openssl, so we didn’t want to ship two TLS backends and have twice the bugs.

During the time that I spent implemented this backend I came to the conclusion that TLS is really hard! And it would have been harder if glib-networking didn’t have all those great unit tests. Thanks to all the people that wrote them.

As you may know Christian Hergert introduced a first version of the minimap for gnome-builder. During the last few days we were working on getting it merged into GtkSourceView and it was pushed to it a few days ago. Now as a final step I added it to gedit. This was one of those features that were requested for a long time so we hope that you will enjoy it!

On Friday Paolo Borelli introduced Nuntius, the small project we’ve been working on to display android notifications on a GNOME desktop.

The feedback we got in these days has been great and it is energizing to receive comments, suggestions, bug reports and even patches! Thank you!
It is probably a good idea to clarify some things and reply to some frequent questions we received.

First of all we want to stress again that what is available today is basically a prototype: as soon as we had something able to connect and show the notifications we went ahead and published it because we think “release early, release often” is the best strategy when it comes to free software. Until yesterday it was not even set up to be translated, thought that is now fixed (hint hint!).

• Scope: we think better integration between GNOME and smartphone is a very interesting area where a lot of features could be added. People suggested being able to send SMS from your desktop application, being able to answer phone calls through a headset connected to the PC, being able to send notifications to the phone when some events occur, etc. These are all things which I would love to see in GNOME, but I am not sure they belong in Nuntius: for now we think we should focus on one thing: showing phone notifications. Should these other features be part of Nuntius? Should they be programs that complement Nuntius? Should they be part of a larger effort that supersedes Nuntius? Just jump in and help us out to shape the answer to these questions!
• Bluetooth: we selected bluetooth instead of wifi because it seemed a natural fit for the task: it gives us discovery and pairing of devices out of the box, it gives us a meaningful concept of “proximity” and in our understanding it uses way less power (we do not have hard data, but we keep Nuntius running on our phone and we do not see it show up among the top apps using the battery). The fact that wearables like smart watches use bluetooth seemed to validate our choice. With that said, we have not ruled out also using wifi and help in that direction is more than welcome: for instance we also hit a technical snag in our initial test using plain TCP: the communication would be interrupted once the phone suspends… I am pretty sure this is solvable, but we did not investigate.
• Why not KDE-connect? the very simple answer is that we did not know about it… Nuntius is a fun project born in front of the coffee machine because we wanted to learn something about android and at the same time do something that we would use every day. We did not spend much time researching existing things, we just went ahead, fired up an editor and started a prototype. Now that we do know about it, we will surely check it out… that’s the beauty of free software!
• Why not a standard protocol? Once again we did not research much, so I would not be surprised if we missed something and if you have any pointers they are very welcome… Our understanding is that there is a Bluetooth profile for notifications, but glancing at the spec, it is much more limited than what we need (e.g. it tells you how many notifications you have, but not the content)
• What about iOS? Once again the answer is surprisingly simple: we do not have an iOS device, but if someone wants to start a nuntius-ios project, we would love to integrate it

As part of my work at NICE I had the opportunity to research a bit how to build the GTK stack using MSVC. The reason for this is that even if we are currently using the msys2 binaries and we are quite happy with them, it becomes a pain to debug any issue you might have in GLib or GTK from MSVC.

The hexchat people took the instructions from Fan and made them easy to build GLib and GTK2 using a powershell script. After learning and fighting powershell (which BTW is actually quite nice) I made a fork of hexchat‘s repository and added GTK 3 to the build system. It is actually quite impressive how you manage to build everything with this script in a windows 7 VM in less than 6 minutes.

I am sharing this with you because those who had to fight GTK on windows I am pretty sure didn’t have it very easy. Also I think there are a lot of things to improve here:

• Make it a bit more like jhbuild, where you choose what you want to build without dealing with the dependencies if you do not really want
• Stop getting custom sources and use the upstream ones. This is one of the things that I worked on, supporting tar.xz on the powershell script.
• Try to get closer on the setup to upstream msvc projects. This means that right now for each project we keep a copy of the msvc projects to just modify the place where we want to build and install the binaries. This is bad, we should just use upstream’s setup which is good enough.
• Remove the dependency on mozilla-build. I’d rather use msys2 instead.
• Make it build with GObject introspection support.
• Have something like jhbuild modules so we could support different versions of the sources.
• Make it build from git: this would be great for continuous integration, but unfortunately at the moment some this is not possible due to the files generated at the dist process.

The current solution we managed to get working is actually good enough for our purposes for what we use glib and gtk on our product but if someone wants to improve this I think it could be really good for the future of GTK and GLib.