GEPS 044 Replace Deprecated Gtk.UIManager

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

GEPS 044 Replace Deprecated Gtk.UIManager

prculley
Gentlemen;

One item that has been suggested for the roadmap for gramps 5.1.x is to correct the Gtk UIManager and associated deprecations.

I have created a proposal and discussion on how this might be done at https://gramps-project.org/wiki/index.php?title=GEPS_044:_Replace_Deprecated_Gtk.UIManager.

I take this goal to mean upgrading several of the currently used Gtk techniques that have been deprecated to the more modern methods. After looking around the web, it appears that there are few write-ups on how this might be done. The best advice available I found is summarized below.

  • Gtk.UIManager is deprecated, use Gtk.Builder instead. UIManager was used to define many of the menus for Gramps using a specialized syntax. Gtk.Builder utilizes an XML input and syntax to define the menus.
  • Gtk.Action is deprecated, use GLib.SimpleAction. Actions are used to separate the Menu items (labels, accelerator, Mnemonics etc.) from what they do.
  • Gtk.ActionGroup is deprecated, use GLib.SimpleActionGroup. The original idea of ActionGroup was to group related menu items together; Gramps used this mechanism to enable/disable groups of menu items when they were not applicable, for instance most menu items were disabled (invisible) when no tree was opened. Sometimes the groups were set insensitive (greyed out) as well.

The new SimpleActionGroup can NOT be used in this way.

The new mechanisms seem to require the use of Gtk.Application and Gtk.ApplicationWindow (at least to avoid other warnings). Using these will involve some changes to our startup code and main window code.

Gtk.Application includes the possibly of a multi document type of interface, potentially with several trees open at once. I propose that for initial work, we do NOT support this. I propose we continue to operate Gramps as a single instance application, where attempts to start another instance only bring the GUI to the front.

Gtk.Application also has several types of support for CLI. For this GEPS I intend to continue letting Gramps deal with the CLI before starting the Gtk.Application (when the GUI is needed). The Gtk.Application will not deal with CLI parameters.

Gtk.Application uses a (hopefully unique) application name to manage its features. I propose that we use "org.gramps-project.Gramps" (which is a valid name according to the rules).

The main goal is to utilize the new techniques instead of the deprecated ones. And to do this with minimal (hopefully no) changes to the GUI or functionality of Gramps.

I have added some additional detail on how this might be done to the GEPS wiki.

I have been testing a small sample application to see if my proposed code changes appear to work; so far I don't see any significant unsolvable problems.

One issue I do see is that the easy way to deal with one of the changes is to use a Gtk.Application method that was not supported until Gtk v3.12, while our current supported Gtk states we should work on 3.10 and above.

Please reply with any comments, suggestions etc. to this email; I will attempt to summarize in the GEPS wiki after a bit of time to let the comments settle out.


Paul C.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel