3 ms·
Textual has a browser-like DOM internally, which means that it has the same kind of structured information that a screen-reader would need. But there isn't a sc
by willm 4y ago
Textual has a browser-like DOM internally, which means that it has the same kind of structured information that a screen-reader would need. But there isn't a screen-reader API for the terminal to expose that.
On the roadmap is a browser target for Textual (same API, just rendering in the browser). Once that's available Textual can make use of browser technology for accessibility.
- sekao 4y agoThe browser target sounds neat. Do you plan on running the python in web assembly, or would it be a client/server design?
- willm 4y agoClient / server initially. The app "runs" remotely with a JS front-end.
- samwillis 4y agoI'm intrigued what the planned architecture is for the web front end. I'm guessing WebSocket back to a persistent process on the backend/server? So all operations happening via the websocket connection. Only the GUI in the browser? I bit like Phoenix LiveView. This would be a really interesting toolkit for building real-time UIs for remote processes.
- willm 4y agoThat's pretty much on the nose!
- samwillis 4y agoAh, so that also explains the significant use of asyncio for all UI operations. Are you also considering a "WebView" front end, a little like Electron?
- willm 4y agoWe were! I figured if we don't do it somebody else will. But there is already a project to bundle a Textual app with a working browser. So you can distribute Textual apps as a binary.