0
I Use This!
Activity Not Available

News

Analyzed about 1 month ago. based on code collected about 1 month ago.
Posted 28 days ago
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]
Posted 3 months ago
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]
Posted 5 months ago
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]
Posted 7 months ago
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]
Posted 7 months ago
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]
Posted 9 months ago
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]
Posted 9 months ago
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]
Posted about 1 year ago
After a very prolonged development cycle we finally have a new alpha release of WonderGUI! This time we have a multitude of improvements, so let’s dive straight into them. (Image by Free-Photos from Pixabay) Major graphics system update Alpha5 ... [More] has received a major upgrade to the graphics system. Large parts have been redesigned from scratch and all known outstanding issues have been addressed. This has taken a fair amount of time and effort, but has resulted in the following improvements: Vastly improved OpenGL performance GlGfxDevice has been redesigned from scratch and now manages GL states and commands much more efficiently. States are only set when necessary and similar drawing commands are queued and executed together. Although I haven’t done any benchmarking I expect there to be at least a 10x performance increase under normal use cases. Improved software rendering performance SoftGfxDevice too has been redesigned from scratch to improve performance and add features. Through some clever use of templates and compiler optimisations we now have hundreds of optimized innerloops for all commmon rendering operations. The whole pipeline has also been streamlined to avoid calculations when not needed. Pixel-perfect OpenGL/Software match The output from OpenGL and software rendering has now been tweaked to be identical. Some really minor color differences may appear in blending due to differences in precision, but these are usually not visible to the naked eye, even in a direct comparison. Support for more pixel formats In addition to 24- and 32-bit RGB surfaces, WonderGUI can now copy from 16-bit RGB, 16-bit RGBA, 8-bit alpha and 8-bit indexed surfaces. 16-bit surfaces can also be used as canvas. These formats might seem redundant for modern PCs, but can be very useful when working with small embedded systems or UIs that includes large animated widgets. Rotation and flipping In addition to stretch, we can now also rotate and flip graphics blocks. Flips and rotations in 90 degree increments can be done with none or minor performance impact in both OpenGL and software rendering, while stretch and free rotation is heavy for software rendering, but almost free for OpenGL. Even segments (previously called waves) can now be flipped and rotated in 90 degree increments. Improved API and subclassing There have been many improvements to the GfxDevice API, which now is more consistent and lean than before. Even subclassing GfxDevice requires less work than before since fewer methods needs to be implemented. This will make it faster to develop future devices for DirectX, Vulkan and Metal. Drag-n-Drop This feature has been long overdue, but WonderGUI finally has solid support for Drag-n-drop, making it way easier to implement in your product. It was designed with great care to make it both easy to add basic drag-n-drop functionality and accomodate more specific needs. My own initial use makes me believe that I reached a good balance between simplicity and flexibility. Popups The popup support has received a major overhaul and should now be fully usable. WonderGUIs way of handling menus and other popups is quite unique in that there is no need for any special menu widget or menu entry class. Everything is done using whatever widgets you prefer and a few extra calls. Skins A new MultiBlockSkin has been added, which allows you to tint and blend several images into one skin. ColorSkin has been extended to support padding and per-state-colors like BoxSkin. The old, limited ColorSkin is still available as StaticColorSkin. New create methods utilizing initializer lists have been added for all skins to allow you to define multiple states in one go. However, the most important update to skins is probably that you no longer need to define every combined state in use. I.e. if a widget enters state SelectedPressedFocused but the appearance for that state isn’t provided by the skin, the closest match will be used according to a specific formula that is better described in a separate post. Graphics Streaming In what might seem like a flashback to X-Windows on old UNIX systems, WonderGUI can now pack its drawing commands into a stream that is unpacked and replayed somewhere else with a minimum of bandwidth overhead. This is where the similarities end though, there has been no compromise to the graphics systems design to facilitate this and there is no cost in overhead (neither CPU nor memory) when not in use. It is all implemented using a special StreamGfxDevice for output and connecting a set of classes dealing with buffering, piping and playing of graphics streams. Although most of you will have no use of this, it can be very useful in certain scenarios involving embedded devices. Renaming of items and interfaces for consistency WonderGUI 3 uses composition of simple, reusable components to create complex widgets. For example is the same Text component shared by TextDisplay and Button. These components have earlier been called Items, but are now more apropriately referred to as Components. All Components now start with a capital C and the public interfaces to them (exposed by the widgets) start with a capital I. This allows them to use the most appropriate names without clashing with each other or Widgets. So now we have a TextEditor widget with an embedded CTextEditor component which is exposed through an ITextEditor interface. Don’t worry if it seems complex, it isn’t when you just use the widget :) New Widgets Although most widgets have received improvements and bugfixes during the alpha5 development cycle, only one new Widget has been added: Canvas. The Canvas widget simply provides a bitmap surface on which you can draw using a GfxDevice. Nothing especially fancy, but a very useful widget to have. General API improvements There have been many small improvements to the API. Some especially worth mentioning: You no longer need to release a widget from its parent before you can add it to another. It is now automatically released. Also, you can now use the new method releaseFromParent() instead of going through the parent when you do need to release a widget. Multiple widgets can now be added to a continer in one go using the « operator and intializer lists. This can actually make your code much more readable. Most methods of container-widgets now supports ranges when manipulating their children. You can for example hide or remove a whole range of children with one call, which is way more clean and efficient than addressing them one by one. So what’s next? Not sure yet. I have many improvements I want to tackle and circumstances will probably decide which I address first. To make WonderGUI useful to more people I will need to add some missing widgets and vastly improve the documentation. However, I’m keen on making some framework improvements first (HiDPI support being at the top of my list) since they are easier to make the less widgets I have to modify. Anyway, you can expect a much higher release rate from now on. [Less]
Posted about 1 year ago
After a very prolonged development cycle we finally have a new alpha release of WonderGUI! This time we have a multitude of improvements, so let’s dive straight into them. (Image by Free-Photos from Pixabay) Major graphics system update Alpha5 ... [More] has received a major upgrade to the graphics system. Large parts have been redesigned from scratch and all known outstanding issues have been addressed. This has taken a fair amount of time and effort, but has resulted in the following improvements: Vastly improved OpenGL performance GlGfxDevice has been redesigned from scratch and now manages GL states and commands much more efficiently. States are only set when necessary and similar drawing commands are queued and executed together. Although I haven’t done any benchmarking I expect there to be at least a 10x performance increase under normal use cases. Improved software rendering performance SoftGfxDevice too has been redesigned from scratch to improve performance and add features. Through some clever use of templates and compiler optimisations we now have hundreds of optimized innerloops for all commmon rendering operations. The whole pipeline has also been streamlined to avoid calculations when not needed. Pixel-perfect OpenGL/Software match The output from OpenGL and software rendering has now been tweaked to be identical. Some really minor color differences may appear in blending due to differences in precision, but these are usually not visible to the naked eye, even in a direct comparison. Support for more pixel formats In addition to 24- and 32-bit RGB surfaces, WonderGUI can now copy from 16-bit RGB, 16-bit RGBA, 8-bit alpha and 8-bit indexed surfaces. 16-bit surfaces can also be used as canvas. These formats might seem redundant for modern PCs, but can be very useful when working with small embedded systems or UIs that includes large animated widgets. Rotation and flipping In addition to stretch, we can now also rotate and flip graphics blocks. Flips and rotations in 90 degree increments can be done with none or minor performance impact in both OpenGL and software rendering, while stretch and free rotation is heavy for software rendering, but almost free for OpenGL. Even segments (previously called waves) can now be flipped and rotated in 90 degree increments. Improved API and subclassing There have been many improvements to the GfxDevice API, which now is more consistent and lean than before. Even subclassing GfxDevice requires less work than before since fewer methods needs to be implemented. This will make it faster to develop future devices for DirectX, Vulkan and Metal. Drag-n-Drop This feature has been long overdue, but WonderGUI finally has solid support for Drag-n-drop, making it way easier to implement in your product. It was designed with great care to make it both easy to add basic drag-n-drop functionality and accomodate more specific needs. My own initial use makes me believe that I reached a good balance between simplicity and flexibility. Popups The popup support has received a major overhaul and should now be fully usable. WonderGUIs way of handling menus and other popups is quite unique in that there is no need for any special menu widget or menu entry class. Everything is done using whatever widgets you prefer and a few extra calls. Skins A new MultiBlockSkin has been added, which allows you to tint and blend several images into one skin. ColorSkin has been extended to support padding and per-state-colors like BoxSkin. The old, limited ColorSkin is still available as StaticColorSkin. New create methods utilizing initializer lists have been added for all skins to allow you to define multiple states in one go. However, the most important update to skins is probably that you no longer need to define every combined state in use. I.e. if a widget enters state SelectedPressedFocused but the appearance for that state isn’t provided by the skin, the closest match will be used according to a specific formula that is better described in a separate post. Graphics Streaming In what might seem like a flashback to X-Windows on old UNIX systems, WonderGUI can now pack its drawing commands into a stream that is unpacked and replayed somewhere else with a minimum of bandwidth overhead. This is where the similarities end though, there has been no compromise to the graphics systems design to facilitate this and there is no cost in overhead (neither CPU nor memory) when not in use. It is all implemented using a special StreamGfxDevice for output and connecting a set of classes dealing with buffering, piping and playing of graphics streams. Although most of you will have no use of this, it can be very useful in certain scenarios involving embedded devices. Renaming of items and interfaces for consistency WonderGUI 3 uses composition of simple, reusable components to create complex widgets. For example is the same Text component shared by TextDisplay and Button. These components have earlier been called Items, but are now more apropriately referred to as Components. All Components now start with a capital C and the public interfaces to them (exposed by the widgets) start with a capital I. This allows them to use the most appropriate names without clashing with each other or Widgets. So now we have a TextEditor widget with an embedded CTextEditor component which is exposed through an ITextEditor interface. Don’t worry if it seems complex, it isn’t when you just use the widget :) New Widgets Although most widgets have received improvements and bugfixes during the alpha5 development cycle, only one new Widget has been added: Canvas. The Canvas widget simply provides a bitmap surface on which you can draw using a GfxDevice. Nothing especially fancy, but a very useful widget to have. General API improvements There have been many small improvements to the API. Some especially worth mentioning: You no longer need to release a widget from its parent before you can add it to another. It is now automatically released. Also, you can now use the new method releaseFromParent() instead of going through the parent when you do need to release a widget. Multiple widgets can now be added to a continer in one go using the « operator and intializer lists. This can actually make your code much more readable. Most methods of container-widgets now supports ranges when manipulating their children. You can for example hide or remove a whole range of children with one call, which is way more clean and efficient than addressing them one by one. So what’s next? Not sure yet. I have many improvements I want to tackle and circumstances will probably decide which I address first. To make WonderGUI useful to more people I will need to add some missing widgets and vastly improve the documentation. However, I’m keen on making some framework improvements first (HiDPI support being at the top of my list) since they are easier to make the less widgets I have to modify. Anyway, you can expect a much higher release rate from now on. [Less]
Posted about 2 years ago
If somebody happens to see this, it is only a test to verify content and layout of the automatic mailing list updater. (Image from pexels.com, CC0 Public Domain) Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor ... [More] incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. [Less]