Hacker News Reader

Comment by 999900000999 | Hacker News Reader

Would it be possible to define the GUI with XML, Unity just added this officially and it makes life much better.

Then you do something like rootGUI.Query("elementID").RegisterCallback( e => otherFunc(e));

The joy of immediate mode guis is that you don't have to register callbacks or manually modify (for example) the visibility of elements in response to some action. Instead you do:

    if checkbox(&show_debug, "Show debugging features") {
        if button("Run some test") {
            test()

Joy for ones, pain for others, I don't miss coding GUIs like MS-DOS MODE X or Linux's SVGAlib.

But then if you need to change some non interactive parts of the UI, your digging though source code instead of modifying XML.

Defining the UI via code becomes cumbersome, stuff like adding attributes, etc

Changing attributes of UI elements defined in code vs some XML format is in my mind the same level of effort.

button.SetBackground(<color>)

I see no difference there.

EDIT: Ok the main difference I guess would be having to switch files (and thus context) which could be annoying. Plus there's also the non-zero performance impact from having to parse an XML format.

What if you have stacked elements, or elements within elements.

In code it's something weird like

Box(button( Icon() )))

How is:

  Box(
    Button(
      Icon(...)
    )
  )

Weirder than:

  <Box>
    <Button>
      <Icon ... />
    </Button>
  </Box>

Now attach some callbacks.

With XML I'm attaching my callbacks via code while defining the UI elsewhere.

With pure code, I have to attach the callbacks directly to the object.

Theirs a reason you don't just use JavaScript to define React components

You're in the wrong thread. :-)

The main benefit of most immediate mode guis I've seen is that it's trivial to expose internal values to a ui in one line of code. No callbacks, no looking for the right place in any XML file or similar. Instead you add these lines when you need them and they show up in a ui:

   checkbox(&godmode, "Activate Godmode")
   slider(&enemy_aggro, "Enemy aggression", 0, 100)

> Now attach some callbacks.

Not that any of this is relevant to immediate mode GUI, but the actual attachment of callbacks can be done identically in code no matter how the base UI design is done if you want it separately, but if you do it in code (whether with normal syntax or a funky transform like JSX) you can also have the option of direct attachment.

> With pure code, I have to attach the callbacks directly to the object.

No, you don't, but you can, and as it turns out, that's kind of popular.

> Theirs a reason you don't just use JavaScript to define React components

You can, in fact, but even when you use JSX, there is a reason you don't use actual (HT/X)ML code, but instead a language that compiles to, and let's you freely mix in, JavaScript.

Let's say you have a really complex UI.

Would you really define your UI in code over XML or HTML

Yes.

The more complex and more dynamic the UI, the worse the separation gets. The worst of it being when you’re writing code to generate your XML/HTML, and probably introducing a third “templating” language to continue the pretense that HTML/XML is not just standard data structures defined in a different syntax.

The purpose of XML/HTML is to make your GUI specification independent of the programming language itself, and independent of any particular library (anyone can spit out an HTML <button>… it’s quite difficult for C++ to construct a Java Button class).

And there’s some notion that it’s easier for “non-programmers” to edit, without being bogged down programming language details (its “easier” to learn HTML than Java… and as programmers we eat the cost by now having to learn both)

So now I'm assuming, you're approach would be to just have classes for your custom UI elements.

It might just be a Unity thing, but up until they released their XML UI tools, I could not build a decent UI for the life of me. Basic things like getting buttons to appear where I want them to are very hard without XML

It’s ultimately the same; XML largely maps to a class with attributes (and an identifier/navigation through XPATH) fairly strictly.

And it should largely take you the same amount of effort;

    Div ( 
      button(…)
    )

And

    <Div>
       <button>…</button>
    </Div>

is equivalent. Things like separating your definition from your styling isn’t a feature of HTML/CSS, it’s a feature of the API design — the API just happens to be encoded one way or the other. In-line callbacks vs a selector + callbacks is the same as well (you still need a way to navigate the hierarchy, but XPATH & co. makes just as much sense on an object tree as it does on XML — although with code, you could also just keep the pointer around)

I don’t know unity’s API’s, but I’d bet that their GUI API doesn’t actually look much like their XML API; and that if they did, you’d have had just as much, or little, trouble picking it up.

Its entirely dependent on how w/e library your using implements that pattern. For the code I just recently wrote that does a similar thing, its literally just:

button.SetIcon(<icon-path-or-font-glyph>)

box.add(button)

Doesn't really seem all that weird to me.

I prefer the best of both worlds. I've been making a YAML like widget syntax in code using an immediate mode GUI written in Nim. It let's me write things like:

    Horizontal:
      box 10.WPerc, 100, 8.Em, 2.Em

      Button:
        text: fmt"Clicked4: {self.count:4d}"
        setup: size 8.Em, 2.Em
        onClick: self.count.inc()

https://github.com/elcritch/fidget/blob/devel/tests/basicwid...

The nice thing about separating the view definition from the controller code is you can work on the view without actually running code. Most retained mode GUIs have standalone view editor. That's essentially not possible in immediate mode guis without a lot more mocking of code.

This is almost by definition incompatible with the immediate mode paradigm and UXML is for UI Toolkit, which is retained-mode.

Wait until you find out about HTML and the document object in Javascript

The evolution of HTML and CSS clearly shows that HTML isn't suited to describe a interface without massive hints to a rendering engine to manipulate it

You say that, but I have a really hard time making any native UI toolkit look how I want it to

Reply on news.ycombinator.com