Page 4 of 6

Re: [Request] Input on design spec of new GUI library

Posted: Tue Jan 20, 2015 4:26 pm
by adrix89
adnzzzzZ wrote:Maybe this is kinda unrelated, but I was looking around for some UI APIs from various places to see if anything in particular got my attention, and I found this It looks pretty cool and maybe you guys would wanna use some of its concepts too, I think it's really simple and seems flexible too.
The problem with that library is that video games are very graphics heavy rather then only using predefined ones.
Another is you lose flexibility when you can't extend or override elements.
You probably need a bit more complexity.

Re: [Request] Input on design spec of new GUI library

Posted: Sun Jan 25, 2015 10:48 am
by Karai17
A quick update! I've implemented a fair amount of the main building blocks for this library, mainly the family hierarchy system. I'm working on setting up the box model right now and I figured since I now have things drawing to screen, I'd start showing off screenshots.

It goes without saying that this is still all very early days and everything is subject to change, nothing is optimized, and it is completely unusable, but here is a pretty picture to show progress anyway!


It is worth noting that DOMinatrix will be using the border-box model, NOT the CSS default content-box model. This means that when you set the size of an element, it will shrink the content area to fit the padding and border into that size.

If you have an element with the size 100x100 and you set the padding to 5 on all sides, the element will remain 100x100 but the usable area will shrink to 90x90. This is far more intuitive than the CSS default where the element's size grows when you add padding and border.

Finally, DOMinatrix has moved to the following address, so feel free to star, open issues, etc.

Re: [Request] Input on design spec of new GUI library

Posted: Wed Jan 28, 2015 7:42 am
by Karai17
Another update! The styles syntax is now being parsed! I will start filling in how each property works but for now, we've got a box model and coloured text. ;)


Re: [Request] Input on design spec of new GUI library

Posted: Wed Jan 28, 2015 10:59 am
by mode7
EDIT: Due to my inability to read the thread properly I've overlooked that a MVC (which is very similar to the proposed MVVM) is already a planned feature, which makes this post kind of obsolete. It can still be seen as an example how such a pattern could be realized. :huh:

Hey everyone,
this is quite an interesting topic and project. I've been working on a similar layout engine based on xaml but the project didn't seem to go anywhere.
It's really nice to see people thinking about easier ways to create guis. LoveFrames is a great feature-rich library but creating guis with it is not a pleasant experience I have to say. You have to write tons of verbose code and callbacks.

I think a dom-tree is a first step in the right direction, as it takes care of the whole structure of your gui and can calculate positions automatically.

But what about data?
One of the most annoying parts of gui coding is to keep you internal data and it's gui representation in sync.
Let's say you have a gui-element 'A' which is a checkbox. If 'A' is checked Element 'B' is visible. If 'A' is not checked Element 'B' is invisible. Normally you would have a callback when "A" is checked. In the callback you would look if 'A' is checked or not and set 'B''s visiblilty accordingly. Easy enough. But what happens when you want to hide 'B' from code? You have to set 'B's visibility and set the checked state of 'A' to 'unchecked'. Still not that hard you think, but what happens if 'A' also controls the visibility of 'C', 'D' and 'E' unchecking 'A' would mean hiding them all and hiding 'A' from code could imply you want to hide 'C','D' and 'E' as well.
An easier example would be the title of a document, that the user can change in a textbox and that is also displayed in the headbar. Changing the text in the textbox would imply that the text in the headbar also changes.

All this can be done with data binding often used in connection with a Model-View-ViewModel (MVVM) pattern.
Consider this (totally made up) xml markup. Which woud be called a "view"

Code: Select all

<checkbox id="Z" checked="binding={windowsVisible}"/>
<window id="A" visible="binding={windowsVisible}">foo</window>
<window id="B" visible="binding={windowsVisible}">foo</window>
In your gui control code (which would be called a "viewModel") you would have something like

Code: Select all

windowsVisible = true
function hideWindows()
    windowsVisible = false
So a single variable represents 3 properties: the checked state of 'Z', and the visible state of 'A' and 'B'.
Please note, thate normally 'windowsVisible' would not be a bool but an observable object, that can recieve events from the view such as when the checkbox is clicked.

Another advantadge comes from the Model part of this pattern. Normally you want your gui to represent objects or data that you have in you game/application state, but you don't want any gui code in your state.E.g. say you want to create a level editor. You might want to manipulate and inspect the level data from your gui but you don't want any gui code in your level once you load it in the game. So the level would be the model, the editors-gui would be the view and the viewmodel would help you to both connect them together and keep them separated.

I would love to see such a pattern incorporated in a gui library and strongly suggest in doing so.

For examples take a look at Microsofts XAML applications (such as WPF, Silverlight or Windows 8.1 Apps) if you're into Microsoft or have a look at the brilliant MVVM framework KnockoutJS ( which has also quite nice interactive examples.

