7GUIs
eugenkiss.github.io
eugenkiss.github.io
I fist became familiar with 7GUIs after getting into statecharts of the various flavors, and xState (statecharts in JS) has some of the tasks from 7GUIs implemented: https://xstate.js.org/docs/tutorials/7guis/counter.html
Pulled down some of repositories listed and ran the provided Postman collection against them. None of them passes all the tests, so seems it's missing a bit of testing infrastructure and possibly centralization, to ensure they all pass the tests.
Once that would be in place, it would be easy to add benchmarking to it, to be able to do some honest comparisons.
At least it works as a baseline for seeing the complexity of frameworks, so it's still useful.
I guess this says a lot, not sure though if about the implementors or the frameworks.
- [1] "Comparison of Object-Oriented and Functional Programming for GUI Development" - Eugen Kiss - Page 49 - 3.9 Cells
R.I.P.
Edit: Source: https://github.com/eugenkiss/7guis/issues/28#issuecomment-51...
A different angle would be to introduce server-single-client interop to each application (starting with counter). Then multiplayer.
Another one is to show how easy it is to take one instance and add another on the screen. Any singletons preventing this? How easy it is to then connect the two instances / drive them from another source of data.
#8 Error handling: on an exception, does the whole app crash? What parts of it become unusable? What are the reset paths?
#9 Data consistency indicators: how functional is the UI when in a fallible state like server updates? (In multiplayer games this would be stuff like client side prediction and reconciliation) What is the recovery path so that data isn't lost across many users? CRDTs and their competitors solve it for document editing but what about general purpose GUIs?
#10 User driven layout: Plugins, configurable UI elements, and a panel manager like you'd find in most IDEs.
#11 Automation/accessibility: mapping UI actions to command line calls or a scriptable layer (former for technical fields like EDA packages, latter for more GUI centric stuff like line of business app). Automation and accessibility are two distinct factors but the implementation details align almost perfectly.
Bonus #12: Remote execution for secure GUIs and ultra high processing power collaboration - think stuff like graphical CAD/FEA simulator with an entire bridge assembly. This is usually only possible with X or if you stream something like display lists/GL calls from a browser engine on the server to a client renderer.
I've seen #8-10 absolutely tear through every UI architecture I've ever seen and #11 is important because it's a nonstarter (or should be) for any serious application that goes out to the public, especially as the ADA's reach expands. The latter requires deep integration with any platform it's on so sadly would eliminate all but the big well funded GUI packages.
#12 has broad implications on how humans interface with computers but I've never seen it implemented at the GUI framework level - think WASM style bytecode for streaming UI state updates (I think ember.js's renderer works this way?).
That depends entirely on the use case. I certainly don't want my MCAD/ECAD software crashing because someone introduced a rare bug in the CSV parser that trips over some unrelated library files - I'm perfectly capable of learning how to get it to a safe state for a restart without losing any data. Anyone who uses massive software package like that for their livelihood learns to work around bugs that cause inconsistent state.
#8 is important because there needs to be a generic way to pass errors up through component hierarchies that may not look like the call stack. In many architectures, for example, the exception in an event handler has to get handled at the root of the event loop, not the parent component. That exception handler has to be smart enough to bubble that exception up through parent components.
Web-based tools, on the other hand, have clearer ways to float divs around, or draw with svg elements, or even if you're just using a canvas they help you lay out your data in a convenient way.
Am I missing something about GUI frameworks? As soon as you want to make something complex like Audacity (and audio and waveform editing tool), the frameworks stop being helpful and are just a way to get a blank window.
The coding flow is also nice, in that you can start buy embellishing an element inline, and then when it reaches your complexity tolerance or you find other uses for the same component you can literally cut and paste your code into a new file remove hard coded layout and add imports and you've got your new custom GUI widget.
Also, advanced toolkits like WPF and Qt allow you to build upon existing controls and extent and nest them in really interesting ways to create powerful UIs.
You can also do pretty crazy fringe stuff easily like adding arbitrary widgets to context menus. Arbitrary widgets within list view or tree view items are probably more useful. The trick is to take as much of that composability as you can for your use case and build upon it.
(I am sure other mature toolkits have similar properties, but Ibam not familiar with them to the same extent)
I don't usually do GUI-related work, but each time I do I typically want to do something complex like plotting charts or drawing diagrams. Each time, I look for a tutorial, but I never find something helpful. The results I get are similar to this QPainter tutorial: https://doc.qt.io/qt-5/qtwidgets-painting-basicdrawing-examp... . They show you that painting is possible, but figuring out how to get interactivity is left as an exercise to the reader.
Compare that to working with d3 or react, where the mouse and keyboard events are easy to create. For example, the first time I used d3, I created a bar chart, and it took just a few minutes of googling to add tooltips on hover and other behaviors when clicking on the bars. I honestly do not know a straightforward way to draw a bar chart with hover affects in QT or Gtk.
So how do I assume other people use them? Well, for the above problem you could write your own mouse picker to map from mouse location to the expected bar location. Having to write your own mouse picker certainly works, but it changes the task from something you can crank out in a few hours to needing to allocate a day or two to set up the infrastructure you need to write a good custom widget. This is also why I assumed people use Electron nowadays: you can get unusual UIs without the rigamarole of making a custom widget. So yes, I know it's possible to make GUIs that don't just compose standard widgets, but I assumed it's arduous.
I'm glad you asked. I didn't realize how controversial my original comment was (it was in negative points for a while). But what am I missing here? Have I just been unable to find a good tutorial? If you were trying to do the "Circle Drawer" example, what tutorial or examples would you follow to get it done quickly?
Depending on your needs, you can also have a good look at QGraphicsView. Maybe you'll have an easier time when you compose your UI using QGraphicsItems.
I am trying to imagine how many syscalls would the Linux kernel have if it was designed like the web ecosystem. And more importantly how many of them would stop working after just 1-2 years ...
For web dev I would also add a plain "convert static HTML to a framework based UI", without any interactions as a step zero.
That's not exactly the case in GUI frameworks - where the different axes of evaluation (ex. expressiveness etc) would require lots of changes to logic and API of the framework (as this is not about mere performance).
And even if this did happen, optimizing for those 7 use cases would make them (a) better than what they are now, (b) better for 7 very common cases, which cover most of everything.
I don't want this thing cluttered up with a bunch of bullshit. This is why I really want access to make more modifications to it more easily. That said, I poked around the OS a bit and have access to root, so it stands to reason hacking on this thing isn't insanely restrictive already. Would be really amazing if Remarkable gave out their UI toolkit though.
1) Counter - 10 minutes
2) TempConv - 30 minutes
The only tricky bit I see is expression evaluation in the spreadsheet, the rest is straightforward.