GBC Theme Framework

I have found myself using the phrase “the new GBC Theme Framework” in some recent support calls.  This is due to some improvements that were made in GBC 5.01.04, and more details can be found in the GBC 5.01.04 New Features and Upgrade Notes.

You should not have to modify existing GBC customisations straight away, but it is something you should take into account for your GBC Customisation activity, and it is something you would need to be aware of when using the new Genero Theme Customizer which at time of writing is in an Early Access Program.  I would encourage you to register and have a look at it if you have not done so already.

The key point is as documented, there are three layers of Theme Variables …

Theme variables are organized into layers, forming a hierarchy

This reorganization involves renaming and recategorizing the variables into layers and groups. This may not alter your approach to customizing the GBC, but it could provide you with new insights to enhance your customization process.

• Top UI designer layer: This new top layer introduces variables in the ui-* namespace, which map to the existing theme-* variables, providing a foundation for UI customization.
• UI Toolkit layer: This layer contains variables in the mt-* namespace, establishing a base for themes and styles that are applied to Genero application widgets.
• Genero widgets layer: This layer features variables in the gbc-* namespace, enabling customization of Genero and GBC widgets within your application.

and if we look in the Theme Variable Reference, these three layers correspond to the Top Design Layer, Advanced Styling Layer, and the Genero Widget Layer.

I find it easy to understand these three layers by focusing on key example at each layer.

In the Top Design Layer, the one Theme Variable you will most likely change, and is probably the first one you change when learning about GBC Customisation is the $ui-primary-color.  You change that color away from Four Js blue to your own color.  You then expect to see that color propagated throughout your User Interface.

In the Advanced Styling Layer, if we look at the Material Field variables, and in particular Material Field Borders here we can change the border width, border color $(mt-field-border-color), border radius $(mt-field-border-radius) (rounding) for all fields.  You can make a change here that is applied to all widgets.

In the Genero Widgets layer, this is where you come to make a change specific to one widget.  So for example, for a Checkbox, this is where you would come to change the icons used for a CheckBox e.g. checked $(gbc-CheckBoxWidget-checked-icon).

With the naming convention of Theme Variables beginning “ui”, “mt”, and “gbc” for these 3 layers, remembering this will help your understanding and hopefully ensure you are looking for the right Theme Variables to use in the right place.

This naming convention also allows us to use a CSS Design methodology named BEM.

GBC widget CSS classes comply with a structured naming convention based on BEM notation.

BEM, which stands for block, element, modifier, is a methodology for naming and organizing CSS classes in a way that makes it clearer what widget each CSS class represents and how it relates to other classes.

The block represents the highest level of the widget and inside the block, there are various other elements and modifiers, which also have class names defined by the BEM notation. GBC widgets follow these naming patterns to construct CSS class names:

CSS classes such as gbc_CheckBoxWidget__box.gbc_checked comply with that convention.

Other than what is explicitly listed in the Upgrade NoteYou do not need to change anything straight away .  With theme variables that previous began with “theme”,  as per the Upgrade note …

The theme-* namespace is now deprecated. This namespace contained variables that allowed you to apply customization settings globally to the user interface (UI) and to specific widgets. It has been replaced by the ui-* namespace.

The existing theme-* variables serve as aliases for the ui-* variables, allowing you to continue using them. However, if you have customizations, feel free to update the variable names to match the new ones.

… you should plan on replacing them with what they are aliased with.