This is great!
Opened this issue · 17 comments
Hi, I've been using this for a month now and I think it's absolutely fantastic! Zero problems, so small and so fast! As a Win32/C/C++ guy I really appreciate the lack of runtime dependencies and familiar code structure. Till now I was using JUCE but will switch as it means I can use the same LVGL code that I use on my embedded projects. Using the new Squareline Studio gives me all RAD I need to get up and running quickly before further hand coding. Please continue to develop this as I think it's really important for LVGL. Thanks.
Thank you for the kind words! Happy that you like both LVGL and SquareLine Studio!
First of all. Thank you for the kind words! I am really happy.
Please continue to develop this as I think it's really important for LVGL. Thanks.
Of course, I am trying to implement these in this project.
- Direct2D and DirectWrite support (for better performance and font rendering)
- Microsoft Active Accessibility and UI Automation support (I think accessibility is really important)
- Host LVGL contents as Win32 HWND or XAML controls for interoping with other apps (similar as the XAML Islands for Win32 desktop apps)
I am sorry for not commit this project frequently in the recent days because I have several projects needs to update. (You can navigate my GitHub page for knowing my commit activities.)
I think there are still lots of work to do for use LVGL to develop desktop applications.
@kisvegabor : I wonder to know your opinion about the minimum Windows OS support for this project.
Kenji Mouri
I wonder to know your opinion about the minimum Windows OS support for this project.
Performance-wise I think with your latest updates we are very good even with software rendering. In the longer run it'd be great to make LVGL a real option for desktop apps too. What do you think, what are the most important missing LVGL features for desktop app development?
What do you think, what are the most important missing LVGL features for desktop app development?
The most important missing LVGL features for desktop app development in the current stage I think is interoperability with other UI infrastructures. If we can support that, developers can use LVGL in some small areas first, and we can get users suggestions and add features they needed.
Because I am a Windows application developer, I will start to implement LVGL contents hosting with Win32 HWND support first. I think I will call it LVGL Islands due to Microsoft having made the XAML Islands with the similar features before. It can make developers easier to use LVGL to achieve some modern needs in their desktop applications. For example, they can implement some animations with the lightweight LVGL framework, but other things LVGL unable to achieved can still reuse their old implementations. Also, LVGL Islands can simplify and unify the Windows simulator and application port implementations.
There are still a lot of design choices I need to decide by myself when I implement LVGL Islands. I think I will create several PRs to LVGL main repository if LVGL Islands has the progress.
Kenji Mouri
but other things LVGL unable to achieved can still reuse their old implementations.
I don't really have real experience with desktop app development so I'd be very curious what are the "LVGL unable to achieve" things. Can you name a few?
Can you name a few?
As my aspect, if I want to use LVGL in my non-XAML-based Win32 projects. I think I will ask for the following items.
- Scrolling behavior should provide an option for enabling desktop style.
- Lack of accessibility support. For implement MSAA/UIA interfaces correctly LVGL should provide a way to get control tree of the display and notify the control setting changes via callback.
- Font rendering with platform infrastructure support. (FreeType is only suitable for POSIX. Windows and macOS should use the builtin infrastructure. For example, Windows should provide DirectWrite font rendering support.)
- Continue to improve the render performance. (Reuse the platform implementations. For example, GDI and Direct2D in Windows. It's hard for me to implement the LVGL draw interfaces due to lacking the detailed document about lv_draw_*_dsc_t structures.)
- Provide a theme as similar as the desktop platform. (I think I will try to port Windows 11 control styles from my Mile.Xaml toolchain to a new theme for LVGL.)
- The input method editor support still need to polish.
Kenji Mouri
So far it has coped really well with everything I've thrown at it, including huge gif files with high frame rate and a Squareline UI running at the same time (software rendering).
Two features I'd like to see:
A switch to enable a console window for printf(). I did it manually in the main cpp with:
////////////////////////////////////////////////////////////////////////////////////////////////////
if (AllocConsole()) //temporary console for printf messages
{
FILE* fi = 0;
freopen_s(&fi, "CONOUT$", "w", stdout);
}
HWND hwnd = GetConsoleWindow();
RECT rect = { 0, 0, 1200, 500 }; //set console position and size
MoveWindow(hwnd, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top, TRUE);
////////////////////////////////////////////////////////////////////////////////////////////////////
And secondly, to have the main window initially auto-size to reflect the display resolution for the lvgl project - particularly useful if using Squareline. I see that this metric isn't output in the Squareline export files but perhaps the info can be extrapolated from the layout features - plus a height offset for the windows title bar.
Kenji, I don't think it is as important to have Windows native style controls as it is to have lvgl controls respond with a windows native 'feel' - or the option for it. I think for many, the fact that it doesn't look like Windows will be an attraction. It already looks very modern with the supplied themes and has the advantage over the electron / sciter approach in that it is small, fast, compiled and genuinely integrated at the lowest reasonable level. I think many lvgl users are aware of the Windows simulator but not so much of the Windows port. Once awareness is raised and it is known that Squareline Studio can be also be used then this port will become very popular amongst embedded engineers and propagate outward from there. I think tight integration with Squareline is important even if it's just smooth interop with the export files.
A good example of a hardware product which has a rich GUI but also offers IOS and Windows 'soft' alternatives is the Elgato Stream Deck:
https://www.elgato.com/en/stream-deck
I imagine the hardware GUI was painstakingly reproduced for the software versions in QT or similar. LVGL / Windows could make this sort of job very simple and transparent since lvgl is already so well established in the embedded sphere. It could / should be the perfect bridge.
Anyway, I'm really enjoying using it with Visual Studio 2022.
May it live long and prosper.
As my aspect, if I want to use LVGL in my non-XAML-based Win32 projects. I think I will ask for the following items.
Thanks!
Scrolling behavior should provide an option for enabling desktop style.
and
The input method editor support still need to polish.
can be and should be solved in LVGL for sure.
Once awareness is raised and it is known that Squareline Studio can be also be used then this port will become very popular amongst embedded engineers and propagate outward from there.
We are thinking about adding Windows "board" support to SquareLine. I.e. allow exporting Windows projects too, similarly to Eclipse. What do you think, lv_port_windows or lv_port_win_visual_studio (or both ?) would be better to add?
In the current stage.
lv_port_windows is intended for desktop application experience with LVGL.
lv_port_win_visual_studio is intended for a standard LVGL simulator for non-desktop application developers.
Because some LVGL users don't like some non-simulator features in the simulator repository, so I told you to help me create lv_port_windows repository on that day.
I hope I can make lv_port_windows and lv_port_win_visual_studio use one implementation in the future. (For example, I provide a Win32 HWND control to users (I hope that can be in the LVGL main repository), users can set using simulator mode or desktop mode.)
Kenji Mouri
For me, lv_port_windows is more important than lv_port_win_visual_studio simulator as we already have the great sim in SQLine. But also important is that people understand the different between the two.
lv_port_windows is intended for desktop application experience with LVGL.
lv_port_win_visual_studio is intended for a standard LVGL simulator for non-desktop application developers.
But also important is that people understand the different between the two.
TBH, it wasn't obvious for me 😅
I believe a simulator should contain a few platform dependent features as possible to let LVGL work as it would an the embedded system.
TBH, it wasn't obvious for me
Here are two simple examples.
When in high dpi mode, simulator uses stretching the image from the framebuffer for making it view as the embedded system shows. But desktop port need to change the framebuffer size and act like the desktop applications.
Also, we need to disable input method in simulator mode because some one want to test their LVGL input methods for the embedded system uses. But the desktop port need to support the system's input methods.
Kenji Mouri
Got it, thank you for the explanation.
Great to see this project. Perfect options to have LVGL everywhere.
I would suggest to look at ImGui project and how the implementation is with multiple backend rendering options.
I have a sample here with ImGui+GLFW+OpenGL3
https://github.com/sukesh-ak/ImGui-GLFW-OpenGL3
This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
The Squareline Studio export to Visual Studio is working really well and it's a pleasure to use. I see that the project display dimensions are now faithfully reflected in the VC project. Fanstastic!
As mentioned in my earlier comment, a toggle for separate console debug output would be useful. This could be a project setting in SLS:
////////////////////////////////////////////////////////////////////////////////////////////////////
if (AllocConsole()) //temporary console for printf messages
{
FILE* fi = 0;
freopen_s(&fi, "CONOUT$", "w", stdout);
}
HWND hwnd = GetConsoleWindow();
RECT rect = { 0, 0, [consolw_width], [console_height] }; //set console position and size
MoveWindow(hwnd, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top, TRUE);
////////////////////////////////////////////////////////////////////////////////////////////////////
I'm lookin forward to a widget for drawing primatives in SLS. Line, Spline, Rectangle, Circle, Elipse, Fill would be great.
Also, and I'll put these suggestions to the SLS forum, a global project variable as an automation target (16bit?) which can then be used as a source for automating any widget parameter.
Thanks,
Nik