Deprecation of UIManager in Gtk4. There are no replacement that can
handle toolbars and merging and unmerging. We use Addins in our
application and need to be able to merge in Menu and Buttons(toolbar).
This needs to be solved, either by making the new GAction stuff handle
Toolbars and merging/unmergin or be undeprecating the UIManager.
The change to Popover in comboboxes. A popover can’t be lager than
it’s parent window and the is a problem. I know that Wayland will fix
this, but this need to work on Windows and Mac OS X aswell.
You should definitely bring these concerns to gtk-devel-list.
I can quickly answer on GtkUIManager: merging and unmerging can be
done with GMenu and GAction; we are kind of phasing out large toolbars,
but you can use containers like GtkStack and GtkRevealer to build
different toolbars and showing them when modes change, instead of
merging/unmerging widgets. Ideally, though, adding support for toolbars
to GAction and GMenu should be feasible. We’re definitely not going to
undeprecated GtkUIManager — it’s redundant to two different APIs
(GtkBuilder and GMenu/GAction), and it cannot be retroactively fixed to
export menus on the session bus, which we consider a key functionality
for multiple platforms: GNOME, Unity, and OSX.
As for combo boxes, I’m not sure I follow; combo boxes haven’t been
moved to popovers. There’s a plan for a simplified widget that uses a
popover, but it hasn’t landed yet. Popovers do extend outside of the
window on Wayland and, ironically, it should be easier to make them do
the same thing on OSX and Windows than on X11, because of the various
grabs that we even have to emulate on those platforms, and that led to
the creation of popovers.
It all comes down to: are you willing to help out with improving,
testing, bug fixing, and QA-ing the backends and functionality you need?
GTK is not a “black box”; we don’t have engineers working full time on
supporting different platforms, or doing QA. If you have an issue, you
*need* to get involved — like the Elementary developers, or even
corporate developers using GTK in their consumer products. What you
cannot do is picking up GTK every 12/24 months, list the things you use
and that have been deprecated, and not put any work into ensuring that
the direction the toolkit is going towards also includes your use cases —
because, at the end of the day, the people that do work on GTK do
exactly that.
--
I am already helping with fixing and testing. We update the Gtk+ framework for our applications every 6 month (from Fedora mingw32/64 release cycle). I definitely would like to help testing toolbar support in GAction and merging/unmerging (if not already working). If someone would like to help implement it (we are willing to pay for the development).
My biggest concern is:
Deprecation of UIManager in Gtk4. There are no replacement that can handle toolbars and merging and unmerging. We use Addins in our application and need to be able to merge in Menu and Buttons(toolbar). This needs to be solved, either by making the new GAction stuff handle Toolbars and merging/unmergin or be undeprecating the UIManager.
The change to Popover in comboboxes. A popover can’t be lager than it’s parent window and the is a problem. I know that Wayland will fix this, but this need to work on Windows and Mac OS X aswell.
Cross platform is very important to us.
--
Answer from Emmanuele
You should definitely bring these concerns to gtk-devel-list.
I can quickly answer on GtkUIManager: merging and unmerging can be done with GMenu and GAction; we are kind of phasing out large toolbars, but you can use containers like GtkStack and GtkRevealer to build different toolbars and showing them when modes change, instead of merging/unmerging widgets. Ideally, though, adding support for toolbars to GAction and GMenu should be feasible. We’re definitely not going to undeprecated GtkUIManager — it’s redundant to two different APIs (GtkBuilder and GMenu/GAction), and it cannot be retroactively fixed to export menus on the session bus, which we consider a key functionality for multiple platforms: GNOME, Unity, and OSX.
As for combo boxes, I’m not sure I follow; combo boxes haven’t been moved to popovers. There’s a plan for a simplified widget that uses a popover, but it hasn’t landed yet. Popovers do extend outside of the window on Wayland and, ironically, it should be easier to make them do the same thing on OSX and Windows than on X11, because of the various grabs that we even have to emulate on those platforms, and that led to the creation of popovers.
It all comes down to: are you willing to help out with improving, testing, bug fixing, and QA-ing the backends and functionality you need? GTK is not a “black box”; we don’t have engineers working full time on supporting different platforms, or doing QA. If you have an issue, you *need* to get involved — like the Elementary developers, or even corporate developers using GTK in their consumer products. What you cannot do is picking up GTK every 12/24 months, list the things you use and that have been deprecated, and not put any work into ensuring that the direction the toolkit is going towards also includes your use cases — because, at the end of the day, the people that do work on GTK do exactly that.
--
I am already helping with fixing and testing. We update the Gtk+ framework for our applications every 6 month (from Fedora mingw32/64 release cycle). I definitely would like to help testing toolbar support in GAction and merging/unmerging (if not already working). If someone would like to help implement it (we are willing to pay for the development).