Hacker News Reader

Comment by varispeed | Hacker News Reader

This is neat, but the problem I always had in these type of libraries is that they only work enough for the examples to be usable. As soon as I wanted to do something that was not in examples, that would either won't work at all or needed a horrible hack to work. I can't give a real example from the top of my head, but I am thinking like the examples would not show how to do a modal popup window and then you learn when you try to instatiate such window then the other window goes crazy or if you close the modal window everything closes and there would be no way to fix it other than digging into library code. I hope this one is not like that.

View on HN

Dear ImGui is not some half-baked experiment. It's used in tons of real world projects right now. The main way I've seen it used is for developer-facing GUI (debug views, tool/editors, etc)

Did you read far enough in the readme to see the screenshots of the projects using this already? Those look like very complex UIs, and at least one of them is open source for you to look at.

It looks very impressive indeed! I may be giving it a go in the near future as I may have an use case for it.

I agree. They work fine for simplistic interfaces with a few buttons, but what about more complex widgets, like plain/rich/code text editors, that have a lot of different callbacks and fire many different asynchronous events?

Sure, a button function that returns a boolean can be used as a simple parameter to an if statement, but you would would need a switch statement to test for all the different events that a text editor could send. That's a terrible clumsy API! And where do you store the complex state of the attributed text, or parsed source code in a code editor? Do you just pass the entire string in every frame and re-parse html each time?

Where do you store and how do you access all the hidden state, like keyboard focus, cursor position, editing modes, etc, that object oriented user interfaces simply expose as properties, getters or setters?

And how do you implement an outliner? Do you have to write recursive immediate code that traverses the entire tree every frame? Where do you store the outline opened/closed state, per-item state, and the cursor position?

You can't just store that state in the actual objects you're showing in the outline, because that mixes your user interface layer with your data modeling layer. The cure is worse than the disease. You end up cobbling together your own spaghetti-coded special-purpose object oriented retained mode adaptation layer, just what you were trying to avoid by using immediate mode in the first place.

And how do you implement efficient scrolling lists or tables or spreadsheets containing thousands or even hundreds of thousands of items? Do you have to pass every single item through the API every frame, instead of implementing callbacks to only pass and cache the items that fit on the screen?

And how do you implement graphics editors? Or drag and drop previewing? Or popping up item specific menus and submenus when you right-click on a list or outline item? Or anything more complex than a simple button?

Objects and closures and asynchronous event handlers are the best thing that happened to user interface programming since the pixel. Use them!

You ask a lot of questions, but none of them are sincere.. Especially since you finish it off with a dogmatic "Use them!". How about keeping an open mind, asking real questions, and give others the chance to prove you wrong (which would be beneficial to you if they succeed)?

IMO you're so stuck in the OOP mindset, that you cannot see the very simple solutions to your questions. To just pick a single example out of the many, since you don't seem to want to be proven wrong anyway..

In OOP each single widget would store whether it is focused using some boolean member. In IM GUIs one just stores the ID of the widget that is focused once in some library-local data structure:

    // ui.h
    bool has_keyboard_focus(uint64_t widget_id);


    // ui.cpp
    struct UIData {
        uint64_t focused_widget_id;
        int16_t cursor_x, cursor_y;
    } ui_data;

    bool has_keyboard_focus(uint64_t widget_id) { return ui_data.focused_widget_id == widget_id; }

    // my_widget.h
    EditMode my_widget_get_edit_mode(uint64_t widget_id);

    // my_widget.cpp
    map<uint64_t /*widget_id*/, EditMode> widget_id_to_edit_mode;
    option<EditMode> my_widget_get_edit_mode(uint64_t widget_id) {
        auto itr = widget_id_to_edit_mode.find(widget_id);
        return itr != widget_id_to_edit_mode.end() ? itr->second : std::nullopt;
    }

> Sure, a button function that returns a boolean can be used as a simple parameter to an if statement, but you would would need a switch statement to test for all the different events that a text editor could send. That's a terrible clumsy API!

Yes indeed, it would be stupid for a text editor to force you to react on one million events or state changes. But this not how text editors are used. To use text editor in most case you only care about the text contents. Any other information is opt-in.

> And where do you store the complex state of the attributed text, or parsed source code in a code editor? Do you just pass the entire string in every frame and re-parse html each time?

You store it wherever you'd store it normally. Many of your question are assuming - and it's a misunderstanding - that IMGUI means that everything HAS to be recomputed every frame. What matters if the interface presented to the UI programmer. Of course the non-trivial text editor requiring a heavy parser, is going to store data if it needs to do so. What's the problem? Did you expect that IMGUI used zero-byte of memory and never store anything?

Text editor: https://github.com/ocornut/imgui/wiki/Useful-Widgets#text-ed...

> You can't just store that state in the actual objects you're showing in the outline, because that mixes your user interface layer with your data modeling layer.

Ever heard of data structures? You can associate data to an object given its ID without storing data inside the object.. This is what practically any advanced widgets in IMGUI land work. If you need 1 piece of data, use a dumb containers, if you need N pieces of data, use a map.

> And how do you implement efficient scrolling lists or tables or spreadsheets containing thousands or even hundreds of thousands of items? Do you have to pass every single item through the API every frame, instead of implementing callbacks to only pass and cache the items that fit on the screen?

You use a function call helping you to submit only items that fit on the screen. There's literally a helper for that in dear imgui. At this point I'm assuming you have never used what you are criticizing.

> And how do you implement graphics editors?

https://github.com/ocornut/imgui/wiki/Useful-Widgets#node-ed...

> Or drag and drop previewing? Or popping up item specific menus and submenus when you right-click on a list or outline item?

That's widely shown in the demo.

Reply on news.ycombinator.com