Thanks for sharing your view. Personally, I think it's perfectly valid to use native controls and base extended control design on them. In fact, this approach has clear advantages: being the most optimized in terms of CPU and memory usage. However, it's not the only path forward. What you suggest is close to what has already been explored (see for example the
test/test_md* in the BGRAControls repository).
There are various opinions and needs on the subject, and we're clearly in a complex situation with three broad directions:
- LCL and/or custom controls based on LCL (like BGRAControls, CustomDrawn…)
- Fresnel and CSS-styled controls (a hybrid approach with CSS and generated HTML)
- A subset of HTML rendering (where a window is essentially an HTML page, rather than dynamically generating HTML like Fresnel on browser)
Regarding the Fresnel project, I think it's a beautiful and ambitious idea. However, it does shift us away from the small-footprint, efficiency-focused path traditionally favored. That's fine, but it may not appeal to everyone. For example, CSS, while flexible, is not particularly efficient (parsing text with complex rules) and though Skia is a solid graphics engine, it brings a footprint of about 20 MB.
Another important factor is the state of GTK support. GTK3 remains problematic, and GTK2 is deprecated by major distributions like Debian. This puts pressure on the LCL's promise of portability. In that context, Fresnel might have better odds of success, since it only needs to handle a subset of OS features. It's good to see this project offer an alternative path.
Ultimately, none of these directions are simple. They will likely coexist for some time. The key question is where to focus our efforts. It seems that here, we lean toward the first option. To keep the project manageable, I agree with your point: we should aim for simplicity and focus on implementing only what's truly needed.
In terms of backward compatibility, it's probably best to keep BGRAControls as it is, a place to experiment with new controls. Breaking existing controls could disrupt current projects that rely on them. It's great to have a stable foundation and a sandbox for innovation.
We could create a new package for future development. But instead of rushing to replicate or import controls from BGRAControls, we should take the time to carefully design its structure. As you suggest, it's a delicate balance: keeping things simple while providing modern, expected features.
That said, we do need at least one person who can dedicate time to ensure consistency throughout the project. Personally, I don't have the bandwidth for that role. Ideally, someone who actively uses these controls in a real project would be a good candidate: they would encounter practical issues regularly and gain valuable insights from hands-on experience.
The project is feasible. A lot of the features we're aiming for are already demonstrated in BGRAControls. Shadows and gradients, for instance, are not technically difficult, we already have what's needed to render them. While we can postpone their implementation at first, we should still design with them in mind, so everything fits together coherently from the beginning.
WIKI Timeout issues
