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.
From the Wikipedia: a Windows service is a computer program that operates in the background. It is similar in concept to an Unix daemon. A Windows service must conform to the interface rules and protocols of the Service Control Manager, the component responsible for managing Windows services.
If you use GLib to try to implement such a program you will end up using the Win C api directly which for this case it is not something that easy to do. At NICE as part of a project we are working on, we decided to make it easier and to provide an abstraction using all the goodness from GLib for these services. Even though we have simplified a bit the design since we allow to have only one service per process, the abstraction allows to “Wrap” a GApplication and run it as a Windows Service.
In the nice-mit repository you can find two classes to make it easy to handle these services:
- dcv-win32-service-manager: it provides some actions to handle the service manager, by allowing to request to install/uninstall/stop/start a service.
- dcv-win32-service: it is the main class to use, it allows to pass the GApplication that will make run and to specify the flags for the actions it will provide to the Windows Service Manager. The Service also hooks into the GApplication to provide some command line options to make it easy to run the actions provided by the manager, i.e you can launch your application as ./test –install to ask the Service Manager to install the service. As a bonus it also handles the parameter “-e or –exec” to provide a way to launch the application without the need of the Service Manager, this way you can launch your application from a terminal directly.
As example of how you would use this you can see here some code:
int main(int argc, char **argv)
/* the GApplication to run */
GApplication *app = g_application_new("com.nice-software.testservice", G_APPLICATION_FLAGS_NONE);
/* the service wrapping the GApplication */
DcvWin32Service *service = dcv_win32_service_new("Test DCV Service",
int status = dcv_win32_service_run(service, argc, argv);
If you ever wrote a console like application for windows and you need this application to deal with the signals the operative system is sending to it for closing it, you might already know that it is not so easy. If you taskkill the application or if you have this application running while the uninstaller runs, it will send a WM_CLOSE signal to the application, in order to catch this signal you need to have a Window, if you do not have a window you will not be able to handle it, or at least this is the recommended way I have found out on the Microsoft documentation. In order to make your life easier at NICE we developed a small class that creates a hidden window for you and allows you do listen to signals for that Window. This class can be found in the nice-mit repository.
As you may know already Christian is running a fundraiser for GNOME Builder, if you have not contributed yet you should!. One of the cool things he prototyped for Builder was a style scheme chooser allowing to easily visualize the style scheme you have available. Last week I decided to take his prototype and put it upstream in GtkSourceView. As a prove the screenshot is showing this new widget used in gedit. I hope you will enjoy and probably it will get into more applications soon.