"Vector" scalability of the whole UI

[dumblob]

Is there any simple way to scale the whole UI in a "vector" way (i.e. not scaling the resulting bitmap, but every single part of the UI separately in a consistent way)? I found just several scaling options, but only for some containers (e.g. panel).

Without scaling, the whole UI is currently not suitable for many deployments (high-res displays of wildly varying sizes - e.g. 5" mobile devices having higher resolution than my 15.4" notebook display).

Also, the sizes differ in the pixel shapes etc., so a separate scaling factor for x and y would be much better than just one common scaling factor.

[vurtun]

Hey, thanks for your feedback! I have to admit that I up to this point did not think about this issue which is a failure on my part, so thank you for bringing it up. I am currently working on panel popups and combo boxes so scaling will be the next big issue I will tackle. But I am currently not completely sure about the general understanding and the extend of the needed changes. As far as I understand scaling is by this article http://docs.unity3d.com/Manual/HOWTO-UIMultiResolution.html which mainly talks about widget placement in different resolutions with anchors. So if I understand correctly is that you basically build a UI with a number of panels at certain positions on the screen in a given base resolution and want the complete UI to be scaleable to any other resolution even with resolutions with a different screen ratio? In addition does this include the widgets (position, width and height) and font height as well? So either way I probably have to dig deeper since the needed changes could be either quite simple or an ugly mess. I am not completely sure at the moment. Which basically means that I cannot make any promises or give a time frame of when it will be done.

[dumblob]

Great news you're going to implement it somehow.

The answer to your questions asking basically "What everything the scaling factor should influence and how?" is surprisingly simple. The scaling factor should influence everything, so the scaling works absolutely the same way as scaling of e.g. SVG in a web browser or Inkscape. Everything else is a matter of layout and has nothing to do with the scale I was writing about.

In fact, the scaling I'm asking for has nothing to do with the unity3d article you linked. In a perfect world, there are no such things as described in the unity3d article, because a layout supporting multiple display sizes with wildly varying pixel densities would use 0-based sizes scale (this is equivalent to the current px in web CSS - it's not one pixel, but just a 0-based scale satisfying the euclidean metric during web page zooming) or ratios (some n-th of the whole) instead of fixed sizes/lengths.

