Breaking changes in Thunar Extensions API
acs82 at gmx.de
Mon Oct 9 23:04:33 CEST 2017
Good work & thanks for this summary of the current state !
2) is perfectly fine for me.
I fully agree, the thunarx API has priority. The thunar-internal
GtkActions possibly we can replace later, step by step.
Hope there are as well some thunar plugin-devs reading this.
... now finally going to checkout & read your new branch :)
On 08.10.2017 18:22, André Miranda wrote:
> Besides the pending issues  we need to solve before a Thunar dev
> release, I
> wanted to handle as much deprecations as possible. At merge time,
> there were
> 1336 warnings, now they are "just" 691 .
> A considerable amount of those deprecations are due GtkAction and
> their replacements (GAction and GBuilder) aren't actually drop-ins
> , we would
> need to re-implement the menu related code: use glade-based xmls for
> GMenu and
> custom functions to achieve the merge capabilities of GtkUIManager and
> perhaps a
> few more hacks I can't remember or predict. That was the approach
> adopted by
> Nautilus, but its UI has been revamped since then, and I can't say how
> well it
> would work for Thunar's "more traditional" UI.
> It's possible to just live with the deprecation warnings (or suppress
> until gtk4+, annoys me but I'm fine with that. Nevertheless, I think
> deprecations must be removed from Thunar Extensions API (thunarx) and
> the soname
> version was already bumped to 3 in order to avoid conflicts with gtk2
> This leads to the approach adopted for Nemo: clean the API and let all
> stuff internally. I have already prepared a WIP branch replacing
> the GtkAction
> usage but I'd like to listen from you guys which way we should pick:
> 1) Keep GtkAction in thunarx, anyway we'll have to bump thunarx
> version again
> when porting to gtk4, hopefully there will be a better replacement for
> GtkAction and GtkUIManager by the time.
> 2) Just remove GtkAction from thunarx API. Hopefully by the time of
> gtk4 port
> the soname version bump will be just to avoid symbols conflicts (my
> 3) Clean all deprecated stuff from Thunar. (don't expect me to work on
> Regarding the implementation of the WIP branch, I picked
> ThunarxMenuItem as the
> replacement of GtkAction based on Nemo and Nautilus, but I'm open for
> suggestions of better names. Also I didn't rename methods such as
> get_file_actions, get_folder_actions and get_dnd_actions, so it's
> still a bit
> This change touches ThunarxMenuProviders and
> ThunarxPreferencesProviders only,
> the other providers use API specific classes instead of GtkAction,
> that's the
> same rationale for ThunarxMenuItem.
> If you reached this point, thanks your patience and sorry for my
> limited skills
> with words :). If you want to put your 2 cents or find something
> please reply this e-mail or let's discuss this on #xfce-dev.
> 1 - https://wiki.xfce.org/releng/4.14/roadmap/thunar
> 2 - https://wiki.xfce.org/releng/4.14/roadmap/thunar/deprecations
> 3 - https://wiki.gnome.org/Projects/GTK+/Menus#Comments
> 4 - https://github.com/andreldm/thunar/tree/gtkaction-replacement
> Andre Miranda (not Thunar's maintainer)
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
More information about the Xfce4-dev