WonderGUI

After 6 months of hard work I can finally present another release of WonderGUI. This release packs some very valuable updates to the framework, enabling sophisticated styling and advanced effects on a wide scale. Read on to know more about the ... [More] exciting new features. But first I want to say that I hav decided to keep WonderGUI in the alpha phase a bit longer since I: a) Still have not converted the Graphics layer to use MU (a WonderGUI specific way to handle screen coordinates). b) I have decided to take a second hard look on how certain classes are constructed. c) I have one more super awesome feature I would love to squeeze in for 3.0. :) These three issues are all likely to cause large changes to parts of the API and once we enter beta phase I want no more of that. Just additions and trivial changes. Anyway, let’s dive into all the exciting features of this release! :) Layered rendering This is the most exciting feature of this release. The CanvasStack widget of alpha8 was a very interesting development and it made me think in new directions when it comes to how Widgets are drawn on the screen. After some serious thoughts I decided to retire the CanvasStack and build its functionality straight into the graphics system. This took way more work than I had anticipated and I needed a second attempt before I got it right, but now it is here! Layered rendering works a bit like layers in Photoshop or GIMP. A number of layers can be created and the widgets can draw into any layers they want, which are then blended together onto the screen. One simple, but effectful way to utilize this is to create widgets with shadows and glow effects that affects surrounding widgets. I tink it is easiest to explain with an example: Let’s say we are going to create a UI that resembles an old, industrial control panel with knobs, large push buttons and lamps. We start by creating four layers: background, shadow, foreground and glow. In the background layer we draw the background of the control panel and any widgets that are flat or sunken into the background. In the foreground layer we draw knobs, levers and large buttons that stand up from the panel as well as turned on lamps that shall emit light onto background and widgets. The shadows from the knobs, levers and buttons in the foreground layer are drawn into the shadow layer. Since the shadows exist in their own layer we can use a clever combination of inverted colors and blendmodes to create shadows that don’t increase darkness when they overlap, which will look much more natural. We also avoid casting shadows on the tall widgets in the foreground layer, by blending the shadow layer onto the background before the foreground layer. Likewise, we combine the light from the lamps in the glow layer using similar techniques, preventing whiteout effects when several lamps shine on the same area. And since the glow layer is added last, it will be applied to both the background and foreground alike. The result is that the tall widgets only cast shadows onto the background, not each other or turned on lamps, and the light from the lamps combines nicely onto background and other widgets. Creating widgets with deep shadows and radient light that spreads onto surrounding widgets is just one way to use layered rendering to increase the realism of your UI. However, using layered rendering in the right way takes some skills and efforts as well as some artistic knowledge about how to combine layers to generate the effects you want. It also increases the resource usage of the application, something I intend to largely mitigate with some planned, future optimizations. The unique Skin concept of WonderGUI plays wonderfully into this, since you can define and combine several skins onto one widget, each working on a different layer. Speaking of skins, that brings us to the next most exciting feature… Animated skins and skin transitions Although the skin concept of WonderGUI always has held great promise, it was first with the previous release that we started to tap that potential when we added a large amount of skins, the functionality to combine them and gave widgets the posibility to more directly influence their skins. In this release we take it one large step further by introducing animated skins. A skin can utilize animations for just running a continous animation or make transitions between states (like a widget slowly changing color when hovered by the mouse or a checkmark gradually being drawn when selected). These kinds of transitions have been standard features of many UI Toolkits for years, so it is an area where WonderGUI has been lacking. It is therefore very pleasing to finally start closing this gap. There is still work to be done on individual skins before we can configure them to use animations the way we want, but the system to allow it is now in place, along with two skins that shows the potential. I also believe that the way this has been implemented in WonderGUI is way more flexible than in most UI Toolkits and will allow for some inovative UI effects. Metal API support Alpha9 includes a backend for using Apples Metal API for rendering. This means we now have three backends - Software, OpenGL and Metal. The Metal backend has not been tested in production yet and is likely to have bugs, but it has passed my test suite. It is also the first backend for modern rendering APIs, but I hope to be able to add support for Vulkan and DirectX in the not so distant future. Gradients All graphics backends now supports gradients. Gradients can be used for fills and tinting graphics when blitting. They can also be used to fill areas when drawing charts and such. All skins have been upgraded to support gradients, with the exception of ColorSkin and StaticColorSkin, where specific gradient skins will be provided instead. New widgets Three more widgets have been added: TooltipLayer can be used to provide tooltips in a simple and consistent way, while also allowing for a lot of customization of look and placement of individual tooltips. Just insert a TooltipLayer into your hierarchy and add tooltip strings to your widgets and see them come to life. CanvasCapsule provides a canvas for its children, allowing for off-screen buffering of parts of the UI that might be time consuming to redraw. It can also provide a separate set of layers for its canvas, allowing for layered rendering of only parts of the UI. RenderLayerCapsule can be useful if you use layered rendering. It simply allows you to switch the layer the widgets it encapsulates renders into, enabling you to not only render skins into separate layers, but also graphics drawn by the widget itself (like the text of a TextDisplay). New skins Three new skins have been added: SpinAnimSkin is a simple animated skin that continously spins a bitmap. ScrollSkin is an animated skin specifically made to support Apple-style checkboxes where a button slides left and right when selected or unselected. But it is flexible enough to probably find other uses as well. StaticGradientSkin draws a simple, static gradient. Useful for backgrounds and such. Other improvements The concept of locking and unlocking a Surface for access to its pixels turned out to be flawed and too restrictive. Instead a new concept of PixelBuffers have been introduced, which allows for more fexibility and performance improvements. Shared pointers are now threadsafe (but weak pointers are not). This allows us to safely move object between threads, although they may still only be accessed from one thread at a time. The class Origo has been renamed Placement. Makes more sense considering how it is used. BlockSkin and StaticBlockSkin now supports a “rigid part” that doesn’t scale with the rest of the skin. Support for inverting the mouse wheel has been added to support Apples “natural scroll direction”. Some simple “object tracking” feature has been added to Base. This can be used to debug memory leaks resulting from forgotten shared pointers or just to check how many objects of each type currently are alive. So, what’s next? Actually, I don’t know. The three things preventing WonderGUI from going into Beta is of course high on the agenda, but so are adding a few fundamental missing widgets. There is also a large number of small issues (papercuts) that I hope to take care of in the near future. But mostly what will be done next will depend on circumstances currently unknown. No matter what, WonderGUI will keep on improving and evolving in exciting directions! [Less]

Once again I have decided to skip a release in order to finish up some half-done development. So, instead of giving you a new release I will give you some information on what I’ve been working on for the last three months. (Work vector created by ... [More] freepik - www.freepik.com) By now you shouldn’t be too surprised to hear that I have been working on things very different from what I had planned. That seems to be a pattern in WonderGUI development, as soon as I think that the path forward is clear and I know what to work on next, some external, unforeseen event causes a reshuffle among my priorities. Two major updates, earlier planned for a post-3.0 release, are now in full development. These are: Animated Skins - The skin system now supports animated skins. Transitions from one state to another can be animated (like checkboxes having the checkmark drawn, buttons slowly fading out when disabled etc) as well can the skin as a whole (any surface can be animated). The system has been implemented but I needed a few attempts before I felt I got it right so it took quite some time. Some updates to various widgets and skins are still needed to properly support this feature throughout the system, but several widgets already supports this. Layered Rendering - This is what I’m busy working on right now. From the next release WonderGUI will support layers (like in Photoshop or GIMP) that widgets can drawn on individually, which then are blended together for display. Currently CanvasStack offers this functionality in a more limited and complex way, but from alpha-9 we should have slick, full blown support for this throughout the system. The main use for this is to enable widgets to have shadows and light effects that spills over onto nearby widgets in a natural way. Once again I needed a few attempts before I got a solution that I’m happy with. Current status is that I got it working just two days ago, but bugs are present and more classes needs to support it before it becomes useful. I will explain these features more in detail in the blog post for the next release. Additionally I have almost completed support for the Metal graphics API. It just needs some modifications to support Layered Rendering and some more extensive testing. So, for the next release, scheduled for January, you should expect at least three major updates. Maybe more if I get the time… [Less]

I’m very excited about this release! By far the largest update for years with an extensive set of updates, that truly affects the developers ability to create beautiful and useful UIs. Skipping the previous release was definitely the right choice ... [More] , cause now I can bring you a coherent and tested set of new features and improvements! We are still in the Alpha-cycle and not in the Beta-cycle as I had hoped due to one outstanding refactoring task holding us back. But the improvements all around more than makes up for it, so let me tell you about all the new, exciting features. New features in graphics system The graphics system has received a round of very exciting updates that will enable more dynamic and better looking UIs. All in all I now feel that the graphics system has reached a level of maturity and features that will enable the vision I’ve had for WonderGUI. Gamma correction - WonderGUI now properly supports gamma correction and sRGB surfaces. This allows for more correct shadows, tinting and blending. Gamma correction is free for the OpenGL renderer but quite costly for the software renderer, so it can be disabled. Gradients - Blits, fills and segments can now be tinted with a gradient. All tinting is free for the OpenGL renderer, but can get costly in software rendering (depending on specific operation). Tiling - Instead of stretching, a surface can now also be tiled across the destination rectangle. The tiled surface can also be scrolled, scaled and rotated for some funky effects. PieChart - Pie-charts can now be drawn through a simple GfxDevice api-call. These can be used not only for drawing pie charts, but are also suitable for rounded meters, knobs and spinners. A8 Canvas - An A8 surface (alpha only, 8 bits per pixel) can now be used as the Canvas. These are useful for shadow, glow and masking effects. Morphing - A new blend mode has been added: Morph. This is somewhat similar to Blend, but morphes between the source and destination (including their alpha channels) instead of blending one onto the other. Both Software and OpenGL rendering are fully up-to-date and there is no noticable difference in output. New skins and vastly improved skinning posibilities The most exciting feature of this release is probably the vast improvements to the skin system and addition of several new skins. This completely opens up new possibilites to style the widgets in advanced ways and do sophisticated things with simple widgets and powerful skins. The most interesting part is the MeterSkins, which displays values provided by the widget in various ways. This value could be the progress of a timer or progress bar, the position of a slider or knob or… anything else depending on the widget. Also the DoubleSkin and BakeSkin allows several skins to be combined in various ways, making it possible to style even the simplest widget into something very sophisticated. FillMeterSkin - A filled box that grows vertically or horizontally with the meter value. Suggested usecases include progress bars, volume meters and slider backgrounds. FrameMeterSkin - A skin that uses frame-based animations to display the meter value. Suggested usecases includes almost anything since whatever effect you want could be made as an animation. PieMeterSkin - A skin that uses the pie-chart primitive to display the meter value. Suggested usecases includes knobs, rounded timers and progressbars as well as busy-spinners. SpinMeterSkin - A skin that rotates a bitmap to display the meter value. Suggested usecases includes knobs and timers. LambdaSkin - A skin where you provide the drawing method in a Lambda function. Suggested usecase is any skin where you want to do something specific not covered by existing skins. StaticBoxSkin - A simplified, static version of BoxSkin. Suggested usecase is wherever you want a static outlined fill, like widget and window backgrounds. StaticBlockSkin - A simplified, static version of BlockSkin. Suggested usecase is wherever you want a static bitmap or nine-patch, like widget and window backgrounds. DoubleSkin - A skin that combines two skins. A front-skin is draw ontop of (and optionally inside) a back-skin. Allows for some simple combination effects. BakeSkin - A skin that bakes together two or more skins in a back-surface before blitting it to the output destination. This allows you to blend backgrounds, foregrounds, glow effects, shadows etc in creative ways for enhanced visual effects. TileSkin - A state-aware skin tiling a surface. StaticTileSkin - A simplified, static version of the above. Suggested usecases includes backgrounds. More improvements to the skin system are to be expected in the next release. I have a long list of new skins and features that I plan to add over time. New Widgets A large number of new widgets have been added. Only a handfull widgets remain before I consider WonderGUI to have a complete set of the fundamentals and therefore ready for general usage (first non-alpha/beta release). Knob - A simple widget which controls a value that you change by pressing and dragging up- and down. Combine it with a SpinMeterSkin, PieMeterSkin or FrameMeterSkin to make it look like a turning knob of your choice. Slider - A normal slider, vertical or horizontal, with a handle that you drag to change its value. RangeSlider - A slider, vertical or horizontal, with two handles so you can set a range. Timer - A simple widget which shows a countdown or similar using whichever MeterSkin you prefer. SelectBox - A simple SelectBox-widget, displaying a string and providing a pulldown menu from which to select a value. A bit primitive at the moment, can’t be controlled by keyboard and can’t have a scrollbar in the list. PianoKeyboard - A quite sophisticated widget for displaying a row of pressable piano keys. Keys can somewhat overlap for a nice 3D effect and number and order of keys can be specified. SideCanvas - This is a utility widget used by other widgets when they need to display content outside their own geometry. Used by SelectBox to display the menu. Not meant to be used directly. CanvasStack - A sophisticated widget for enabling widgets to draw in separate layers which are then blended together. Would need a complete article on its own, but allows for some really neat graphics effects. DesignLayer - This widget is just in its embryonic state, but is intended to be a tool for introspection and manipulation of the widgets in real-time. Will be gradually improved over the next several releases until it becomes useful. In additon to this, the AnimPlayer widget has received a large refactory, utilizing the same CAnimFrames component as FrameMeterSkin. Also, the RefreshButton widget has been removed since it wasn’t really used anymore and had fallen behind in its design. Future improvements to Skins will make it completely redundant. Error handling A system for catching and handling errors has been implemented. It doesn’t rely on exceptions or return values, but a user-specified callback that can do anything you want (like throw an exception, assert or just log the error). Specific information about the error including an error code, severity rating, human readable explanation and file, line and method where it occurred is provided. So far error-handling has been added to a few key areas, but several hundred more are needed to make WonderGUI a truly robust library. The goal is of course that no programmer mistake should result in confusing crashes inside WonderGUI at a later point if it can be detected. This might never be reached, but it is a worthy goal nevertheless. A catch-rate of 90-95% would still be awesome and is definitely doable over time. Other improvements A large amount of improvements and bugfixes have been done all over the place. Here is a list of the most noteworthy ones: Introspection - This release includes some very basic introspection support in that you can now see not only the class name of any wg::Object, but also iterate up through its class hierarchy. Text system MU-ified - The text system now uses the MU-coordinate system just like the widgets instead of pixels as before. TextStyle rewrite - The TextStyle class turned out to have a lot of issues, both in logic and implementation. A full rewrite was necessary. The new one is simplified - more coherent, lightweight and easier to understand. Backup fonts - A font can now specify a backup font which will be used for any glyphs missing in this font. Dataset - A template class that can be used to turn any arbitrary struct or object into a reference counted wg::Object. Baggage - Widgets and Surfaces can now carry “Baggage”, that is a pointer to any kind of wg::Object you like. The intended use is to allow you to attach meta data to your widgets and surfaces, suggestedly in the form of a Dataset or Blob. This removes the need for a separate hashmap with metadata. So, what’s next? My immediate focus will be on a graphics device for Apple’s Metal API, since I have a contract to develop it. Support for the next-gen graphics accelerators (Vulkan, DirectX and Metal) is very important for WonderGUI’s future and Metal will be the first one to be implemented. Besides this there are three areas I would like to put effort into: More widgets - Without a complete set of the fundamental widgets, WonderGUI is only useful to a subset of its potential userbase. At least three widgets needs to be added (TableList, Menubar and Tablist) and some need to be updated or improved in various ways. More skins - I’ve made a list of roughly 40 skins that would be needed to allow for all the designs and effects I have in mind. Today I have 16 of them (the 16 most important ones I would say) and most of them are not yet feature complete. Fully MU-ified framework - Currently the graphics system API (GfxDevices and Surfaces) work with pixels instead MU (measuring units), which causes some unecessary friction and confusion. I want to make it all coherent and easier to use by using MU as the unit everywhere. As mentioned at the top, I had hoped to make this release the first Beta, but after writing some new skins and widgets it became apparent that staying with pixel coordinates for the Text and Graphics APIs while everything else had been converted to the new MU-coordinates was very awkward, confusing and prone to cause bugs. Some more refactoring (that I previously wasn’t sure would be beneficial) turned out to be necessary. In this release I have converted the Text APIs to use MU, but the Graphics APIs are still on pixels. Until that is done, every WonderGUI release will be labeled Alpha. I will once again aim for a new release in 3 months, but will not shy away from skipping another release if it turns out to be the right thing to do. [Less]

I’m very excited about this release! By far the largest update for years with an extensive set of updates, that truly affects the developers ability to create beautiful and useful UIs. Skipping the previous release was definitely the right choice ... [More] , cause now I can bring you a coherent and tested set of new features and improvements! We are still in the Alpha-cycle and not in the Beta-cycle as I had hoped due to one outstanding refactoring task holding us back. But the improvements all around more than makes up for it, so let me tell you about all the new, exciting features. New features in graphics system The graphics system has received a round of very exciting updates that will enable more dynamic and better looking UIs. All in all I now feel that the graphics system has reached a level of maturity and features that will enable the vision I’ve had for WonderGUI. Gamma correction - WonderGUI now properly supports gamma correction and sRGB surfaces. This allows for more correct shadows, tinting and blending. Gamma correction is free for the OpenGL renderer but quite costly for the software renderer, so it can be disabled. Gradients - Blits, fills and segments can now be tinted with a gradient. All tinting is free for the OpenGL renderer, but can get costly in software rendering (depending on specific operation). Tiling - Instead of stretching, a surface can now also be tiled across the destination rectangle. The tiled surface can also be scrolled, scaled and rotated for some funky effects. PieChart - Pie-charts can now be drawn through a simple GfxDevice api-call. These can be used not only for drawing pie charts, but are also suitable for rounded meters, knobs and spinners. A8 Canvas - An A8 surface (alpha only, 8 bits per pixel) can now be used as the Canvas. These are useful for shadow, glow and masking effects. Morphing - A new blend mode has been added: Morph. This is somewhat similar to Blend, but morphes between the source and destination (including their alpha channels) instead of blending one onto the other. Both Software and OpenGL rendering are fully up-to-date and there is no noticable difference in output. New skins and vastly improved skinning posibilities The most exciting feature of this release is probably the vast improvements to the skin system and addition of several new skins. This completely opens up new possibilites to style the widgets in advanced ways and do sophisticated things with simple widgets and powerful skins. The most interesting part is the MeterSkins, which displays values provided by the widget in various ways. This value could be the progress of a timer or progress bar, the position of a slider or knob or… anything else depending on the widget. Also the DoubleSkin and BakeSkin allows several skins to be combined in various ways, making it possible to style even the simples widget into something very sophisticated. FillMeterSkin - A filled box that grows vertically or horizontally with the meter value. Suggested usecases include progress bars, volume meters and slider backgrounds. FrameMeterSkin - A skin that uses frame-based animations to display the meter value. Suggested usecases includes almost anything since whatever effect you want could be made as an animation. PieMeterSkin - A skin that uses the pie-chart primitive to display the meter value. Suggested usecases includes knobs, rounded timers and progressbars as well as busy-spinners. SpinMeterSkin - A skin that rotates a bitmap to display the meter value. Suggested usecases includes knobs and timers. LambdaSkin - A skin where you provide the drawing method in a Lambda function. Suggested usecase is any skin where you want to do something specific not covered by existing skins. StaticBoxSkin - A simplified, static version of BoxSkin. Suggested usecase is wherever you want a static outlined fill, like widget and window backgrounds. StaticBlockSkin - A simplified, static version of BlockSkin. Suggested usecase is wherever you want a static bitmap or nine-patch, like widget and window backgrounds. DoubleSkin - A skin that combines two skins. A front-skin is draw ontop of (and optionally inside) a back-skin. Allows for some simple combination effects. BakeSkin - A skin that bakes together two or more skins in a back-surface before blitting it to the output destination. This allows you to blend backgrounds, foregrounds, glow effects, shadows etc in creative ways for enhanced visual effects. TileSkin - A state-aware skin tiling a surface. StaticTileSkin - A simplified, static version of the above. Suggested usecases includes backgrounds. More improvements to the skin system are to be expected in the next release. I have a long list of new skins and features that I plan to add over time. New Widgets A large number of new widgets have been added. Only a handfull widgets remain before I consider WonderGUI to have a complete set of the fundamentals and therefore ready for general usage (first non-alpha/beta release). Knob - A simple widget which controls a value that you change by pressing and dragging up- and down. Combine it with a SpinMeterSkin, PieMeterSkin or FrameMeterSkin to make it look like a turning knob of your choice. Slider - A normal slider, vertical or horizontal, with a handle that you drag to change its value. RangeSlider - A slider, vertical or horizontal, with two handles so you can set a range. Timer - A simple widget which shows a countdown or similar using whichever MeterSkin you prefer. SelectBox - A simple SelectBox-widget, displaying a string and providing a pulldown menu from which to select a value. A bit primitive at the moment, can’t be controlled by keyboard and can’t have a scrollbar in the list. PianoKeyboard - A quite sophisticated widget for displaying a row of pressable piano keys. Keys can somewhat overlap for a nice 3D effect and number and order of keys can be specified. SideCanvas - This is a utility widget used by other widgets when they need to display content outside their own geometry. Used by SelectBox to display the menu. Not meant to be used directly. CanvasStack - A sophisticated widget for enabling widgets to draw in separate layers which are then blended together. Would need a complete article on its own, but allows for some really neat graphics effects. DesignLayer - This widget is just in its embryonic state, but is intended to be a tool for introspection and manipulation of the widgets in real-time. Will be gradually improved over the next several releases until it becomes useful. In additon to this, the AnimPlayer widget has received a large refactory, utilizing the same CAnimFrames component as FrameMeterSkin. Also, the RefreshButton widget has been removed since it wasn’t really used anymore and had fallen behind in its design. Future improvements to Skins will make it completely redundant. Error handling A system for catching and handling errors has been implemented. It doesn’t rely on exceptions or return values, but a user-specified callback that can do anything you want (like throw an exception, assert or just log the error). Specific information about the error including an error code, severity rating, human readable explanation and file, line and method where it occurred is provided. So far error-handling has been added to a few key areas, but several hundred more are needed to make WonderGUI a truly robust library. The goal is of course that no programmer mistake should result in confusing crashes inside WonderGUI at a later point if it can be detected. This might never be reached, but it is a worthy goal nevertheless. A catch-rate of 90-95% would still be awesome and is definitely doable over time. Other improvements A large amount of improvements and bugfixes have been done all over the place. Here is a list of the most noteworthy ones: Introspection - This release includes some very basic introspection support in that you can now see not only the class name of any wg::Object, but also iterate up through its class hierarchy. Text system MU-ified - The text system now uses the MU-coordinate system just like the widgets instead of pixels as before. TextStyle rewrite - The TextStyle class turned out to have a lot of issues, both in logic and implementation. A full rewrite was necessary. The new one is simplified - more coherent, lightweight and easier to understand. Backup fonts - A font can now specify a backup font which will be used for any glyphs missing in this font. Dataset - A template class that can be used to turn any arbitrary struct or object into a reference counted wg::Object. Baggage - Widgets and Surfaces can now carry “Baggage”, that is a pointer to any kind of wg::Object you like. The intended use is to allow you to attach meta data to your widgets and surfaces, suggestedly in the form of a Dataset or Blob. This removes the need for a separate hashmap with metadata. So, what’s next? My immediate focus will be on a graphics device for Apple’s Metal API, since I have a contract to develop it. Support for the next-gen graphics accelerators (Vulkan, DirectX and Metal) is very important for WonderGUI’s future and Metal will be the first one to be implemented. Besides this there are three areas I would like to put effort into: More widgets - Without a complete set of the fundamental widgets, WonderGUI is only useful to a subset of its potential userbase. At least three widgets needs to be added (TableList, Menubar and Tablist) and some need to be updated or improved in various ways. More skins - I’ve made a list of roughly 40 skins that would be needed to allow for all the designs and effects I have in mind. Today I have 16 of them (the 16 most important ones I would say) and most of them are not yet feature complete. Fully MU-ified framework - Currently the graphics system API (GfxDevices and Surfaces) work with pixels instead MU (measuring units), which causes some unecessary friction and confusion. I want to make it all coherent and easier to use by using MU as the unit everywhere. As mentioned at the top, I had hoped to make this release the first Beta, but after writing some new skins and widgets it became apparent that staying with pixel coordinates for the Text and Graphics APIs while everything else had been converted to the new MU-coordinates was very awkward, confusing and prone to cause bugs. Some more refactoring (that I previously wasn’t sure would be beneficial) turned out to be necessary. In this release I have converted the Text APIs to use MU, but the Graphics APIs are still on pixels. Until that is done, every WonderGUI release will be labeled Alpha. I will once again aim for a new release in 3 months, but will not shy away from skipping another release if it turns out to be the right thing to do. [Less]

The next release should have been due in April, but after some delays I have decided to skip this release and focus on the next one, due in July. It is easy to assume that this is caused by lack of progress, but nothing could be further from the ... [More] truth. Let me tell you a bit about the current state of WonderGUI. (Work vector created by freepik - www.freepik.com) The priorities of WonderGUI development is largely driven by client requests. When starting a new release cycle I often have a specific plan and list of features to work on, but only weeks later I find myself work on completely different areas. This can at times be frustrating, but is also a blessing. My clients have often turned out to be my greatest asset. Not only do they provide me the economic means to continue WonderGUI development, their feedback and feature requests often leads to totally unplanned, but very vaulable improvements. They actually drive WonderGUI development in directions I wouldn’t have thought of myself, making WonderGUI, in my opinion, a more unique and exciting offering among all other UI Toolkits. This spring has been very intense in that way. My plan was to add some missing standard widgets to make WonderGUI usable to a more wide audience, but instead I have found myself mainly work on some very exciting improvements to the GfxSystem and some innovative improvements on widget skinning. On top of that we have a few new widgets (but not the ones I had in mind), a unique way of rendering in layers and the start of a live UI-introspector/editor. Unfortunately, only a few of these improvements are in a state that I would be comfortable to release them in. So instead of rolling back most of the development and spend a few days putting together and testing a new release, I decided to just keep moving forward as quickly as I can in order to bring it all into the next release. All in all, this refocus will delay the release of 3.0 by about 6 months, but I believe it will be a much more compelling release, making the wait worthwhile. Personally, feel very excited about the next release! :) [Less]

WonderGUI is now formally backed by an incorporated entity! Nordic UI Technologies AB is the name of the company that now has been formed to be the commercial entity backing the WonderGUI project. (City photo created by wirestock - www.freepik.com) ... [More] Nordic UI Technologies AB is fully owned and operated by Tord Jansson, the creator of WonderGUI, so this does not change the direction or structure of the project as such. But as a properly incorporated entity we are now better prepared for a future expansion, providing technology and services to more clients. With the looming release of WonderGUI 3.0 (this or next year) we felt it was about time to strengthen our commercial structure. Nordic UI Technologies AB replaces Lushcode, a sole proprietorship earlier run by Tord Jansson, as the business entity in all licensing, consulting and support related matters. [Less]

With this release we are probably seeing the end of the alpha-cycle. I have made major improvements to how child widgets are added, handled and accessed. With that, the whole framework now works and behaves much the way I envisioned several years ... [More] ago. Read on to know more. (Picture by TheDigitalArtist@Pixabay) First of all I must say that I’m quite happy with the pace of development I’ve kept the last few months, resulting in a release with two major improvements only two months after the previous one. So, let me tell you a little about these two improvements, starting with the easiest one. R.I.P Interfaces The Component/Interface system is essentially a framework within the framework. Components are reusable building blocks for widgets and Interfaces are used to expose parts of the components methods to the world outside the widget. I’ve never been fully pleased with the need for a separate Interface class, so I took a second hard look and found a better way. The result is a lot of internal code cleanup and removal of a dozen unnecessary classes. For the user of the framework there isn’t much of a change except that the prefix of the classes has changed (CTextDisplay instead of ITextDisplay etc), unless you write your own widgets, which now should be a bit easier and cleaner. Major slot-system refactoring The concept of slots is unique to WonderGUI and has been a bit experimental. Essentially, a slot is a place to put a child widget in a container widget. Some containers have one or more fixed slots, restricting the number of children, while others dynamically allocate slots as needed. The purpose of the slot, except for holding a pointer to the child widget, is to provide easy access to all the parameters the container offers to control the layout and presentation of the child. Previously you needed to call a method with a reference to the slot (index or interator) in order to manipulate it, but now the slot itself contains all the relevant methods. So, in order to hide the third child in a PackPanel you can now do: pWidget->slots[2].hide(); Very straight forward, isn’t it? You can also do the same thing with an interator pointing at the slot: (*it).hide(); Please note that you need to precede the iterator with an asterisk and enclose it in parentheses. Otherwise you access methods provided by the iterator itself instead of the slot. To access methods in the widget, you still use the -> operator as before: pWidget->slots[2]->id(); Using either -> or . depending on if you want to call the childs methods or the parents methods (for controlling the childs presentation) might need a little getting used to, but makes a lot of sense and makes things very smooth in the end. The container still provides methods for changing several slots at once, so if you want to hide 5 children starting with child 3, you can still do this: pWidget->slots.hide( 2, 5 ); // Note, index starts at 0. There are still a few tweaks and improvements to the slot system that didn’t make it into this release, but essentially it is now there. Widget resizing improvements Resizing individual widgets can easily create cascading effects in complex, dynamic layouts. This can result in deep, recursive calls that heavily tax the CPU.quickly get very CPU taxing. Alpha 7 has had some minor, but important changes to how widgets request resize and how parents are expected to respond, allowing for far more efficient handling in the future. Bugfixes and other minor changes A few dozen bugs have been fixed all over the place, improving stability, consistency and performance. Documentation has also been improved in certain areas. So, what’s next? With this release, the last of the planned framework refactoring has been completed. A more comprehensive error handling framework will still need to be implemented, but that is not expected to cause any major API changes. I therefore expect the next release to be the first beta. I plan to shift my focus towards the individual widgets, improving and updating the existing ones and adding new ones to make the framework complete. Beyond that I will spend much more time testing, debugging and writing documentation. [Less]