Re: [Request] Input on design spec of new GUI library

Posted: Thu Jan 29, 2015 12:13 am
by Karai17
Nested styles work now, and things are a little more sane. \o/

EDIT: Here is the output from my current tests and benchmarks!

Code: Select all

Executing: love  .
Passed: Parsed Markup

Passed: ID Selector
Passed: Type Selector
Passed: Class Selector
Passed: New Element
Passed: New Element (below 1)
Passed: New Element (above #)
Passed: Check Siblings
Passed: New Root Element

Passed: Has Children
Passed: Prepend Child
Passed: Append Child
Passed: Add Child
Passed: Remove Child
Passed: Replace Child
Passed: Insert Before
Passed: Insert After
Passed: Attach Child
Passed: Detach Child
Passed: Destroy Element
Passed: Clone Element
Passed: Check Properties
Passed: Get Property Values
Passed: Set Property Values
Passed: Remove Property Values

Passed: Element Styles
Passed: ID Styles
Passed: Class Styles
Passed: Nested Styles
Passed: Conflicting Value Assignments
Passed: :last Pseudo-Class

All Tests: Passed

50 Elements: 0.000529
500 Elements: 0.008748
5000 Elements: 0.079288

50 Selectors: 0.000772
500 Selectors: 0.003162
5000 Selectors: 0.186242

50 Elements, 50 Selectors, 600 Passes: 0.000300s/f
500 Elements, 50 Selectors, 600 Passes: 0.000810s/f
5000 Elements, 50 Selectors, 600 Passes: 0.008100s/f
50 Elements, 500 Selectors, 600 Passes: 0.002485s/f
500 Elements, 500 Selectors, 600 Passes: 0.007958s/f
5000 Elements, 500 Selectors, 600 Passes: 0.091379s/f
50 Elements, 5000 Selectors, 600 Passes: 0.025748s/f
500 Elements, 5000 Selectors, 600 Passes: 0.077881s/f
5000 Elements, 5000 Selectors, 600 Passes: 0.819223s/f

All Benchmarks: Completed

Re: [Request] Input on design spec of new GUI library

Posted: Thu Jan 29, 2015 7:33 am
by Karai17
I fixed up my display model so things are in the proper position depending on whether they are block or inline elements. :)


As you can see, Block elements take up their full horizontal space, inline elements wrap if they were to overflow, and children also work.

Margin, Border, and Padding are all taken into account.

Re: [Request] Input on design spec of new GUI library

Posted: Fri Jan 30, 2015 5:17 am
by Karai17
I spent today implementing more of the box model. Elements without a defined width or height now have it dynamically created in the same way that HTML does it:

* If no width defined, the element will consume as much width as possible.
* If no height defined, the element will consume as little height as needed.
* Element will always start on a new line.

Inline (Inline-Block in HTML):
* If no width defined, the element will consume as little width as needed.
* If no height defined, the element will consume as little height as needed.
* Element will start on the right of the previous line except for if the previous element was block or if there is no room within container.


Pictured above:

* Yellow lines are element margins
* White lines are element width/heights
* Blue lines are element content areas (width/height sans border and padding)
* Text is element values being printed
* Red text is the text colour for the child elements as defined by the stylesheet
* The B* elements are all block elements with a defined height but no width (width is generated by consuming the full container content width, in this case the whole screen)
* B2 is a block element with a defined width and height
* The I* elements are all inline elements with a defined height but no width (width is generated based on criteria such as content width or largest-child)

Re: [Request] Input on design spec of new GUI library

Posted: Fri Jan 30, 2015 3:00 pm
by Zarty55
Looking pretty good man!! Can't wait to use it :awesome:

Re: [Request] Input on design spec of new GUI library

Posted: Sun Feb 15, 2015 10:49 am
by Karai17
A quick update. I had put this on hold for a little bit to work on other things, but I have come back to it now and have dome a lot of code clean up and restructuring. While the screenshot below may not be an impressive step forward from the previous, the code is much more manageable now and I am going to start implementing a full flexible box model on top of the basic box model. Once both Basic and Flexible boxes are done, things should move much more quickly.


Re: DOMinatrix - a WIP GUI Library

Posted: Tue Feb 24, 2015 1:29 pm
by Karai17
Today I woke up a bit earlier than intended, so I decided to build an event system. Not sure how, but after about three hours of coding when I finally pressed "build", it just... worked. I haven't created a full test-case yet, but it seems to work quite well! I still need to implement importing scripts but otherwise, we now have a full event system. And by full, I mean Mouse, keyboard, joystick, and gamepad! :)

Edit: Importing script files now works, too! This completes the full MVC layout and gives you the power to start building a UI. Next up will be to start filling in the styles so that our UI can start looking like more than just some boxes. ;)




As previously noted, you *can* avoid the MVC system and strictly use the controller to design everything, if you so choose.