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.
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.
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.
At the beginning of this year my old Dell XPS M1530 ended the warranty. After a few months trying to decide between a Lenovo and a Dell, I decided that for my work and also because of the great support they provide no matter in which part of Europe you are, I bought a Dell M4700. This was more or less right after I was at GUADEC and to be honest, since then it was quite a nightmare to make it work correctly in Linux.
The first distribution I tried in that moment was Fedora 17. I was working mostly. I needed the nvidia proprietary driver, ’cause nouveau didn’t work for my graphic card. Maybe too new at that time? This was ok, I installed the driver and it worked quite ok. What really pissed me off was that the touchpad didn’t work at all like a touchpad but like a normal mouse. The first thing that I did was to check if Ubuntu supported this laptop. In their web page it was saying that they did. (It was a lie) How you can support a laptop if it is not correctly working? Anyway after some more research I’ve found out that the touchpad in this laptop uses a new ALPS protocol not supported by the kernel.
In this post I could tell you all the insane things that I had to do to manage to finally get it working. But I will just put you here the steps that you have to follow in case that you are with a Fedora 17 or 18 and you have the same problem.
If the problems with the NVIDIA driver and the touchpad weren’t enough, a couple of weeks ago after some update in Fedora 18, I started to get hangs in my wireless connection. My first thought was, how is that possible? I am running Fedora 18 but with my custom Fedora 17 which has the touchpad working. Just this week after a post from Alberto Ruiz pointing me to the proprietary driver of Broadcom, I decided to install the broadcom-iwl package and now it is working as it never worked before. Thanks again Alberto for opening my eyes.
And that’s it. Is this how Linux will conquer the world? Dunno, every time that I want to install Linux into a computer I always end up getting a lot of troubles. Unless we get something done at the respect we will really not reach all the normal people out there who just want to install an Operative System and work with it. To be honest I really encourage people to use the proprietary drivers if you are having these problems too.
Finally I want to thank Ben Gamari for the help provided on this touchpad topic and for reverse engineer the new Alps protocol.
It’s been quite a long time without blogging about anything so I will take finally some time and write about the latest and greatest things that I’ve been doing in this last few months.
That’s it, some of you may have heard that GNOME is moving to Python 3 and since last week we are already using it in the gedit master branch. The plugins in the gedit module are already ported and working, although they need some testing so if you are brave enough and you want to try, some feedback is appreciated. About the other python plugins that we maintain in the gedit-plugins module we are just missing a couple of plugins. One of them, the dashboard is waiting for Seif and the syntex plugin is waiting for Jose. Hopefully they will be soon ported and we will be able to merge the wip/python3 branch into master.