With this release we are probably seeing the end of the alpha-cycle. I have made major improvements to how child widgets are added, handled and accessed. With that, the whole framework now works and behaves much the way I envisioned several years ... [More] ago. Read on to know more. (Picture by TheDigitalArtist@Pixabay) First of all I must say that I’m quite happy with the pace of development I’ve kept the last few months, resulting in a release with two major improvements only two months after the previous one. So, let me tell you a little about these two improvements, starting with the easiest one. R.I.P Interfaces The Component/Interface system is essentially a framework within the framework. Components are reusable building blocks for widgets and Interfaces are used to expose parts of the components methods to the world outside the widget. I’ve never been fully pleased with the need for a separate Interface class, so I took a second hard look and found a better way. The result is a lot of internal code cleanup and removal of a dozen unnecessary classes. For the user of the framework there isn’t much of a change except that the prefix of the classes has changed (CTextDisplay instead of ITextDisplay etc), unless you write your own widgets, which now should be a bit easier and cleaner. Major slot-system refactoring The concept of slots is unique to WonderGUI and has been a bit experimental. Essentially, a slot is a place to put a child widget in a container widget. Some containers have one or more fixed slots, restricting the number of children, while others dynamically allocate slots as needed. The purpose of the slot, except for holding a pointer to the child widget, is to provide easy access to all the parameters the container offers to control the layout and presentation of the child. Previously you needed to call a method with a reference to the slot (index or interator) in order to manipulate it, but now the slot itself contains all the relevant methods. So, in order to hide the third child in a PackPanel you can now do: pWidget->slots[2].hide(); Very straight forward, isn’t it? You can also do the same thing with an interator pointing at the slot: (*it).hide(); Please note that you need to precede the iterator with an asterisk and enclose it in parentheses. Otherwise you access methods provided by the iterator itself instead of the slot. To access methods in the widget, you still use the -> operator as before: pWidget->slots[2]->id(); Using either -> or . depending on if you want to call the childs methods or the parents methods (for controlling the childs presentation) might need a little getting used to, but makes a lot of sense and makes things very smooth in the end. The container still provides methods for changing several slots at once, so if you want to hide 5 children starting with child 3, you can still do this: pWidget->slots.hide( 2, 5 ); // Note, index starts at 0. There are still a few tweaks and improvements to the slot system that didn’t make it into this release, but essentially it is now there. Widget resizing improvements Resizing individual widgets can easily create cascading effects in complex, dynamic layouts. This can result in deep, recursive calls that heavily tax the CPU.quickly get very CPU taxing. Alpha 7 has had some minor, but important changes to how widgets request resize and how parents are expected to respond, allowing for far more efficient handling in the future. Bugfixes and other minor changes A few dozen bugs have been fixed all over the place, improving stability, consistency and performance. Documentation has also been improved in certain areas. So, what’s next? With this release, the last of the planned framework refactoring has been completed. A more comprehensive error handling framework will still need to be implemented, but that is not expected to cause any major API changes. I therefore expect the next release to be the first beta. I plan to shift my focus towards the individual widgets, improving and updating the existing ones and adding new ones to make the framework complete. Beyond that I will spend much more time testing, debugging and writing documentation. [Less]

After a much shorter development cycle than last time, but longer than I aimed for, here is Alpha6! This release packs a very valuable new feature that affects the whole framework, so read on to know more. (Picture by Stephen Edmonds,CC-BY-SA 2.) ... [More] UI Scaling The main feature for this release is UI scaling. WonderGUI now fully supports scaling of the entire UI in increments of 25% (100%, 125% 150%, 175%, 200% and so on). This was my third attempt to add scaling to WonderGUI. My first attempt was badly thought through and abandoned half-way through development when the problems became apparent. My second attempt is currently implemented in WG2 (WonderGUI version 2, which is still maintained and used). It works decently but had a number of drawbacks, most notably an API with duplicate methods for setting/getting geometry in points vs pixels and inconsistencies when converting geometry back and forth between those two units. With this third attempt I believe I have a solution with an almost seamless API, good performance and minimal problems with inconsistencies during unit conversion. Hopefully it just works for most of you without even giving the relationship of points and pixels any thought. The magic ingredient is a new primitive called QPix (short for quarter pixels), which keeps the value internally in quarters of a pixel, but seamlessly converts to points when accessing it. I won’t dive into details here, I’ll explain it in a separate blog post when I get the time. For those who want to try it out, you simply create a Context, set its scaling and call wg::Base::setActiveContext(). Currently the scaling is limited to the same scale factor for the whole UI and can’t be dynamically changed at runtime. To change the scale factor you will need to throw away all your widgets, change the scale factor and rebuild the UI. Other components such as Skins, Fonts and TextStyles are not affected and can be kept as they are. These limitations are not inherent to the solution and will be addressed in a future update, but are not prioritized right now. Also, in case somebody didn’t understand it: This is proper scaling of the UI, not rendering to a backbuffer and then just scaling the bitmap. Fonts and edges remains super clear with no blurring and performance is unaffected by the scale factor. Improvements to graphics system There has been several improvements to the graphics system in this release: BlitSource clipping SoftGfxDevice has now the intelligence to avoid reading pixels outside the source surface. This makes rotScaleBlit() so much more useful, opening the door to all kinds of widgets and effects where graphics is rotated. Before this you either had to stick to OpenGL rendering or make sure that you had enough pixels between the block to be rotated and the edges of the blit source. MipMap support (OpenGL only) GlGfxDevice can now take advantage of mipmaps when scaling down graphics, resulting in better output quality. Mipmapping is enabled on a per-surface basis and needs to be decided when surface is created by setting a flag. The cost is 33% more memory for the surface to hold the mipmaps and degraded performance when unlocking, copying or rendering to the surface. Software rendering ignores this flag. New blend modes Two new blend modes have been added: Min and Max. Min results in the lowest value of source and destination for each channel (R, G, B and A) being written. Max is the opposite. These are rarely used but are needed to generate shadows that can overlap each other without artifacts (coming feature). Alpha only canvas Alpha-only surfaces can now be used as canvas. There might be many uses for this, but my main goal was to save memory and increase performance when dealing with caching of shadows and vector fonts. For this release though, they both still use 32-bit RGBA surfaces. Output consistency improvements A lot of effort has been made to make the output of the OpenGL and software renderer consistent. A few extreme test cases still produce slightly different result, but in most cases the output is identical. I have also noticed some minor variations caused by differences in OpenGL implementation between vendors. But for all practical purposes, the output should now be identical. New, updated and removed widgets A ShadowLayer-widget has been created, but was pulled from this release and will be reintroduced later after some refactoring. The Oscilloscope widget has been removed. It was hardly used and since it will become redundant once I port the much better Chart-widget from WG2, I couldn’t justify the effort to maintain it through the latest round of framework refactorings. SizeCapsule is currently a work in progress since it was discovered to not handle all situations correctly, but the refactoring work was interrupted. It should work fine for most normal cases, but treat it with some suspicion until the next alpha. Bugfixes and other minor changes A few dozen bugs have been fixed all over the place, improving stability, consistency and performance. So, what’s next? What will come next is not set in stone. I will adapt my plans to cater to the people who already use and are depending on WonderGUI and they have been hinting about interest in more graphics backends, so that is a hot candidate. There are also a number of new widgets and features in WG2 that I would like to bring over, and are necessary to eventually migrate current users from WG2. Anyway, you should expect the next release to contain some new widgets. With most other things in place, a complete set of common base widgets is now what is most lacking in WonderGUI 3. Something I intend to address over the next few releases. [Less]

