I guess it depends on what you want to do!
Your code was using both the “LMB” and “touch” triggers for the same logic, so in your case it makes sense to just have one, to not make things unnecessarily complicated. 
2 Likes
Don’t you think that it would be better not to stick tightly to the texture names in the code, for example, the “button_normal, button_pressed”, but to make 2 box-nodes in the template and switch them if necessary. In this case, the designer can arbitrarily change the texture and have several buttons with different textures at the same time, without modifying the code.
And yet - in the hit_test, you check local touch = action_id == dirtylarry.action_id_touch, but when you move the mouse (pressed) over the button, the action_id == nil comes over time after time and the button twitches.
2 Likes
Hey, these are good points! I have been wanting to do a new incarnation of dirtylarry for quite some time, but never gotten around to do it. There are certainly a lot of things that could be looked into and rethought.
The thing is, I personally haven’t run into any huge blockers for what I use it for (which is mainly debug GUI) that has pushed me over the edge to do a rewrite. 
There are more mature GUI libraries available, such as gooey, that are aimed at more production level GUI.
That said, I still think dirtylarry still hits a good mixture of ease of use and functionality for “quick and dirty GUIs”. I don’t think I will make any huge changes to dirtylarry in the nearest future, but if someone wants to take a stab and make it easier to make themes/skins for it while keeping the “immediate mode”-ish API, then I’m all for it!
2 Likes
Yes, I like the dirtylarry just for the combination of ease of use and functionality. And use it as GUI-tutorial Thank you for dirtylarry!
3 Likes