Potential change to a different GUI framework

[setzer22]

Hi all! 👋

This is just a heads up. I'm not sure if this decision is going to go through, for now I'm just exploring, but... I'm thinking of migrating Blackjack's frontend from egui to Iced. If I end up committing to this, there will be a more in-depth rationale, but here's a super quick summary of what's made me look into this:

• No "native" zooming support (what I've been using for Blackjack was supposed to be a temporary hack): A panning / zooming container emilk/egui#1811
• No way to separate draw order from interaction order, causing event handling issues: Incorrect draw order egui_node_graph#71
• Complex layout: No easy way to share left-aligned and right-aligned widgets in the same row, any kind of right-aligning is generally a pain.

I still love egui and how smooth it feels to develop UI logic in it, but I think Blackjack is at a point where it makes sense to make my life as a programmer a bit more difficult, if that means I can be up to the UX standards I aspire for this app.

There's people who have expressed interest in learning more about the UI side of the code, and that would certainly be affected by this rewrite, so I'd rather warn people sooner than later 😄 (I'll take the liberty to ping those of you who have been more active recently @inact1v1ty @HenryWConklin @Zireael07).

To validate this is the right move, I've been working on a simple prototype on the feature/ui_iced_poc branch. The branch currently won't build because it's pointing to some local dependencies, but in case anyone is interested on working on this or just build the code please let me know! Here's a showcase GIF in the meantime, the thing is still pretty bare bones, but just look how much better that graph zooming feels already! 🙂

[setzer22]

Another quick update 😄

After trying Iced for a while, I found it to be a very nice library with a lot of potential. But there are several things in it that made a potential rewrite too painful:

• The Elm architecture is very far from what I envision for Blackjack. It creates a lot of unnecessary indirection in a way that I feel would make the codebase too hard for me to navigate comfortably, and for potential contributors to pick up. This is of course entirely subjective, but I'd like something closer to the simplicity of egui.
• The Iced ecosystem is still a bit shaky. There have been some major breaking changes recently, and more are planned. Some features are still notably missing. The most important one is multiline text edit support.

Overall, I felt the cost to adopt Iced was too high at this time, so I called off the initial experiment. But all the points I brought up about egui in my previous message are still valid. So I've decided to try a different thing: The epaint crate that powers egui is in a very good state, and is capable of rendering anything egui is capable of rendering, so I'm building an alternative UI system on top of epaint called guee, which can be found here: https://github.com/setzer22/guee. I'm trying to build something that fits Blackjack well, and addresses all of the shortcomings listed above:

• Widget panning and zooming is supported from the start.
• The library is still recreating the state from scratch each frame, so in a sense it is immediate-mode. But layout, input processing and drawing are separated, communicating to each other via a widget tree, and the user sets callbacks to modify the state, so in a sense it is also retained-mode.
• The above, not only solves the issue of decoupling rendering order from processing order, but allows implementing a crappy version of the flexbox algorithm for more complex layout.

I have some early results for this, and in a similar amount of time, the rewrite is already much further than it was when I tried to do this in Iced. The library is currently being developed in lockstep with the new Blackjack GUI, as a dogfooding strategy. Here's a few screencaps: