Migrating from Handy 0.0.x to Handy 1
Migrating from Handy 0.0.x to Handy 1 — Notes on migration to Handy 1.
Handy 1 is a major new version of Handy that breaks both API and ABI compared to Handy 0.0.x. Thankfully, most of the changes are not hard to adapt to and there are a number of steps that you can take to prepare your Handy 0.0.x application for the switch to Handy 1. After that, there's a number of adjustments that you may have to do when you actually switch your application to build against Handy 1.
The steps outlined in the following sections assume that your application is working with Handy 0.0.13, which is the final stable release of Handy 0.0.x. It includes all the necessary APIs and tools to help you port your application to Handy 1. If you are using an older version of Handy 0.0.x, you should first get your application to build and work with Handy 0.0.13.
Static linking support has been removed, and so did the static build option. You must adapt you program to link to the library dynamically, using the package_subdir build option if needed.
Over the years, a number of functions, and in some cases, entire widgets have been deprecated. These deprecations are clearly spelled out in the API reference, with hints about the recommended replacements. The API reference for GTK 3 also includes an index of all deprecated symbols.
This section outlines porting tasks that you need to tackle when you get to the point that you actually build your application against Handy 1. Making it possible to prepare for these in Handy 0.0 would have been either impossible or impractical.
hdy_init() has been removed. Instead, Handy 1 comes with a library constructor which will automatically initialize it when linked. You should just remove calls to hdy_init().
All widget constructors now return the #GtkWidget type rather than the constructed widget's type, following the same convention as GTK 3.
Affected widgets: #HdyActionRow, #HdyColumn, #HdyComboRow, #HdyExpanderRow, #HdyPreferencesGroup, #HdyPreferencesPage, #HdyPreferencesRow, #HdyPreferencesWindow, #HdySqueezer, #HdyTitleBar, #HdyViewSwitcherBar, #HdyViewSwitcher
#HdyFold has been removed. This affects the API of #HdyLeaflet, see the “Adapt to HdyLeaflet API changes” section to know how.
HdyPaginator has been renamed HdyCarousel, so you should replace the former by the later. Similarly, HdyPaginatorIndicatorStyle has been renamed HdyCarouselIndicatorStyle.
The #HdyFold type has been removed in favor of using a boolean, and #HdyLeaflet adjusted to that as the #HdyLeaflet:fold property has been removed in favor of #HdyLeaflet:folded. Also, the hdy_leaflet_get_homogeneous() and hdy_leaflet_set_homogeneous() accessors take a boolean parameter instead of a #HdyFold.
The default value for the #HdyLeaflet:transition-type property is changed from “none” to “over”. “over” is the recommanded transtion for typical #HdyLeaflet use-cases, if this isn't what you want to use, be sure to adapt your code.
#HdyViewSwitcher doesn't subclass #GtkBox anymore. Instead, it subclasses #GtkBin and contains a box.
#HdyViewSwitcherBar won't be revealed if the #HdyViewSwitcherBar:stack property is %NULL or if it has less than two pages, even if you set #HdyViewSwitcherBar:reveal to %TRUE.
Widgets with a customn CSS node name got their name changed to be the class' name in lowercase, with no separation between words, and with no namespace prefix. E.g. the CSS node name of HdyViewSwitcher is viewswitcher.
Action items were packed from the end toward the start of the row. It is now reversed, and widgets have to be packed from the start to the end.
It isn't possible to add children at the bottom of a #HdyActionRow anymore, instead use other widgets like #HdyExpanderRow. Widgets added to a #HdyActionRow will now be added at the end of the row, and the hdy_action_row_add_action() method and the action child type have been removed.
The main horizontal box of #HdyActionRow had the row-header CSS style class, it now has the header CSS style class and can hence be accessed as box.header subnode.
#HdyActionRow is now unactivatable by default, giving it an activatable widget will automatically make it activatable.
#HdyComboRow is now unactivatable by default, binding and unbinding a model will toggle its activatability.
#HdyExpanderRow doesn't descend from #HdyActionRow anymore but from #HdyPreferencesRow. It reimplement some features from #HdyActionRow, like the #HdyExpanderRow:title, #HdyExpanderRow:subtitle, #HdyExpanderRow:use-underline and #HdyExpanderRow:icon-name, but it doesn't offer the “activate” signal nor the ability to add widgets in its header row.
Widgets you add to it will be added to its inner #GtkListBox.
#HdyPreferencesPage doesn't subclass #GtkScrolledWindow anymore. Instead, it subclasses #GtkBin and contains a scrolled window.