LVGL: Boost UI With Scoped Enums For Parts & States

Jan 16, 2026 by Editorial Team 52 views

Hey guys! Ever felt like your LVGL code could use a little extra oomph? Well, buckle up, because we're diving into a super cool feature: scoped enums for parts and states! This isn't just about making your code look prettier; it's about making it safer, more intuitive, and a whole lot easier to work with. We're talking about upgrading those old-school macros, like LV_PART_MAIN and LV_STATE_PRESSED, and replacing them with the power of C++ scoped enums. Ready to level up your LVGL game? Let's get started!

The Problem: Macros and the Global Namespace

So, what's the deal with those LV_PART_... and LV_STATE_... macros? Well, they've been doing their job, but they're not exactly the bee's knees when it comes to modern C++ development. Here's why:

Type Safety: Macros are basically just text replacements. This means the compiler doesn't have a clue what type they are. You could accidentally pass the wrong macro to a function, and the compiler might not catch it until runtime. Yikes!
Global Namespace Pollution: Macros live in the global namespace, which means they can potentially clash with other names in your code. This can lead to some seriously confusing bugs that are a pain to track down.
IDE Discoverability: When you're using an IDE, it's super helpful to have features like autocompletion and code navigation. Macros don't play well with these features, making it harder to explore and understand the LVGL API.

In essence, while macros have served their purpose, they're not ideal for the type safety and code organization that modern C++ strives for. It is time to improve our LVGL experience.

The Solution: C++ Scoped Enums

Now, let's talk about the hero of our story: scoped enums! Scoped enums (also known as enum classes) are a fantastic feature of C++ that provide a much cleaner and safer way to represent a set of named constants. Here's why they're awesome:

Type Safety: Scoped enums are real types! This means the compiler will check that you're using them correctly. If you try to pass a Part to a function that expects a State, you'll get a compile-time error. No more sneaky bugs!
Namespace Isolation: Scoped enums live in their own namespace. This means you can have a Part enum and a State enum without any naming conflicts. Clean and organized!
Improved IDE Support: IDEs love scoped enums! They provide excellent autocompletion, code navigation, and other features that make your life easier.

Basically, scoped enums bring a whole lot of goodness to the table, making your code more robust, readable, and maintainable. This improvement aligns perfectly with the goals of modern C++ development.

Proposed Feature: Scoped Enums for Parts and States

Here's what the proposed feature looks like:

enum class Part { Main, Scrollbar, Indicator, Knob, ... };: This defines an enum class called Part that lists all the parts of a widget. For instance, you might have Main for the main part of a widget, Scrollbar for the scrollbar, and so on. The exact list of parts will depend on the widgets you're using.
enum class State { Default, Checked, Focused, FocusKey, Edited, Pressed, ... };: This defines an enum class called State that lists all the possible states a widget can be in. Examples include Default, Checked, Focused, Pressed, and Edited. Again, the specific states will vary depending on the widget.
Bitwise Operators for State: This is where things get really cool. We'll implement bitwise operators (like | for OR) for the State enum. This lets you combine multiple states easily. For example, if a button is both Pressed and Focused, you can represent that with State::Pressed | State::Focused.
API Updates: The LVGL API will be updated to accept these enums. So, instead of passing LV_PART_MAIN to a function, you'll pass Part::Main. This will provide the type safety and improved discoverability that we're after.

This proposed feature is all about making your LVGL code more modern, robust, and a joy to work with. It's a win-win for everyone involved!

Benefits of Using Scoped Enums

Let's break down the benefits of embracing scoped enums in LVGL:

Enhanced Type Safety: As mentioned earlier, type safety is a game-changer. It means the compiler will help you catch errors before your code even runs. This will save you countless hours of debugging and frustration. Imagine, no more accidentally passing the wrong part or state to a function! The compiler will prevent it. This alone is a massive win for code quality and reliability.
Improved Code Readability: Using scoped enums makes your code much more self-documenting. When you see Part::Main, it's immediately clear what you're referring to. No more guessing what LV_PART_MAIN actually means. This improved readability makes your code easier to understand, maintain, and collaborate on.
Reduced Namespace Pollution: Scoped enums keep your code clean and organized by avoiding the global namespace. This reduces the risk of naming conflicts and makes your code easier to reason about. You won't have to worry about macros clashing with other variables or functions in your project.
Better IDE Integration: Modern IDEs are designed to work seamlessly with scoped enums. You'll get features like autocompletion, code navigation, and refactoring support, all of which will make you a more efficient and productive developer. This improved integration will speed up your development workflow.
Easier Maintenance and Debugging: With type safety, improved readability, and better IDE support, your code will be much easier to maintain and debug. You'll be able to identify and fix errors more quickly, and you'll spend less time troubleshooting cryptic macro-related issues.
Modern C++ Best Practices: Embracing scoped enums is a step toward adopting modern C++ best practices. It shows that the LVGL project is committed to using the latest features and techniques to create high-quality code.

Implementing Bitwise Operators

One of the most powerful aspects of using scoped enums for State is the ability to combine states using bitwise operators. Let's delve into how this is achieved:

Underlying Representation: The key to implementing bitwise operators is to use an underlying integer type (typically int or uint8_t) for the enum class. Each enum value will then represent a bit or a combination of bits.
Bitwise OR (|): The bitwise OR operator is used to combine two or more states. If either bit is set in either of the operands, the corresponding bit is set in the result. For example, if State::Pressed represents the bit 0x01 and State::Focused represents the bit 0x02, then State::Pressed | State::Focused would result in 0x03, indicating that both states are active.
Bitwise AND (&): The bitwise AND operator is used to check if a particular state is active. If a bit is set in both operands, the corresponding bit is set in the result. For example, (widget.getState() & State::Pressed) != 0 would determine if the widget is currently in the Pressed state.
Bitwise NOT (~): The bitwise NOT operator is used to invert all the bits of a state. This can be useful for excluding a particular state.
Overloading Operators: To implement these operators, you'll need to overload them for the State enum class. This involves defining the behavior of each operator when used with State values. The overloaded operators will perform the bitwise operations on the underlying integer representations.

By carefully implementing these bitwise operators, you can create a highly flexible and expressive system for managing widget states. This will significantly improve the usability and power of the LVGL API.

Updating LVGL APIs

So, how do we actually integrate these scoped enums into the LVGL API? Let's take a look:

Function Signatures: The most obvious change will be in the function signatures. Instead of accepting lv_part_t or lv_state_t (which are typically integer types), functions will now accept Part and State enums, respectively. This will provide the type safety we're after. For example, a function that sets the state of a widget might change from void lv_obj_set_state(lv_obj_t *obj, lv_state_t state) to void lv_obj_set_state(lv_obj_t *obj, State state).
Internal Adaptations: Internally, the LVGL code will need to be adapted to work with the new enum types. This might involve updating existing code to use the enum values instead of the old macros. This is a crucial step to ensure everything works smoothly.
Backward Compatibility (Important Consideration): The transition to scoped enums should be done in a way that preserves backward compatibility, or at least provides a smooth migration path. This could involve providing macros that map the old macro names to the new enum values, or by using a compatibility layer that bridges the old and new APIs. Ensuring a smooth transition is crucial for existing users of the library.
Documentation and Examples: All changes should be accompanied by clear and concise documentation and examples. Developers will need to know how to use the new enums and how they relate to the old macros. Good documentation is key to a successful transition.
Testing: Thorough testing is essential to ensure that the new enums work correctly and don't introduce any regressions. Unit tests, integration tests, and user testing should be used to validate the changes.

Conclusion: The Future of LVGL Parts and States

Alright, guys, we've covered a lot of ground today! We've discussed the problems with macros, the benefits of scoped enums, the proposed feature, and how it will impact the LVGL API. Hopefully, you're as excited as I am about this upgrade! By replacing LV_PART_... and LV_STATE_... macros with C++ scoped enums, we can look forward to:

Improved Code Quality: Type safety and better code organization will lead to fewer bugs and more robust code.
Enhanced Readability: Scoped enums make your code easier to understand and maintain.
Better Developer Experience: Improved IDE support will make your coding life a breeze.
Modern C++: Aligning with modern C++ best practices.

This is a fantastic step forward for LVGL, making it even more powerful and user-friendly. So, let's embrace the future and say goodbye to those old macros! Thanks for joining me on this journey, and I hope this helps you out on your LVGL adventures. Happy coding, everyone!