Interesting ideas! I'm not sure it'd be possible or even desirable to directly share end user code / widgets between frameworks though.
However, there's lots of ideas and core libraries that can be shared. Things like [Windy](https://github.com/treeform/windy) and [nim-native-dialogs](https://github.com/SSPkrolik/nim-native-dialogs) are fantastic core libraries! Personally, I split out my [CSSGrid](https://github.com/elcritch/cssgrid) library from Fidgetty for this sort of eco-system thinking. CSS-Grid is (in my humble opinion) an awesome tool for complex table-like layouts. In theory css-grid can be usable for lots of different GUI's / TUI's / etc. > The challenge at hand seems to be, to unite things into a nim "specification" > for default widgets, widget customizations, toolkit selection, and theming. > Separating concerns with an eye on working with a shared nim interface. This would be challenging. Making re-usable widgets across toolkits requires deciding on various trade-off's and design patterns so it doesn't seem like it'd be a useful goal in itself. However, sharing ideas and being able to "translate" widgets manually, or even using event handling procs could be super helpful. > Has Fidget already come reasonable close to finding some "common event > system" logic that works for input/output of events from different toolkits > (<https://github.com/simonkrauter/NiGui/issues/11>)? Is the only thing left > for an integration, to add access to native interfaces (i.e. NiGui and > webgui) to Fidget v1 or v2? Fidget's event system model is pretty limited when you want to do more advanced things.. I ended up doing a partial re-write of events in Fidgetty. :) It's still simple, but captures mouse events to one node ahead before widgets / nodes are visited. This makes it easy to handle overlapping menu's, etc. It likely wouldn't be a good fit for most native ui-toolkits though.
