My big complaint with textual is that it wants to be react. I can see why it would want to be react, that's a very popular framework that a lot of people are already familiar with, but I don't think it's actually a good way of doing user interfaces. But the basic reactive design is a well trod road, and basing your system design on something that's known to work is a great way to derisk the project. Sure, we'll draw some heavy inspiration from react.
Alright, so we're using some bastardization of CSS as well? That might be going a little bit too far. The react model already breaks the idea of CSS in a lot of ways, preferring standardized components. Sure, developers still use CSS to customize components, but I view that more as a side effect of how react evolved rather than as a justifiable architectural choice. But as long as you don't have to use CSS I suppose it's fine.
Last I tried it, you do have to use CSS. There are no good standard components, so you will be making your own, and instead of having components be one nice self encapsulated Python class the standard docs use things like list components and then style them with an external style sheet.
For those reasons textual just isn't for me yet. In python there should be one, and preferably only one, obvious way to do something. By mirroring react so closely they're also mirroring what I see as the JavaScript communities biggest vice.
Can you elaborate on how textual wants to be like the react framework? I don't see React (or react) mentioned anywhere in the article.
They have a virtual DoM https://textual.textualize.io/api/dom_node/
This includes a lot of what you'd expect from HTML, classes, CSS, etc.
They have reactive attributes https://textual.textualize.io/guide/reactivity/
It has HTML (or at least a DoM), css, and you design widgets the same way.
It's not a virtual DOM. It's not technically even a DOM, because there is no Document. The name has stuck, which is why we went with that. Technically, its a tree. One of the most common data structures used to represent a UI, and predates React by decades.
It has CSS in common with HTML. classes are pretty much required for CSS. That's not "a lot". But why shouldn't a UI framework borrow concepts that work for, you know, User Interfaces?
Reactives attributes are very useful concept to manage UI complexity. And again, not exclusive to React.
this sounds like you're elaborating on why textual wants to be react rather than rebutting the assertion that textual wants to be react. but nobody was saying that wanting to be react was unreasonable
hmm, well, i guess traverseda was sort of saying that react was bad. i doubt that's a widely shared opinion tho
I only meant to rebut the factual claims made in the previous comment. Textual is inspired by web development (and I've always described it as such), but "want to be react" is way overblown. It has things in common with React, but equally many other web and UI frameworks. Heck you could say that Textual wants to be JQuery, and that would be just as apt...
How is it more like jQuery than React?
maybe it depends on what the implicit reference class is. if you're comparing it to react, angular, ncurses, s-lang, jquery, vue.js, and php, then sure, things like html and css are hardly react-specific. if you're comparing it to ncurses, s-lang, win32, mfc, the vic in the commodore 64, winforms, whiptail, dear imgui, the tms9918 used in the msx, emacs lisp markers and text properties, gtk, the nintendo ppu, opengl and glut, xlib, xt, tcl/tk, ansi.sys, naplps, ripscrip, turbovision, direct access menu.exe, and react, it's basically exactly the same thing as react
jesus, i sure have built shitty user interfaces on a lot of platforms
Thanks, it seems like people tend to say react, or reactive attributes, when they are describing model-view-controller (MVC) patterns.
If you think that react (and FRP in general) is not a good way to build UIs, what is, in your opinion?
I don't agree that React is FRP. FRP is a generic solution that builds data-UI synchronization around data, and assumes that incremental UI updates will be written in UI code. React puts data-UI synchronization code inside UI components and provides an Immediate Mode-like API to avoid writing incremental updates in UI code.
In your world, the incremental UI code lives in the react library, and react applications aren’t UI code, they’re just FRP data transformations.
React components are clearly not FRP data transformations, they don't have any notion of data flows, observable/computed values, etc.
I want a way to embed a terminal (it doesn't have to support a myriad terminal emulations, only one) inside a graphical program. MacOS first, but other platforms would be nice.
So, imagine a normal GUI window, but one of the components in it is a terminal window. Is there something like that?
Or should I just use mono font text view?
I've used xterm.js for this, but I was already in a webview. It's pretty good, might even be worth the webview for https://github.com/xtermjs/xterm.js Used by vscode among others
GNOMEs Gtk has a companion library named libvte which provides the terminal as widget. It is used by Gnome-Terminal (and many other terminals) itself and now supports Gtk4:
https://gitlab.gnome.org/GNOME/vte
Basically its usage starts with vte_terminal_new().
Unicode? Emojis? https://gitlab.gnome.org/GNOME/vte/-/blob/master/doc/ambiguo...
What hurts me? The only thing which hurts me is that the maintainer doesn’t like background transparency in the official terminal application. The library supports it and many terminals use it. But this is another topic. With an embedded terminal you will likely not use that feature ;)
PS: KDE likely has a smiliar solution within Qt. As you named portability either Gtk or Qt are you tools. The biggest hurdle is shipping the libraries on macOS. On Linux it is done automatically. Windows is rather easy. Regarding Gtk, ship the gdk-pixbuf loaders alongside, they are loaded at runtime via dlopen(). The small differences hurt during porting.
People probably simply emulate a terminal window and execute the commands via the OS APIs (syscalls). This is unlikely to be truly "embedding".
You don't have to use CSS (actually you never did). Every style can be set in code, and the docs have CSS + Python equivalent for every style.
I guess its been a while since you checked https://textual.textualize.io/widget_gallery/
Yeah, it does seem like things have changed a lot since I last used it, which I think was probably a few years ago. Time flies.
I don't see how it is trying to be React; It definitely tries to use concepts from HTML and CSS (and perhaps even some JS?), but I actually found that it allowed me to move very quickly as I didn't need to learn a whole new UI system from scratch. I didn't need to create any component of my own, and CSS is something I already know. If anything, like I wrote in another comment, the slight layout differences and deviation from CSS is what sometimes got me a little confused.