{"id":1290,"date":"2021-01-29T13:21:24","date_gmt":"2021-01-29T12:21:24","guid":{"rendered":"http:\/\/hobbykeller.spdns.de\/?p=1290"},"modified":"2021-02-05T15:19:05","modified_gmt":"2021-02-05T14:19:05","slug":"creating-custom-widgets-for-pygtk-in-glade","status":"publish","type":"post","link":"https:\/\/hobbykeller.spdns.de\/?p=1290","title":{"rendered":"Creating custom widgets for PyGTK in Glade"},"content":{"rendered":"\n
\"Glade_Custom_Widgets\"<\/figure><\/div>\n\n\n\n

When developing GUI applications for Python, PyGTK<\/a> expects the the coder to define the complete layout of the GUI with its objects and the corresponding wiring of events, signals and actions in the code. This can be quite tedious, and fortunately there is Glade<\/a> which is UI designer that allows to graphically layout a window. It then produces an XML file that can be added to the Python code<\/a>. One question that remains is: How can I add custom widgets that extend standard Gtk widgets to Glade? This is what I am going to demonstrate in this post.<\/p>\n\n\n\n

1. Definition of “custom widget”<\/h1>\n\n\n\n

There are two cases that are covered by the term custom widget:<\/p>\n\n\n\n

  1. A group of two or more standard widgets that are dubbed composite widgets<\/strong> in Glade. The typical show case for composite widgets is a GtkLabel that serves as a description for a GtkEntry<\/a> next to it (there is also a YouTube video<\/a> corresponding to the slides).<\/li>
  2. An extension of an existing standard widget<\/strong> that is obtained by sub-classing and exposes and\/or overrides additional properties, methods, signals – the usual stuff you would expect with sub-classing.<\/li><\/ol>\n\n\n\n

    We will focus on the second case, i.e. a custom widget that we derive as a subclass from a standard Gtk widget. I will demonstrate this with the AwsomeTextView<\/code> subclass that has been derived from the standard Gtk.TextView adapted from this askubuntu.com discussion<\/a>. Although this discussion dates back 10 years, for me it’s still the most useful set of instructions I have been able to find on the net.<\/p>\n\n\n\n

    2. What we need to achieve the above<\/h1>\n\n\n\n
    \n

    We have two challenges to overcome in our custom widget exercise:<\/p>\n<\/div><\/div>\n\n\n\n

    1. Organize the housekeeping inside Glade: Glade needs to know what custom widget it should take to its toolbox, from which standard Gtk widget class it is derived, what placeholder icon is used in the toolbox, what properties and methods the widget exposes, what signals it should feature and connect to potential callback functions.<\/li>
    2. Import the custom widget into the code of our final application. This includes both the import of the code module belonging to our custom subclass as well as the xml<\/code> information for the Gtk.Builder<\/code>.<\/li><\/ol>\n\n\n\n

      2.1 Set up Glade to feature a custom widget<\/h2>\n\n\n\n

      In its current version 3.22, Glade needs two things for processing a custom widget: an xml<\/code> file dubbed catalog file<\/strong> that holds information such as the name of the widget, the widget group it belongs to, the parent widget it extends, the icon that should be used for the widget in the placeholder, etc.<\/p>\n\n\n\n

      Secondly, we need a Python file called module file<\/strong> that holds the usual subclass code of the custom widget: name of the subclass, the parent class it extends from, additional properties and methods exposed, overrides, etc.<\/p>\n\n\n\n

      2.1.1 Catalog XML file<\/h3>\n\n\n\n

      Older versions expect this file to be saved in some \/usr\/...\/glade\/catalogs<\/code> directory or similar. In Ubuntu 20.04 LTS with the standard apt<\/code> (not snap) installation of Glade, the directory would be \/usr\/share\/glade\/catalogs<\/code>. More recent version of Glade allow to specify extra catalog paths that are scanned for catalog xml<\/code> files.<\/p>\n\n\n\n

      As the catalog file is also needed for the final application, it is therefore recommendable to save directly in the application directory and add the directory path as an extra catalog path in the Glade Preferences. This way we avoid having to fiddle around with the PYTHONPATH<\/code> environment variable on our system.<\/p>\n\n\n\n

      From other samples I found on the internet, I have composed the following catalog file awsome_text_view.xml<\/code> for my AwesomeTextView<\/code> widget that I want to add as a custom widget to the Glade toolbox:<\/p>\n\n\n\n

      <glade-catalog name=\"awesome_text_view\"\n    library=\"gladepython\"\n    domain=\"glade-3\"\n    depends=\"gtk+\">\n\n <init-function>glade_python_init<\/init-function>\n\n <glade-widget-classes>\n   <glade-widget-class title=\"Awesome TextView\" name=\"AwesomeTextView\"\n                       generic-name=\"awesome_text_view\" parent=\"GtkTextView\"\n                       icon-name=\"widget-gtk-textview\"\/>\n <\/glade-widget-classes>\n\n <glade-widget-group name=\"python\" title=\"Python\">\n   <glade-widget-class-ref name=\"AwesomeTextView\"\/>\n <\/glade-widget-group>\n<\/glade-catalog><\/pre><\/div>\n\n\n\n
      <\/div>\n\n\n\n
      <\/div>\n\n\n\n
      A few words on the structure of catalog files:<\/p>\n\n\n\n