Xfce accepted to Google Summer of Code 2022

Good news, Xfce has been accepted to Google Summer of Code 2022 !

This time not only different thunar projects will be mentored, but as well some xfce4-terminal, xfce4-screenshooter and xfce4-panel projects. Check our Xfce GSoC Wiki for a detailed list of project ideas !

If you are not much involved into Xfce yet and interested in software development, now might be a good opportunity to contribute to Xfce while even getting payed for it !

In case you are already involved in Xfce development, you might be interested to mentor a GSoC contributor and add some project idea to the ideas-list for which you can do mentoring.

For more detailed information, best check the guides on the official GSoC page.

Hope to see you there !

Shiny new things in Thunar thanks to GSoC 2021

GSoC 2021 is over now and I am happy to tell you that both students working on thunar did an excellent job. Alot of nice stuff has been added thanks to them !

In order to allow you to discover all these new features, Thunar 4.17.5 was just released. (Note that this is a development release. It still might have some rough edges)

For details about the new features check the summaries provided by Sergios and Yongha:

• Sergios GSoC Summary
• Yongha's GSoC Summary

Besides these, here as well some more new features added during GSoC for which I thought they would be worth to mention:

Bookmarks got moved into a separate 'Bookmarks Menu' and a 'create bookmark' option was added (MR !109 and MR !71)

A new menu item "Set Default Application" was added to the "Open with" submenu (MR !79)

A new section 'Default Application' was added to the 'thunar-chooser-dialog' (MR !81)

On top there are still various open merge requests with partial finished features, most of them from GSoC students for which I did not find time so far. So expect more new stuff to arrive soon !

You as well might want to keep an eye on xfce4-terminal, which received alot of activity recently, since it is now maintained by Sergios Kefalidis.

If you find a bug on any of these new features, please make use of the xfce bugtracker.

Happy testing !

Xfce participation in GSoC 2021

I am a bit late with my blog post .. though I suppose better late than never :D

This year Xfce applied to the Google Summer of Code program and I am happy to tell you that we accomplished to get 3 slots ! (That's very good, since new organization usually only receive one or two slots)

There was a lot of interest by students. In total 15 proposals were received for Xfce. So sadly we had to refuse several nice proposals. However the number of mentors as well was limited, so that this year Xfce anyhow would not be able to mentor more students.

Now there are 3 very motivated GSoC students supporting Xfce. Allow me to introduce:

• Yongha Hwang, who applied for various thunar issues, mostly related to file transmission.
• Sergios Anestis Kefalidis, who as well works on thunar, targeting a wide range of features.
• Vishal Sharma, who is looking into sample/skeleton panel plugins in different GOI supported languages.

Since I maintain thunar, I am the main mentor of Sergios and Yongha.

These two and as well some other thunar focused GSoC applicants kept me very busy by adding many contributions long before the official coding part started :) Already now I think mentoring for GSoC was a good thing to do. The gain by far outweighs the burden. I don't have much time left to work on issues myself, though the students overcompensate that by magnitudes.

Here a small taste of the recent activity related to GSoC:

• Thunar issues fixed by GSoC students
• Currently 12 open thunar merge requests, 9 opened by GSoC students

... and that is only thunar. There is as well a lot of activity on exo and libxfce4-util !

Many various smaller tweaks already made it into thunar 4.17.2. Some bigger ones, e.g. issues from the [project ideas list](https://wiki.xfce.org/projects/gsoc/start#project_ideas) are currently in work, or even already landed in the current master.

If you want to take a peek on the upcoming changes and new features already now, you can check the students frequent blog posts:

• Yongha Hwang
• Sergios Anestis Kefalidis
• Vishal Sharma

Hope you will enjoy the upcoming changes!

Thunar, GtkAction and a big mess

Overview

My journey into the GtkAction abysses of Thunar began in the mid of 2019. Be warned, it is no story of success. It is rather a story about finding a way through a maze while walking into almost every dead end.

Actually I just wanted to fix #198 (Merge all file-context-menus into one). But somehow things got weird. More than half a year later and after numerous interactive rebases I finally merged my branch into master \o/

Motivation

The old Thunar used to create the same menu items in different places using different code. In the past that led to inconsistencies. E.g. the location bar only provided a very minimal context menu, no custom actions at all.

From time to time I found myself right-clicking on a `location-button`, just to find out that there still is no `custom action`. At some point of maximal annoyance I decided to fix that problem ... not sure if I would have done so when I knew how long that road would be.

Looking at thunar-location-buttons.c revealed a lot of duplicated code. thunar-standard-view and thunar-window both used the deprecated GtkActionEntry to define `menu item labels` and related actions. The `location buttons` just mirrored parts of that code. On top some other actions were defined in thunar-launcher or had their own classes, inheriting `GtkAction`.

So yay, lets just copy+paste the missing stuff to the location buttons? Nah, that would be too easy. As a developer who values DRY, it would hurt my belief in clean code to produce more mess.

Let's Start Hacking

I started to do some coding .. first I created a new widget thunar-menu which internally is a gtk-menu, and moved menu-item creation and the related actions for copy/cut/paste/delete/move_to_trash there to have them at some central place, so they can be reused by different menus. I as well moved the actions from `thunar-launcher` to `thunar-menu` (I guess the original intention of the launcher was, to actually launch things, not to manage menu-items) and replaced separate action classes in favour of methods inside `thunar-menu`.

Meanwhile the location-button-menu and the context-menu, which I used for testing, were populated with some items again.

The old code made massive use of the deprecated `GtkAction` and `GtkActionEntry` classes together with `GtkUiManager`. I did not want to add more `G_GNUC_BEGIN_IGNORE_DEPRECATIONS` to silence warnings. So I decided to replace the deprecated calls.

Looking into the gtk3 documentation revealed that there now is GAction and GActionEntry which provides some service around accelerator activation, and there is GtkMenu/GMenu for which at that time I had no clear idea why there are two of them.

The documentation of GAction told me that it should not be used for anything related to labels, icons or creation of visual widgets, damn. So at that time I did not see an advantage in using this class. I decided to rather go for `GtkMenu` together with some custom replacement for `GtkActionEntry`: XfceGtkActionEntry.

In retrospective ignoring `GAction` might not have been my smartest move. Meanwhile I understood how `GAction` can be used with `GtkMenu`, and I will most likely go for it at some later point.

Regarding GtkUiManager: The definition of menu-items of Thunar was scattered across 7 different *-ui.xml files, making it hard to figure out what belongs together. Because of that I decided to just get rid of the deprecated `GtkUiManager` and create menu-items in the code instead of predefining their order in xml. IMO the usage of xml files might be nice for static GUI's, though for dynamic menu-creation it just introduces unnecessary complexity.

So I started to build `XfceGtkActionEntry` and some support methods.`XfceGtkActionEntry` is a structure which holds labels, tooltips, icons, types, the accelerator paths and callbacks to the related actions. Like `GtkActionEntry` it is just a struct and can be filled in a static way.

Next problem: The menus in Thunar so far did not get destroyed, but were updated whenever the selected items got changed, and got shown when needed. That sounded wrong to me. Why should I want to update menu-items, which can be expensive, while no menu is visible at all ? There were bugs about menu flickering and slowness while rubber banding/mass select which seem to be related. Since I anyhow needed to touch that part, I decided to build menus only when they need to be shown.

Things went well, I came to the point where I needed some items from `thunar-window`, like the zoom-section and the view-specific settings. As well most file-menu items in the `thunar-window` menu did not work any more since I moved management of them from `thunar-launcher` to` thunar-menu`. So next step clearly was: Introduce `XfceGtkActionEntry` to `thunar-window` ... and than shit hit the fan.

So far the `thunar-window` menu was always present and took care for any accelerator actions. Since my concept was "create menu on request", there was no menu instance which could take care for accelerators any more, leading to dysfunctional accelerator keys, rendering my whole concept as faulty .. aargh.

Start all over again

After some time of grieve and doubts I fixed the problem by moving most of the code from `thunar-menu` back to `thunar-launcher`, which lifetime is coupled to `thunar-window`.

From now on `thunar-menu` was more or less just an convenience wrapper for `thunar-launcher` ... still useful, but sadly it lost its glory. `thunar-launcher` now builds volatile menu items on request and permanently listens to the related accelerators. Finally accelerators started to work fine, and I was able to continue to fight with the window menu.

I had much more trouble with that menu, too much to tell it here .. however somehow I managed to get it functional, so that it mostly worked like before.

An unpleasant discovery

Later on, while reporting a bug against gtk I learned that the class gtk_accel_map, which I use as a central part will be deprecated soon ... aargh again. The gtk devs so far just missed to set a deprecation macro. So it seems like I will need to touch the accelerator part again. This time I plan to make use of the GActionMap interface .. going to be a story for another day.

Testing and open issues

For first testing and code-review I luckily got support of some early adopters. They found many more defects and regressions which kept me busy a long while. Fortunately nothing concept-breaking was found.

While writing this there are still some regressions I introduced, waiting to get fixed by me before a stable release:

• Regression: Missing accelerators for bookmark items
• GObject-WARNING on closing thunar in some conditions

And there are related tasks on my agenda, for which I just did not find the time so far:

• rename `thunar-launcher` to e.g. `thunar-action-manager`
• use `thunar-menu` in `bookmark view`
• use `thunar-menu` in `Tree view`
• many minor things

Conclusion

Finally I ended up with 25 commits and +4717 / -7149 line changes. The occurrence of `G_GNUC_BEGIN_IGNORE_DEPRECATIONS` got reduced from 250 to 35. The remaining 35 occurrences will further drop when using GtkMenu for bookmark-view/tree-view. That should simplify the move to gtk4 in the future. The `location-button` context menu shows custom-actions now, and as well some other bugs got fixed with the changes.

So overall, the result does not look too bad I guess.

Well, this blogpost grew by far too long. I hope you nevertheless enjoyed the journey into the Thunar internals!

... enough storytelling for now, I really need to take care of these remaining regressions! :)

Thanks to Reuben, AndreLDM, DarkTrick and others for early testing and bug reporting! Special thanks to AndreLDM, motivating me to write this blogpost at all :D.