The future of Nuklear - brainstorming ideas

[dumblob]

@BieHDC wrote on 2021-12-20:

This should be the discussion place of what should be done and etc as the discussion started in this issue.

This is also my first time directly working with others together and figuring out this new interface.

[dumblob]

@dumblob wrote on 2021-12-20:

Will reply later (hopefully at the latest in a few days but ... anything can happen).

Btw. could this be made public? I think we shouldn't hide such discussions 😉.

[dumblob]

@BieHDC wrote on 2021-12-20:

I dont know, i am literally using this interface first time too. But i am busy the next days anyway, so...

[dumblob]

@RobLoach wrote on 2021-12-25:

One thing I'd love to see revamped is the gamepad/keyboard-only support. While you can accomplish it, it takes some work. Would be nice to have it just work.

[Hejsil]

With my null-termination-be-gone branch, it's pretty clear that I'm a big fan of having an API that is friendly and efficient to bindings from other languages. This would include:

• API that does not use null terminated strings
• libc is optional (nuklear already forfills this)
• Mark none nullable pointers as such with some annotation (there are compiler attributes for this)
  • This is useful for tools that generates bindings based on header files

One other thing I have as a wishlist item is a better allocator interface. The current one has the same interface as malloc/free, but this kind of interface requires the allocator keeps track of the allocation length, which can be extra unnecessary overhead for some allocation schemes.

[Hejsil]

Another one: A very low level API for nk_label and other text widgets that provides some sort of string builder, which can then be used to implement printf formatting and the like. Idk the exact API, but something like this is what I'm thinking.

struct nk_command_text_builder builder = nk_label_builder_begin(ctx);
nk_command_text_builder_append(&builder, "prefix - ");
nk_command_text_builder_append(&builder, some_string_variable);
nk_command_text_builder_append(&builder, " - suffix");
nk_label_builder_end(&builder);

The idea here being that the string will be built in place on the nk_command_text that will be emitted. This would allow other languages to wrap this API and use their standard formatting APIs.

[dumblob]

A very low level API for nk_label and other text widgets that provides some sort of string builder, which can then be used to implement printf formatting and the like...

Just saw this and find it interesting - especially if extended to allow for custom string "type" - e.g. https://github.com/josephg/librope (or its "successor" https://github.com/josephg/jumprope-rs ).

[iperov]

Hi guys.
Is it possible to create brand new UI concept, something between [Immediate mode UI] and [Full state UI].
Keep simplicity of UI declaration, but provide more flexibility, such as animations?

[dumblob]

@iperov yes, that's one of the few things I myself had in mind - but didn't have time to write a concise description of what I think. I'll get to it at some point.

Feel free to take a look at traffaillac/traffaillac.github.io#1 and Pauan/rust-signals#31 in the meantime.

If you have any ideas, speak out - the more feedback the better 😉.

[iperov]

I have an idea, but I don't know how relevant it is because I don't design GUI engines.
For example when we declare a sequence of layout and widgets
gui.vertical_layout_start()
gui.label()
gui.horizontal_layout_start()
gui.label()
gui.button()

the engine should automatically build internal layout/widget objects/structures?
and they won't reset on the next pass if the widget declarations match the internal representation?

also can user get access to such structures to define additional logic?
for example some pseudocode

button_obj = gui.button()
if button_obj.clicked():
   ... instant click process right here

button_obj.call_on_hover( on_button_hover ) - call function if mouse is hovering button

func on_button_hover (button_obj.):
   time = button_object.mouse_hovering_elapsed_time()
   button_obj.set_color(  RGB()*time  )
   if time >= 1.0:
     button_obj.set_icon ( icon_ready )
   if time < 1.0:
     button_obj.disable_click()

also 

gui.button.set_default_on_button_hover (on_button_hover) - to set handler for all buttons

so it is ok when some widget sequences are changed and do not match internal representation, they will just recreated, and all animation will reset.

also I would like to have a library for python as well. Because machine learning requires visualization, and QT is too redundant for that purpose.

[threedslider]

Hi,

Nuklear is very cool project, I will use it surely. My request is : will be it as 100% full customization with 100% visual for my C++ project ?

[dumblob]

My request is : will be it as 100% full customization with 100% visual for my C++ project ?

The current Nuklear is very customizable. If you can specify technical shortcomings you experience, then please describe them in detail here. Otherwise please use the Nuklear issue tracker to discuss everything else. Thanks!

[dumblob]

To keep in mind the other side of the spectrum: https://wiki.csswg.org/ideas/mistakes (it's missing some - e.g. ::first-line which is subject to font-size thus creating a loop...).

[threedslider]

The current Nuklear is very customizable. If you can specify technical shortcomings you experience, then please describe them in detail here. Otherwise please use the Nuklear issue tracker to discuss everything else. Thanks!

Ok cool ! Thank you too and keep it up ^^

[dumblob]

Some very interesting thoughts about "command" drawing (Nuklear currently also uses commands) and different kinds of such commands etc. from a highly experienced person: red/REP#103 (comment) .

[BieHDC]

Sorry for the long silence, but i finally got time again. Here are some of the keypoints i would like to have:

• Only 2 layouting systems, a simple one like nk_layout_dynamic and one for complex ones. Consider the default chat application: left sidebar spanning from top to bottom 64px wide, then you have a subspace with a top bar holding channel description. Then you have another subspace with input bar at the bottom and a send button, and the rest in the middle for text. Something like this should be "easily" doable, but right now we lack the "take the rest of the remaining space and treat it as new window" kind of command (which is kinda what my subspace pr is trying to do). This also means that instead of being top left to buttom down only layouting, you should be able to specify the anchor point (i think thats what its called). In this example for the text input and send button you would anchor to bottom left.
• I would also make much more use of caching. So you still stay immediate mode but first time code path it initialises memory from heap. This makes saving and accessing the state much easier and should remove some "hacky" things as annotated in current nuklear.
• Having simple modular widgets to build larger more complex widgets. For example being able to connect a bunch of text input widgets to build a bigger excel sheet. This was something that was personally causing me issues since some widgets have a mind of their own. Basically have a nice way to make complex widgets.

Thats what i remember right now, please give feedback.