Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Thu, 25 Apr 2024 07:28:44 +0000
Post From: Future planned OS platforms for SC
| [2017-12-03 22:52:56] |
| BeardPower - Posts: 51 |
|
Hi, I'm new to SC, so pardon me for reviving this thread. First and foremost, regardless of the framework, you will use in the end, there will be dragons. If you want to avoid them nearly wholly, you have to roll your own UI engine, as many developers did for their (audio) software. Are there some (useful) UI frameworks out there? Sure. Are they perfect? No, and maybe there will never be one. There are three possibilities: - use the native frameworks on each platform - use a software renderer and roll your own UI engine - use a (hardware accelerated) UI engine, which is not perfect I hope this little overview helps you in your decision making. Let's start with the central questions: - Do you want/need a C++ framework or is even a framework written in C (or a different language) okay? - Do you want/need native widgets, near-native widgets or don't you care about that? - Do you want/need to use an immediate mode or retained mode UI? - Do you want/need theming support? - Do you want/need to use vector graphics? - Do you want/need to use scripting? - Do you want/need to use different rendering backends and the latest and greatest hardware acceleration? As I read through the forum, I have the impression, that the SC team does not care about a native widget feature. If they did, they would not be that resistant to incorporate the newest, fancy flat designs the major OSs are heading. :) But, let's assume for now, that they do care. The major frameworks used, as already mentioned in previous posts, are Qt and wxWidgets. Both are not only UI frameworks, but cross-platform development frameworks, which means, that they come with a lot of features, bells and whistles (aka bloat), which SC does not need or does not even want to use, as they already implemented their own custom containers, data structures and so on. So SC only needs a pure UI engine. There are also multimedia frameworks like JUCE, SDL, SFML and Kore. Those handle graphics context creation, input handling, drawing primitives, asset rendering and much more. The difference is the number of platforms they support, features and the programming language. SDL is C, JUCE, SFML and Kore is C++, with Kore supporting the most backends (from Windows to Android to Game consoles; DX12, OpenGL (ES), Vulkan, Metal, you name it). Last, but not least, there are pure UI libraries like FLTK and NanoSVG. Qt: - C++ - near-native widgets (they do try to emulate the native widgets as best as they can, but they will never look 1:1) - retained mode - theming support - vector graphics support - scripting support - hardware acceleration based on various APIs * does not use GTK+ on Linux * licensed under different licenses (commercial and LGPL) wxWidgets: - C++ - native widgets, so they will look 1:1 - retained mode - theming support - no vector graphics support - scripting support - hardware acceleration based on OpenGL * uses GTK+ on Linux * licensed under the wxWindows Library Licence A major issue with both is that they are very bloated and eat up a lot of resources, inflate the executable in size to a vast extent and, especially Qt adds some licensing headaches. When using Open Source software, you always have to deal with licenses, which are maybe incompatible with your proprietary software, like the GPL. E.g., Qt comes with two licenses: commercial and Open Source (LGPL). When using the latter, you need to statically link the Qt libs, which maybe is something you do not want, so you need to go with the former, which adds significant costs for the developer. SDL/SFML/Kore (there is also Kha, which is implemented in Haxe and using Kore for the native backends): - C/C++ - all are just multimedia libraries, which use hardware acceleration where they can - immediate mode - not message/event based; only rendering the complete scene with x frames per second (think of a video game) - hardware acceleration based on OpenGL and other APIs (Kore supports any graphics lib; DX11/DX12, OpenGL (ES), Metal, Vulkan, etc.) - support any major platform and beyond * no dependencies (fast, small and light) * you have to use a third party UI engine/library or you draw the widgets yourself * all are licensed under the zlib/png license https://www.libsdl.org https://www.sfml-dev.org http://kha.tech / https://github.com/Kode/Kore JUCE: - C++ - non-native widgets, so they will never look 1:1 - retained mode - theming support - vector graphics support - scripting support - hardware acceleration based on OpenGL * licensed under different licenses (commercial and GPL) * it was originally developed for implementing music applications, so it also offers a great UI module https://juce.com / https://juce.com/features FLTK: - C++ - non-native widgets, so they will never look 1:1 - retained mode - no theming support - no vector graphic support - no scripting support - hardware acceleration based on OpenGL * no dependencies (fast, small and light; it only adds a few hundred kb to your executable) * licensed under the LPGL with static linking clause http://www.fltk.org NanoVG: - C - non-native widgets, so they will never look 1:1 - immediate mode - no theming support - vector graphics support (as the lib is a vector graphics rendering library base on OpenGL) - no scripting support - hardware acceleration based on OpenGL (there are also ports to other graphics APIs) * no dependencies (fast, small and light) * you have to use a third party UI engine/library or you draw the widgets yourself * licensed under the zlib license https://github.com/memononen/nanovg Alternatives, which are Open Source, have a permissive license and are tailored to be fast, have a small footprint and are doing just one thing: UI Nevertheless, the Open Source licenses maybe are incompatible with your proprietary software! There are also other UI libraries, which just call the native widget functions of the OS to draw them, but either they are missing out on some OS (Linux or macOS), are in flux, unstable or immature. Some libs, which could also be interesting for you: - libGUI (just calling the native functions of the OS) https://github.com/andlabs/libui - EFL (used by Samsung for their TizenOS) https://www.enlightenment.org/about-efl Godspeed to you for bringing a native SC to other platforms! Date Time Of Last Edit: 2017-12-03 22:56:00
|