Breaking changes in Thunar Extensions API

[Alex]

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 :)

Cheers,
Alex

On 08.10.2017 18:22, André Miranda wrote:
> Besides the pending issues [1] 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 [2].
>
> A considerable amount of those deprecations are due GtkAction and
> GtkUIManager,
> their replacements (GAction and GBuilder) aren't actually drop-ins
> [3], 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
> them)
> until gtk4+, annoys me but I'm fine with that. Nevertheless, I think
> these
> 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
> symbols.
>
> This leads to the approach adopted for Nemo: clean the API and let all
> deprecated
> stuff internally. I have already prepared a WIP branch[4] 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
>    preference).
>
> 3) Clean all deprecated stuff from Thunar. (don't expect me to work on
> this).
>
> 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
> awkward.
>
> 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
> confusing,
> 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
>
> Cheers,
> Andre Miranda (not Thunar's maintainer)
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev