I'd posted previously about experimenting with ImGUI, but working on it led to common C++ annoyances. It got me thinking about Fidget again. So I hacked it to increase the DPI for HiDPI screens. That got me wanting to see what else I could add. A few days of hacking in the evening and I was able to add some features like scrolling & scrollbar in the OpenGL renderer. Note I'm not too interested in the HTML renderer.
Here's a short clip of some changes:
It was pretty easy to hack in the features. Scrolling runs at 60fps! I'm not experienced with OpenGL and I'm thankful for all the work @treeform and friends put into making the core libraries. It's much better experience hacking on Fidget than trying to hack on ImGui or other GUI libraries. Gotta love a pure Nim code base.
You can find my code changes at https://github.com/elcritch/fidget.
Always good to have a new GUI option. I wonder how the competition of the GUIs wil turn out.
Hopefully it's not a zero-sum game. :-) Though Nim has a lot of half-workable UI options which is a pain. It's odd but Fidget is like 90% of the way to making useable UIs comparable to ImGUI.
I myself have chosen for the browser-based interface because I think the browser isnt going away any time soon. But what do i know? :-)
Browsers/HTML are king, it's true. Still I really want to be able to make simple static GUIs w/o electron or similar. There's plenty of HTML5 UI options, but not so many OpenGL rendered immediate mode GUIs. So the html5 backend for fidget is less interesting to me is all.
I think next up I'm going to try wrapping Fidget with some ImKivy like widgets and see how it goes. The main limitation to the Fidget OpenGL backend is user inputs and bubbling them up and such.
I have noticed that the nim-community seems sort of neutral towards the choice of GUI, which is usually a wise choice. I suppose they have had heated discussions in the past and now want to avoid "this tool is better than that discussions". However in relation to the take-up of Nim it is relevant. A low-threshold GUI for people to get started programming apps in Nim would be a plus. I have done my round-trip along the possible GUI-options and noticed that some of them were abandoned allready. Maybe because the uptake was not as they had hoped. A certain degree of scattering of energy can happen that way. That is both the plus and the minus of open-soure. Letting the "market" decide what GUI will win is an option. However not making clear choices may also let the market decide that Nim does not have solid GUI-options and thereby discard Nim as a serious alternative. Time will learn what is the best approach. As a result I have chosen for the browser because that will not be abandoned.
But for the new-comers browser-programming is clunky and laborious to write a simple app in. But at least it will not go away, sending ones code to the scrap-heap. But I think besides the browser there is room for one or few low-threshold GUIs that excite people to start programming real-life apps.
Until now I see a lot of libraries and language-improvements (which is good), but I dont see many announcements of end-user-applications. Broadly speaking, I think programming-languages can be used for system-components, business-to-business-apps, end-user-applications and community-aps (like github), which are overlapping categories. But maybe there are more use-cases. I dont know if the Nim-community has a clear vision on the product-placement of Nim. That way i talk in marketing-speak. Actually i have a love-hate-relationship with markets and marketing. I know markets are a reality (descriptive use of markets) but i doubt of markets and marketing as a prescriptive or even a predatory principle, in the sense of conquering markets, thereby crowding out other aspects of life and non-market-cultures. Oh, oh i am going political again...So what is the marketing-plan of Nim? :-)
How much work would it be to move from "immediate mode" UI to an event based solution? Ideally fidget would support both modes equally well, but I have no idea how hard would this be.
Based on my digging around Fidget is a bit of a hybrid model. Fidget only re-draws frames after receiving new events like mouse, keyboard, resize events, etc. However, Fidget does re-calculate all "nodes" for each frame drawn. It's not too dissimilar from React in some ways.
The core of an event system is there, IMHO. It even appears to have some very limited Nim async support.
I was going to see if I could plumb in timer events and/or custom user events to enable drawing time series plots. But it'd just be a dumb "trigger frame re-draw, and let the plot get it's next data".
Though if Fidget user UI code could be setup to integrate async calls it'd make it easy to write "business logic" code for calling databases or the like in a widget. Not sure precisely how to do that. I've been mulling over ideas. Problem is you'd need to cache the previous Fidget Node data until the async was ready. That's a tricky problem though.
Possibly a better system would be more like how React Redux works where events trigger changes to the "data tree", which then triggers a React "render". Something like this Redux-React example. It'd actually fit in with my ImKivy experimental api where only data passed into a widget can be modified by that widget. The old-school Apple UI way was "observable" key-value objects. Suggestions welcome! I think it'd be fun problem to crack, in a more elegant Nim manner.
Anyway, the lack of a business-compatible event-based model keeps me from fully exploring Fidget. And that's very sad. :-)
I get that. I actually believe Fidget was undersold, or rather, that the Figma-like aspects were a bit of a red herring. As cool as the Figma part was, it obscured all the ground work that'd already been done on Fidget's UI engine. Plus most of us developers aren't graphics folks wanting pixel perfect UIs, but we can use pre-made widgets. Kinda ;)
