Nacho's Blog

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",
                                                   DCV_WIN32_SERVICE_CAN_BE_SUSPENDED |
                                                   DCV_WIN32_SERVICE_CAN_BE_STOPPED |
                                                   DCV_WIN32_SERVICE_STOP_ON_SHUTDOWN,
                                                   app);
  int status = dcv_win32_service_run(service, argc, argv);
  g_object_unref(service);
  g_object_unref(app);

  return status;
}

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.

For the last few years I have been working on getting gedit builds for Windows and it has never been as easy as now. In this post I will explain the steps you have to do to easily build your application on Windows.

• Install the latest version of msys2. You can get it from http://msys2.github.io/. Ensure to install it on a short directory path, i.e the default c:\msys64 should be fine. Highlight that this is msys2, which compared with the previous msys system this one is fast and well maintained.
• Open the msys2_shell.bat that you can find in c:\msys64.
• Update it by running: pacman -Syu. This will probably update msys2 so you will have to relaunch again the shell.
• Install the toolchain, in my case I installed the x86_64 but you can install i686 or both. To do so: pacman -S mingw-w64-x86_64-toolchain
• Create a PKGBUILD file as you would do for Arch Linux for the package you would like to build for windows. You can find the gedit one here. Or you can find more information on how to create this file on the Arch Linux wiki.
• Once you have the PKGBUILD file ready build it by running “makepkg-mingw -sL”. This will build your project and generate a package.
• Install this package with pacman -U file
• If that package your are trying to build is not already shipped by msys2 or if it is too old and you want to update it you can fork the MINGW-packages repository and add it to it and make a pull request.
• If the package reach upstream you will not need to build it anymore in order to use it but you can simply install it by doing: pacman -S mingw-w64-x86_64-package-name
• As an example installing gedit on Windows it is just a matter of installing msys2, update it and run “pacman -S mingw-w64-x86_64-gedit”

As you see installing and or building an application is not that difficult anymore, but as like for the case of gedit you might want to create an installer which will make easy to distribute your application. Since pacman allows you to create new roots, what I did is to create an installer based on pacman. The files can be found here. To explain a bit better how this works, here is what each file from that link mean:

• make-gedit-installer: is a bash script which installs the base msys2 system in a specific root, in this case /tmp/gedit, and then it installs gedit and all its dependencies. Since some of them are not needed as they are optional, it also takes care of removing them.
• make-gedit-installer.bat: it runs make-gedit-installer in 2 stages. The first one installs the basic system and the second stage installs gedit and its dependencies.
• qt-ifw: it is used the QT sdk installer. I know it is QT but it is actually quite easy to use and anyway it is just an installer. This folder defines the packages and the installation procedure. It just a few xml files that you have to edit to set the information of your package and it also contains some Javascripts to define the installation.

I hope this helps to get your application ported to Windows and if you have any questions you can contact the msys2 team on the #msys2 channel of the OFTC IRC. Of course if you have any doubt and you prefer to contact the gedit team we are like usual in the #gedit channel on the Gimpnet IRC.

It has been a while since the last release of gedit for windows. After some work I am proud to announce that a new version of gedit is available. This version can be downloaded from here.

This new version features the latest unstable version of gedit 3.13.4 with all the unstable versions of the libraries we depend on (GTK+, Glib, atk, gtksourceview… etc). If the word “unstable” does not take you out the idea of trying it, please give it a try and report any issues that you may find. Right now it is known that the Start menu link is not working properly and that some of the python plugins crash the application.

On the next post I will explain how you can create the installer for gedit by yourself, how you can build gedit easily on windows and how you can actually do to build for windows your GTK application or library in a few steps.

At NICE we make use of GTK+ on Windows, Linux and OSX on our product Desktop Cloud Visualization. Till now we managed to do everything with the released versions of GTK we were getting from gtk.org but we are in a point where we need the new features from GLib and there are no new versions for Windows. The point, we were checking all the possibilities out there, sbuild, hexchat’s, using fedora’s mingw binaries, using suse’s mingw binaries… Either they did not provide all the packages or they just provided the packages for win32 and not for win64 but we did not manage to have a bundle of the gtk’s libraries.

As you may know Tarnyko was the previous person in charge of making the GTK bundles, he did a really good job and he also provided a build system to setup the build system and build all the required libraries. The problem is that it was not setup in a git repository, it was providing all the tarballs and it was not easy to update them, since you would have to download the tarball, replace the old one and update the scripts to build it. What we did was to take this build system and improve it so things are a bit more automated, so at the end you just have to update the version number to get the new version of the library built, we’ve also set it up so it builds glib 2.40 and gtk2 2.24 and gtk3 3.12.

We have released this new build system under the GNOME repository: https://git.gnome.org/browse/gtk-builder-win

If you have any doubts, you want to contribute to it (please do it!) feel free to send us a mail, contact either me or pbor on the gtk+ channel of the IRC.

We just landed to git master the changes that implement a refresh of the main user interface.

While small changes and iterations in the UI happened in every cycle, this is the most radical change in the UI in years so it is a very important and significative change.

The goal of this work is to create a modern, slicker interface which wastes less screen estate and lets you focus on the text or code you are writing. No features were harmed in the making of this new UI.

These changes bring gedit in line with the latest GNOME conventions and take advantages of the new design patterns and GTK widgets.

However some of the concepts there have been brewing for a long time and saw many iterations in test branches and mockups.

Some words about what you see in the pictures above

• not everything is set in stone, we would very much welcome feedback
• the tabs look and feel is part of the latest Adwaita gtk theme and not something custom in gedit and could be still subject to changes
• while what you see is the new default look of gedit, the changes to the code base should allow us to have far better integration with the environment we are running on and allow us to easily have different UI on OSX, Windows, Unity, etc. (help from people running gedit out of gnome-shell is very much welcome)

What about plugins

plugins that interacted with the menu will need to be adapted to the new API. We are a bit sorry we had to (partially) break the plugin API again, but this cannot be helped since with the current manpower we can focus on a specific set of changes during each cycle.

We hope you enjoy this new face of gedit and you are very welcome to enter in the #gedit channel of the Gimpnet IRC in case you want to contact with us and discuss any issues about the new design or if you want to help to better support gedit in your favourite desktop environment.

These days is having place the DX Hackfest so I thought it would be nice to show a new feature I was working on for gedit.

If you are interested in this plugin you can get it from my github.