A UI with Shiny for Python?

[JoFrhwld]

Admittedly, we're a ways away from having even a cli, but once we get things in order, it might be possible to put together a Shiny app that users can run locally?

https://shiny.posit.co/py/

I suppose another option would be writing something in Tkinter. https://tkdocs.com/index.html

I think I'd prefer shiny because:

• I already have some familiarity with it.
• Since the interface is all html/javascript, it's maybe a bit easier or familiar to theme?

A potential downside to a shiny interface is that since it runs in the browser, it may contribute to some confusion for users about whether or not their data is leaving their local system.

[chrisbrickhouse]

Agree that we're a long ways off from a GUI. Admittedly, I don't know much about Shiny, but at first glance I don't like the idea:

FAVE is already resource intensive. Shiny requires the user run a local web server and browser which are both resource intensive on their own. The triplet of FAVE, server, and browser will hog resources and degrade all three services. If this were run as an actual web app (like DARLA) where server and client are run on different machines and the server can have arbitrary resources (like DARLA), then I think these concerns are minimized. But as a local interface, it seems too heavy.

TK is incredibly stable, well supported, and has a broad base of programmers who know how to work with it. I learned TK over a decade ago when I still programmed in Perl, and that knowledge translates easily to the modern python interface. The largest benefit of all of this is that knowledge, support, and documentation will be easy to come by because there will be decades of stackoverflow posts, blog posts, and manuals written for the library. As a FOSS project, the another benefit is that the large programmer base makes it more likely that (1) developers will know the library and submit patches and (2) that our developers can build and demonstrate skills that make them competitive in industry.

---

I think the solution here is to keep the main library separate from the UIs in general, graphical or terminal. We have fave-core which exposes a consistent API, and a set of UI libraries that wrap the API in user-friendly ways. Users can choose the UI which is best for their needs without core development being tightly coupled to UI/UX.

So, for example we could have fave-shiny which wraps fave-core's API in the Shiny workflow. This might be useful for DARLA, and thinking ahead, it would be a good division of labor if we had them take point on a web-server-based wrapper for the fave-core as the main downstream users of such a library (i.e., Jim Stanford should probably be tapped for input and interest in this). On the other hand, fave-tk and fave-cli would wrap the core API for local computation, and users could choose the interface that works best for them. It also leaves open the possibility that users develop their own UI for use cases we don't forsee.

A downside to this modular approach is that it leads to fractured user documentation. I think this can be worked around though. DARLA for example would document its own interface and this would serve as user documentation for fave-shiny in general. fave-tk and fave-cli would likely be tightly coupled and use the same functions so it's more about naming things similarly and having a documentation system that allows switching between methods kinda like how some sites allow you to switch between Python/Java/Perl examples in the same tutorial.

[JoFrhwld]

I think the solution here is to keep the main library separate from the UIs in general, graphical or terminal.

Oh I was absolutely thinking of this as a separate library with fave as a dependency.