![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
GUI library design
Feb. 20th, 2019 09:57 amSome of the C graphics libraries are great, but I've yet to find a simple GUI that makes it easy to port some older BASIC programs that I want to be able to keep working with. I've created several iterations of my own GUI library, but have never been satisfied with the results. That's the main reason I keep investigating cross-platform GUIs, to see if someone's found a better way to do it. Of the various designs, the ideas behind the immediate mode GUIs seem the most useful for the type of programs I'm targeting. However, I can't seem to find one GUI library that provides a simple way to do what I want. So, I've decided to revisit my old GUI library designs but eliminate some of the framework constraints and some of the object oriented elements. Instead, I'm looking at a more procedural approach that uses concepts from immediate mode GUIs.
Even though I'm avoiding popular C/C++ GUI libraries, I'm not starting completely from scratch and writing everything myself. There are plenty of good graphics libraries that are very portable and make a great basic starting point for a GUI. One of the libraries I've been very impressed with is SDL. It makes a great base for porting software. I've also done a lot of work with PicoGL (a TinyGL fork). It's a convenient way to make OpenGL more portable and avoid some of the version issues. It works on low resource platforms such as handheld devices that don't have high performance video driver support. I've often found OpenGL and Mesa slow on older computers and low resource systems. PicoGL provides very good performance on these types of systems. While using Win32 is not as portable as I would like, it's not that hard to get an OpenGL window up and running on Win32. That easily allows switching between Win32/OpenGL and SDL (1.2.15 or SDL 2.x)/PicoGL. SDL can work on a variety of platforms and PicoGL can work with SDL or with other options such as nano-x, X11 or vesa framebuffer. It shouldn't be too hard to take the output from PicoGL to use with the Android bitmap API either. Another possible option for a backend is Allegro. Like SDL, it works on a variety of platforms. It would be nice to switch between SDL and Allegro as backends depending on which works best for a particular platform without needing to redesign an entire application.
The PDCurses/ncurses API provides a standard way to create console based programs that work well on a variety of platforms from DOS to Windows to FreeBSD to Linux. However, it provides only text support and no real graphics support. While it's great for porting programs written to work with it, I don't think it's the best option to use as a GUI backend. I recently came across TinyCurses which provides a subset of the API and uses SDL as a backend. PDCurses also offers SDL as a backend option. I couldn't help thinking, once a decent GUI design was finalized, it wouldn't be too hard to provide a subset of functionality similar to PDCurses/ncurses. That would allow for easy porting of some PDCurses/ncurses based applications to any platform the GUI library works on.
So, why not just use OpenGL as the backend to design a GUI library? After considering the pros and cons, I decided I don't want to be tied specifically to OpenGL as an API for 2D graphics. While it's very popular and available on several platforms, the changes from a fixed function pipeline to a programmable pipeline with its own shading language make it hard to port programs from one version to another. PicoGL makes use of old fixed function pipeline concepts. Windows OpenGL also uses the older design. Mobile devices and WebGL make use of the newer concepts and the ability to harness the GPU to do more processing. Many developers seem to be abandoning the older concepts and embracing the new programmable pipeline design. However, that leaves some nice older applications that were designed for earlier versions of OpenGL that won't port easily to the newer versions. They might require a complete redesign and rewrite. Using PicoGL is one way to make it easier to port such applications. It can do software rendering to a bitmap which can then use more modern methods (including later versions of OpenGL or SDL 2.x) to transfer the bitmap to the screen. While the idea of using OpenGL as the portable backend for a GUI library sounds good, dealing with version differences and what versions may be available on which platforms does not make it the best option for a complete cross-platform portable solution. Instead, I prefer the concept of being able to switch out backends to use what works well on a particular platform. The GUI library should encapsulate the rendering as much as possible to avoid needing to rewrite applications in order to switch to another backend.
On the other hand, many GUI libraries and some other rendering libraries (such as SDL) offer ways to interoperate with a graphics library like OpenGL. While I want my GUI library code to be cross-platform, I don't want to limit a developer to using just that API. If a programmer wants to use OpenGL or SDL2_gfx or some other library to handle 2D/3D graphics, I'd like the GUI to be able to interoperate with that choice. It would mean that the resulting application would be less portable. However, if an application is already designed to utilize SDL2_gfx, OpenGL or some other library that could work compatibly with the GUI library, it could make adding some GUI functionality to an existing application much easier.
I definitely know what I'm looking for in a cross-platform GUI. I want a simple, portable way to get text, menus, forms, file/directory picker dialog functionality to the screen. I'd like to make use of Freetype fonts. I want an internationalized way to display text and for users to input text. The text strings will probably involve a library such as gettext. I want the options to use keyboard input for those of us who prefer keyboard commands to get their work done and mouse/touchscreen input for devices such as mobile phones where a real keyboard may not be available. I need to be able to access graphics and audio information from a file system or from a zipped file (such as .apk file on Android). I don't care if the look and feel matches what's in style for a particular device or operating system. I just want it to be user-friendly and ergonomically designed.
If you're interested in GUI design or working on a GUI or gaming library of your own, I'd love to compare notes on the subject. Have an idea for what C library might make a good backend for a portable, cross-platform C based GUI? Let me know. Feel free to discuss design issues or other C/C++ topics on the CppDesign mailing list or contact me to compare design notes and share ideas ( http://www.distasis.com/connect.htm ).
Even though I'm avoiding popular C/C++ GUI libraries, I'm not starting completely from scratch and writing everything myself. There are plenty of good graphics libraries that are very portable and make a great basic starting point for a GUI. One of the libraries I've been very impressed with is SDL. It makes a great base for porting software. I've also done a lot of work with PicoGL (a TinyGL fork). It's a convenient way to make OpenGL more portable and avoid some of the version issues. It works on low resource platforms such as handheld devices that don't have high performance video driver support. I've often found OpenGL and Mesa slow on older computers and low resource systems. PicoGL provides very good performance on these types of systems. While using Win32 is not as portable as I would like, it's not that hard to get an OpenGL window up and running on Win32. That easily allows switching between Win32/OpenGL and SDL (1.2.15 or SDL 2.x)/PicoGL. SDL can work on a variety of platforms and PicoGL can work with SDL or with other options such as nano-x, X11 or vesa framebuffer. It shouldn't be too hard to take the output from PicoGL to use with the Android bitmap API either. Another possible option for a backend is Allegro. Like SDL, it works on a variety of platforms. It would be nice to switch between SDL and Allegro as backends depending on which works best for a particular platform without needing to redesign an entire application.
The PDCurses/ncurses API provides a standard way to create console based programs that work well on a variety of platforms from DOS to Windows to FreeBSD to Linux. However, it provides only text support and no real graphics support. While it's great for porting programs written to work with it, I don't think it's the best option to use as a GUI backend. I recently came across TinyCurses which provides a subset of the API and uses SDL as a backend. PDCurses also offers SDL as a backend option. I couldn't help thinking, once a decent GUI design was finalized, it wouldn't be too hard to provide a subset of functionality similar to PDCurses/ncurses. That would allow for easy porting of some PDCurses/ncurses based applications to any platform the GUI library works on.
So, why not just use OpenGL as the backend to design a GUI library? After considering the pros and cons, I decided I don't want to be tied specifically to OpenGL as an API for 2D graphics. While it's very popular and available on several platforms, the changes from a fixed function pipeline to a programmable pipeline with its own shading language make it hard to port programs from one version to another. PicoGL makes use of old fixed function pipeline concepts. Windows OpenGL also uses the older design. Mobile devices and WebGL make use of the newer concepts and the ability to harness the GPU to do more processing. Many developers seem to be abandoning the older concepts and embracing the new programmable pipeline design. However, that leaves some nice older applications that were designed for earlier versions of OpenGL that won't port easily to the newer versions. They might require a complete redesign and rewrite. Using PicoGL is one way to make it easier to port such applications. It can do software rendering to a bitmap which can then use more modern methods (including later versions of OpenGL or SDL 2.x) to transfer the bitmap to the screen. While the idea of using OpenGL as the portable backend for a GUI library sounds good, dealing with version differences and what versions may be available on which platforms does not make it the best option for a complete cross-platform portable solution. Instead, I prefer the concept of being able to switch out backends to use what works well on a particular platform. The GUI library should encapsulate the rendering as much as possible to avoid needing to rewrite applications in order to switch to another backend.
On the other hand, many GUI libraries and some other rendering libraries (such as SDL) offer ways to interoperate with a graphics library like OpenGL. While I want my GUI library code to be cross-platform, I don't want to limit a developer to using just that API. If a programmer wants to use OpenGL or SDL2_gfx or some other library to handle 2D/3D graphics, I'd like the GUI to be able to interoperate with that choice. It would mean that the resulting application would be less portable. However, if an application is already designed to utilize SDL2_gfx, OpenGL or some other library that could work compatibly with the GUI library, it could make adding some GUI functionality to an existing application much easier.
I definitely know what I'm looking for in a cross-platform GUI. I want a simple, portable way to get text, menus, forms, file/directory picker dialog functionality to the screen. I'd like to make use of Freetype fonts. I want an internationalized way to display text and for users to input text. The text strings will probably involve a library such as gettext. I want the options to use keyboard input for those of us who prefer keyboard commands to get their work done and mouse/touchscreen input for devices such as mobile phones where a real keyboard may not be available. I need to be able to access graphics and audio information from a file system or from a zipped file (such as .apk file on Android). I don't care if the look and feel matches what's in style for a particular device or operating system. I just want it to be user-friendly and ergonomically designed.
If you're interested in GUI design or working on a GUI or gaming library of your own, I'd love to compare notes on the subject. Have an idea for what C library might make a good backend for a portable, cross-platform C based GUI? Let me know. Feel free to discuss design issues or other C/C++ topics on the CppDesign mailing list or contact me to compare design notes and share ideas ( http://www.distasis.com/connect.htm ).
![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}