I'd love to see one website/git repository with implementations from every major framework (desktop+web) implementing these 7 GUIs, and have some benchmarks additionally to some E2E tests. Would make it easy to see at a glance what kind of complexity you would get exposed to as a user of that framework. Anyone know any collection? Closest to that that I know about is http://todomvc.com/ but it's biased in a way that it's very trivial example, geared towards MV* frameworks/libraries and only for web.
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
Yes, that looks like a building block towards what I would want to exist indeed. Thanks for sharing!
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.
Reading through the challenges, the last one seemed like a big leap. Made me think of the “learn to draw” meme that progresses quickly from simple shapes to a simple cartoon and a god leap to a super realistically rendered pencil drawing.
It might seem complicated at a glance, but if you look through the implementation guidelines / rules / description, it's not that big of a leap. It has clear requirements and the paper[1] outlines everything together with example code (in both JavaFX and ScalaFX), and it's not a "god leap" if you have at least a bit of experience building UIs.
- [1] "Comparison of Object-Oriented and Functional Programming for GUI Development" - Eugen Kiss - Page 49 - 3.9 Cells
Neither is it really a "god leap" in the art analogue either, that's what makes it a particularly apt analogy, I think. The implication in the art example is "iterate the above techniques a large number of times to obtain a finished result like this". It seems like a "god leap" because most people don't see the thousands/millions of iterated steps, they see the finished product as a finished product without the intuition of the component parts. That does seem to apply to the Cells project here: most of the same underlying components but yes iterated far enough and long enough it seems like a more insurmountable leap than it should without the right intuition pump.
Well, not a lot seem to have bothered. There are JS spreadsheet implementations in 200 lines, so it's not that it's very difficult, more like this didn't have enough exposure to attract programmers yet -- for example there's not a Cocoa or SwiftUI implementation.
Oh, I did absolutely not suggest that. But without knowing anyone of those involved, I just suggested that they might wish that no more information should be disclosed. That was all.
What extensions can people think of? What is #8, #9 on this progression?
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?).
I don't quite get #8. An exception should be handled where we expect it, depending on a reason for the exception. If something totally unexpected happened, it's better to let the whole app crash than to let it continue running in a corrupted state (unless it's a software for nuclear plants), isn't it?
> If something totally unexpected happened, it's better to let the whole app crash than to let it continue running in a corrupted state (unless it's a software for nuclear plants), isn't it?
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.
So the actual challenge should be a bit better specced. The flight booking example, but some configurations are invalid and the validation can only be calculated after the form is submitted. How should the error be handled?
The circle drawing and spreadsheet tasks are very interesting, because most GUI frameworks and tutorials just focus on laying out standard widgets and make it difficult to create custom components. Gtk and QT help you when your interface is a bunch of checkboxes and text inputs and buttons, but as soon as you want to plot a curve or make a custom tooltip or a chessboard, all it gives you is a canvas and some pixel commands.
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.
Well, I don't think you had a good look at toolkits like Qt. They provide a lot more than just a bumch of widget and window frames. There are application framework style features in there like a very capable undo stack, abstractions over resource loading, MVC pattern implementations, plugin loading, ...
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)
Addendum, but I'm really getting curious now: How did you come to this flawed impression of GUI frameworks? Why did you think people used them if they were so useless?
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.
Actually this is exactly why we use QML. QML makes it easy to create new GUI primitives that can be called in the same way as the standard library widgets.
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.
You make a waveform display widget (where indeed, drawing the waveform is something you implement), and position that using the frameworks layouting options, position sub-elements using the framework tools, use event-handling mechanisms the framework provides, ... Just because you need one piece with custom rendering doesn't mean the framework isn't helpful for everything else, and often it brings tools for that too - e.g. plenty of Qt apps use SVG support for rendering graphics that fit the SVG model well, it has its own graphicsview features that do a lot more than a plain canvas, ...
Is there anything similar that covers other fundamental and common task such as I/O,networking, json, xml, webservice, string manipulation and so on? Or in other words what today is considered as batch processing/system integration?
for distributed systems, the assignments from https://pdos.csail.mit.edu/6.824/ are fantastic. reading material tool, if you want to study and not just do
UX seems to create an insane volume of different ways for doing the very same thing. In other areas of software engineering you just look at the standard library or commonly used libraries and that's enough. I would imagine that's caused by lack of "science" in the process, in the sense that you can't really measure things.
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 ...
That makes more sense for an e.g. processor benchmark, where people compete to cheat and sell more units.
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.
What is sad here is that you are drawing on a computer (and a pretty advanced one at that), and you can draw buttons, but you can't make them "do" anything.
I appreciate how much of the interface was written for this tablet (I can even SSH into it over USB-C), but the OS still seems pretty locked down, which is sad indeed.
Yeah I also have a Remarkable (2), and the potential is all there but the execution on the software side -- beyond the excellent drawing capabilities -- is stunningly unimaginative
IDK, Ethernet over USB seemed really smart, as did self-hosting a little web server for upload/download. It's all pretty basic still though...
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.
I think on the front of collaborative editing we have too many open (research) questions regarding what the best algorithm for solving 'conflicts' is (OT, CFRD, etc.), so that the actual GUI toolkit doesn't matter so much.
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