Take a look at the Cassowary algorithm (list of interesting implementations can be found on http://overconstrained.io/) and try to play with it a little e.g. on http://cacaodev.github.io/Autolayout/ConstraintEditor/ . It's very convenient to specify layout using such constraints. Constraint-based layouting is used in Cocoa on Mac OS X and iOS devices exactly for the reason of different pixel densities on various Mac devices. There are lot's of other interesting implementations around:

• https://github.com/gss/engine
• https://github.com/layxlang/layx
• https://github.com/babelsberg/babelsberg-js
• https://github.com/ejvaughan/SimpleFormatLanguage

By the way, I've read your discussions about fonts and I still don't fully understand why don't you want to support similar built-in font handling as e.g. in ImGui? Currently the GUI written using vurtun gui won't be portable at all and it's one of the main reasons why developers won't use vurtun gui. It would be sufficient if there was similar font API as in ImGui with a functional font rendering backend, but being very easy to exchange in case the stb_truetype is not enough.

[dumblob]

By the way, an interesting discussion about constraints-based layouting using Cassowary in immediate GUIs can be found on https://github.com/ocornut/imgui/issues/268 .

[vurtun]

OK that looks like an extreme amount of pain and especially time consumption that I just do not have. In addition my imgui library saves even less widget state than his library, so if he already tells you that he cannot implement it because of the constrains of imgui libraries then it will be almost impossible in mine. In addition why do you think that having no actual font implementation is less portable than implementing one myself. Since the implementation is completely on the user side, with font loading, management as well as drawing it is by definition more portable. The biggest problem with my font handling method is the callback which is needed to calculate the width of a string and therefore limits the source code to C at the moment.

[dumblob]

The constraint-based layout was just an example of the perfect world, which is not our case :smile:. At least not for the time being (the discussion about Cassowary in ImGui continues...).

Back to scaling - was I enough clear with the description?

Regarding font, from my point of view, it's easier to change rendering backends for GUI stuff, but not so easy to change font rendering library (because of weird varying APIs on different platforms). Users nowadays anyway want to write their applications portable and thus choose some tiny portable font library, because they don't want to care about it any more.

If font rendering is part of the GUI library, it doesn't make the library more portable, but greatly increases the probability of using the library for portable applications, because all "inherent" parts of GUI (usually there are two - widgets and fonts) are already part of the one tiny library.

Regarding the callback - why does it limit the source code to C? C-style function pointers are still supported in C++ (even in C++11) if I didn't miss anything. Or did you have something else in mind?

[vurtun]

As for scaling, it is still interesting but I will have to think about an implementation that will fit into my library. At least the concept of creating a UI with a given resolution in mind and having it scale to different resolutions and ratios is definitely interesting and probably worth thinking about. With the callback I was referring to languages outside of C/C++/C++14 like Lua which do not support the concept or rather have limited support and therefore cannot use the library.

[dumblob]

With the callback I was referring to languages outside of C/C++/C++14 like Lua which do not support the concept or rather have limited support and therefore cannot use the library.

Actually Lua has first class functions, so this is not an issue. But in general you're right that there are languages, which don't support that (on the other hand, such languages usually support something similar and thus are able to wrap it one way or another).

[dumblob]

Thanks for the huge rewrite and refactoring! It looks gorgeous - I'll test it ASAP ;)

I'm though still concerned about the scalability as I didn't see anything like that in the source code. Do you have any idea how to achieve that with GUI?

By the way do you think renaming this project to some less generic name (e.g. Vurtun GUI) would be possible as referring just to GUI is extremely ambiguous :(

[vurtun]

It gets better but it is still far away from what I want. So I would not directly advice to commit to this library yet. A lot of things can still change and some things are currently buggy (horizontal scrollbars, dynamic windows height calculation , ...). I am currently trying to fix the bugs and add optional font handling and if that is done I will evaluate if it is really worth it for me to further add more features to this library and go further with vector-like scalability. I spend six month on this library and I am not sure anymore if everything was or is worth the time I invest. Not to talk my library down but my vision of libraries with total control on the side of the user for loss of usability in combination with a rather unknown use of immediate mode APIs in a field which is as oversaturated as GUIs does not seem to be very attractive for a lot of people. As for the name I am very bad with names. I tried to come up with a clever name but finally decided to rename the library from gui to zahnrad. It is not very original but hopefully less generic than 'gui'.

[dumblob]

So I would not directly advice to commit to this library yet.

I understand, but from my point of view, this library is on a good path :wink:

I am currently trying to fix the bugs and add optional font handling and if that is done I will evaluate if it is really worth it for me to further add more features to this library and go further with vector-like scalability.

Ok. I believe though, that such scalability will become an important topic for you in the mean time :wink:.

Not to talk my library down but my vision of libraries with total control on the side of the user for loss of usability in combination with a rather unknown use of immediate mode APIs in a field which is as oversaturated as GUIs does not seem to be very attractive for a lot of people.

Times are slowly changing...

As for the name I am very bad with names. I tried to come up with a clever name but finally decided to rename the library from gui to zahnrad. It is not very original but hopefully less generic than 'gui'.

zahnrad (tooth bike) sounds good to me.

[vurtun]

Good to know. I still think that scalability is important and interesting so it is more a question of if I implement something to achieve it directly or only provide a way to use my library in a way to make it possible. I still have to look into it. But first I have to do font handling and bug fixing. Tooth bike, is not quite correct but almost better than the real meaning :), zahnrad is german for cogwheel which could be translated directly to tooth wheel, so tooth bike is not so far of.

[vurtun]

OK I finished the optional font handling part and took another look at scalability. As far as I can see it the base for it is already present in my library and the only thing I am missing is the constraint solver, which should not be a core part of the library. It is already possible to set the position and size of any window and it is possible to allocate the complete window space and place widget at any pixel position and size inside the window. So it should be possible to take a library like https://github.com/nucleic/kiwi and just calculate the position and size of every window and widget and just set it to the calculated values or am I missing something?

[dumblob]

Thank you for such quick implementation! I like the APIs, especially the adjustability of the font handling.

or am I missing something?

No, you're not missing anything. Initially I was considering having two global variables, but after all the new changes you've done it would be a nonsense. It's way better to stick to some comprehensive layouting (e.g. flat layouting based on the kiwi library you linked or tree-like embedding based on the built-in tiling) and leave the numbers in pixels.

By the way, did you already consider changing all prefixes in file names, C identifiers, etc. from gui to zahnrad or to zr (as an abbreviation)?

[vurtun]

OK good to hear that scaling has been solved. So I guess the only changes that are left are small bug fixes, polish, Makefiles, additional examples and further testing to make sure even more crazy ideas like node editor are possible or even easy to do. As for prefixes I changed all from gui to zr which is hopefully not to bad of a change for everyone using it.