After a much shorter development cycle than last time, but longer than I aimed for, here is Alpha6! This release packs a very valuable new feature that affects the whole framework, so read on to know more. (Picture by Stephen Edmonds,CC-BY-SA 2.) ... [More] UI Scaling The main feature for this release is UI scaling. WonderGUI now fully supports scaling of the entire UI in increments of 25% (100%, 125% 150%, 175%, 200% and so on). This was my third attempt to add scaling to WonderGUI. My first attempt was badly thought through and abandoned half-way through development when the problems became apparent. My second attempt is currently implemented in WG2 (WonderGUI version 2, which is still maintained and used). It works decently but had a number of drawbacks, most notably an API with duplicate methods for setting/getting geometry in points vs pixels and inconsistencies when converting geometry back and forth between those two units. With this third attempt I believe I have a solution with an almost seamless API, good performance and minimal problems with inconsistencies during unit conversion. Hopefully it just works for most of you without even giving the relationship of points and pixels any thought. The magic ingredient is a new primitive called QPix (short for quarter pixels), which keeps the value internally in quarters of a pixel, but seamlessly converts to points when accessing it. I won’t dive into details here, I’ll explain it in a separate blog post when I get the time. For those who want to try it out, you simply create a Context, set its scaling and call wg::Base::setActiveContext(). Currently the scaling is limited to the same scale factor for the whole UI and can’t be dynamically changed at runtime. To change the scale factor you will need to throw away all your widgets, change the scale factor and rebuild the UI. Other components such as Skins, Fonts and TextStyles are not affected and can be kept as they are. These limitations are not inherent to the solution and will be addressed in a future update, but are not prioritized right now. Also, in case somebody didn’t understand it: This is proper scaling of the UI, not rendering to a backbuffer and then just scaling the bitmap. Fonts and edges remains super clear with no blurring and performance is unaffected by the scale factor. Improvements to graphics system There has been several improvements to the graphics system in this release: BlitSource clipping SoftGfxDevice has now the intelligence to avoid reading pixels outside the source surface. This makes rotScaleBlit() so much more useful, opening the door to all kinds of widgets and effects where graphics is rotated. Before this you either had to stick to OpenGL rendering or make sure that you had enough pixels between the block to be rotated and the edges of the blit source. MipMap support (OpenGL only) GlGfxDevice can now take advantage of mipmaps when scaling down graphics, resulting in better output quality. Mipmapping is enabled on a per-surface basis and needs to be decided when surface is created by setting a flag. The cost is 33% more memory for the surface to hold the mipmaps and degraded performance when unlocking, copying or rendering to the surface. Software rendering ignores this flag. New blend modes Two new blend modes have been added: Min and Max. Min results in the lowest value of source and destination for each channel (R, G, B and A) being written. Max is the opposite. These are rarely used but are needed to generate shadows that can overlap each other without artifacts (coming feature). Alpha only canvas Alpha-only surfaces can now be used as canvas. There might be many uses for this, but my main goal was to save memory and increase performance when dealing with caching of shadows and vector fonts. For this release though, they both still use 32-bit RGBA surfaces. Output consistency improvements A lot of effort has been made to make the output of the OpenGL and software renderer consistent. A few extreme test cases still produce slightly different result, but in most cases the output is identical. I have also noticed some minor variations caused by differences in OpenGL implementation between vendors. But for all practical purposes, the output should now be identical. New, updated and removed widgets A ShadowLayer-widget has been created, but was pulled from this release and will be reintroduced later after some refactoring. The Oscilloscope widget has been removed. It was hardly used and since it will become redundant once I port the much better Chart-widget from WG2, I couldn’t justify the effort to maintain it through the latest round of framework refactorings. SizeCapsule is currently a work in progress since it was discovered to not handle all situations correctly, but the refactoring work was interrupted. It should work fine for most normal cases, but treat it with some suspicion until the next alpha. Bugfixes and other minor changes A few dozen bugs have been fixed all over the place, improving stability, consistency and performance. So, what’s next? What will come next is not set in stone. I will adapt my plans to cater to the people who already use and are depending on WonderGUI and they have been hinting about interest in more graphics backends, so that is a hot candidate. There are also a number of new widgets and features in WG2 that I would like to bring over, and are necessary to eventually migrate current users from WG2. Anyway, you should expect the next release to contain some new widgets. With most other things in place, a complete set of common base widgets is now what is most lacking in WonderGUI 3. Something I intend to address over the next few releases. [Less]