My 2 cents. My own very strong preference is that the Nim UI library should not depend, either directly or indirectly, on any foreign-language UI API such as GTKx, Qt, Cocoa, whatever. To me, choosing that option means handcuffing oneself to whatever the underlying library offers, with no easy way to extend its capabilities from within Nim. I do not want to be faced with working in a language I'm not interested in, constrained by an unfamiliar framework dictated by that language's eccentricities, to fix some internal glitch that affects what I'm trying to accomplish. To me, the default UI library should be implemented entirely in Nim, not "mostly" in Nim.
What makes the most sense to me is to that the Nim UI library that be based on a graphics library that is common across OSes. As far as I know the only such graphics libraries are opengl/glfw and sdl2. And the only Nim libraries I have found that are based on those are fidget (opengl/glfw), fidgetty (opengl/glfw) and nimx (sdl2). Unfortunately, based on my limited investigation so far, I have concerns with each of them. Some of the concerns I mention may be based on misconceptions. Please correct me where I'm wrong. I agree that fidget looks like a good starting point. But: * From assorted posts in this forum I got the impression that there is/was a "version 2" being worked on. Is that still active? What changes are/were envisioned? * Fidget seems to depend on Figma for designing the layout of an application's UI. Figma is a proprietary product that does not include Linux (my platform). So some alternative for layout specification is needed, for those to whom Figma is not an option. Fidgetty supplies some basic widgets, plus provides a mechanism to deal with layouts. But: * The implementation of fidgetty is based on a cloned "development" version of fidget. Why? Is there any plan under way to reconcile the two? * The core widget code (widgets.nim) is completely opaque to me. This may be because I am a newbie as far as macros are concerned, but to me macros are properly used to extend language features (i.e. DSLs) and should be readable in their own terms. Here it seems that a macro with nested macros/templates is simply used to generate a significant chunk of boilerplate code. I have no argument with the objective, but I find the implementation extremely difficult to understand. I have seen no mention of nimx here, other than a terse dismissal complaining about lack of documentation. That shortcoming is common to all three of the above alternatives. Are there any valid reasons why it should not be considered? On the surface it seems to be the most mature of the three. Has anyone used it for a real application? What was your experience? I have not yet looked at nimx in any depth - the only concern I have so far is that it uses nake for its builds. Which isn't exactly a show-stopper. >From what I have seen so far all three options provide a possible starting >point from where a very viable native Nim UI library can be reached. And I >would be happy to contribute work to getting there. But first I need to see >some degree of consensus about what that starting point is.
