Colorize query status results and highlight on change #7074
Conversation
|
Hello, In principle I like this idea but the amount of extra code (+116 lines to the demo) and use of coding-style not matching style of imgui_demo.cpp makes it something I am unlikely to integrate at the moment. Efforts should be made so that custom logic should be as local as possible to the code using it, and generally to reduce code to a minimum. I'm not entirely sure there is a better way to do that to that to be honest, but in the present condition it seems a little too noisy to be considered for inclusion. I'll keep this open either way to reevaluate later as the idea is good. That, or we expand on this idea to provide an in-imgui debug tool that does something like that (e.g. something you can call manually after an item to output its state), which actually was something on my todo-list already. |
108 but whose counting 馃槤. There is however still a lot of repetitive code. This could be simplified into loops but at the cost of using more C++11 code (lambdas) and dynamically allocation (example)
I just saw now that there are other "helper functions" and "structs" define just before the
That's why the structs are declared inside the functions. But yes, as mentioned above, I missed the fact that some of the |
|
I've pushed an update to use lambdas. That removes a lot of redundant code (only 68 new lines 鉁岋笍). Adding new fields is now just one line per field, with the added benefit that the format string and the The main issue is the use of inheritance and gasp virtual functions. The heap allocation of static variables sucks as well. However, the only alternatives I could think of was using some kind of variant/union, or to separate arrays for the bool vs ImVec2 values, or to use tuples. None felt compelling enough to me though. I've also done another pass at trying to figure out what the coding style is (to be blunt though, it's not easy without some more complete documentation than the 2 lines mentioned in CONTRIBUTING.md, especially since I've seen so much code in my life that I've learned to ignore it 馃槢) |
|
I am afraid this is worse in term of coding style :( I'm not against this but honestly since it isn't an easy slam-dunk in term of merge I'd consider it not urgent. The real underlying problem is that those small requests or features, however legit, tends to be hogging resources away from bigger, more important features. |
|
I see. Sorry to be a burden. I won't bother you again. |
|
Apologies if my answer was misleading: I appreciate the work going into PR like this. |
|
Not sure if you closed that accidentally, afaik since it used |
|
It was accidental. I do have a branch for it now if necessary (but then you said you liked that the 2nd commit even less than the first...) |
|
The idea is good i鈥檓 just not sure what the best strategy is to implement it neatly. I tend to like to keep ideas around, i鈥檒l remember this one and know where to find it (normally the first commit hash is still available). |
In the demo, when query the item and window statuses, colorize the background to make the boolean values more visible (green/red for true/false, blue for others). Also, at high FPS, it's very hard to see when the value changes, especially when it's transient, like the return value or clicks. So make the changes more visible by flashing the background.
|
Hmm I could reopen the PR by re-pushing to master and I see a way to move the PR into another branch (via the So, options:
Preference? |
|
Closing in favor of #7127 |
In the demo, when query the item and window statuses, colorize the background to make the boolean values more visible (green/red for true/false, blue for others).
Also, at high FPS, it's very hard to see when the value changes, especially when it's transient, like the return value or clicks. So make the changes more visible by flashing the background.
example:
Flash.mp4
...with the mouse hovering the child window, which Windows Snip tool doesn't capture 馃槥