41–50 of 60 posts
Earlier quoted context omitted.
It's the only thing that can scale to complicated UI
What does "scale"even mean in UI context? 10 or 100 controls in app makes difference how exactly? Retained apps redraw when needed, they are idle most of the times. How redrawing every frame helps to scale?
I understand the core is the layout engine and a component library? Does the rendering somehow benefit from GPU? I recently had a good experience creating custom UI based on ebitengine — also a cross-platform Go engine. As it is a game engine, it has this built in game drawing loop, GPU-accelerated, with some cross-platform kb/mouse input handling. And this feels like a good platform to build the layout engine and co…
> ebitengine
I have considered using it as a backend, but the blocker for me was how it handles resizing: the window content will stretch while it's being resized.
cross-platform is overstatement. can I run it on Android? iOS? no? then 99.999999% of real world users cannot access it. and if it is desktop oly, what is the point? it is no better than web.
I had a look through the code to see how it manages not to use a pile of C libraries with cgo like other Go GUI libraries. The answer is platform dependent: Windows loads the relevant DLLs by hand and calls them. This is a well established technique in Go programs and due to the super stable DLL interface works well. Linux has an x11 and Wayland backends and these implement (through a library) the wire protocols dire…
> Mobile is under consideration (no decision yet). If it is supported, it will be limited to utility-style apps — not games or rich multi-touch experiences. https://judi.systems/shirei/ No Multiple Windows so even desktop apps will be limited to "utility-style apps". I compiled and ran the process_monitor example on linux: it works, compiles fast and is about 10mb. Also cross-built for windows and it's 8.4mb. Can't b…
Earlier quoted context omitted.
This is a publish-only mirror repo. The commit history is the publish history, not the work history.
but if you other ppl to read, use or contribute, they will probably need the "work history" more than a "publish history". because nobody is going to read those big ass commits, specially when unsure about it worthiness.
Earlier quoted context omitted.
This is a publish-only mirror repo. The commit history is the publish history, not the work history.
that doesn't make much sense. why go out of your way to publish a selected history instead of the whole work?
Earlier quoted context omitted.
that doesn't make much sense. why go out of your way to publish a selected history instead of the whole work?
I have several projects in the same git repository which also forms a workspace in Go. Many of the projects in that repo are not public.
Earlier quoted context omitted.
I have several projects in the same git repository which also forms a workspace in Go. Many of the projects in that repo are not public.
ok, so because of that you manually export changes you want to publish to a new repo? i'd start separating the repos. personally i would be uncomfortable using a repo that the developer does not use for their own development. if you ever want to accept contributions this might become an issue. but that's just my feeling.
I'm putting out something in the hopes of it being useful for others.
Earlier quoted context omitted.
It's the only thing that can scale to complicated UI
What does "scale"even mean in UI context? 10 or 100 controls in app makes difference how exactly? Retained apps redraw when needed, they are idle most of the times. How redrawing every frame helps to scale?
No.
It means that you build the UI by describing what it should look like now, based on the data / state you own, without referencing any existing "widget" object or trying to manipulate it.
Scale is not about the number of buttons, but the structure of the data.
You have a list of objects, within each objects you have several fields, some of them lists, some of them maps. within some of those sub-items you have other lists and maps, nested arbitrarily.
This would be hell to manage for a retained mode UI. You have to mirror the application data into a widget tree and keep all the elements in sync, all the way down to the arbitrary depths of it.
You'd be writing thousands of lines of code that do nothing but keep your data in sync with widget states. You'd have many one off bugs where one sub field fails to sync in some scenarios. Your only options is to be more defensive: more events, more full-resync. As a result, the codebase is complicated and the application feels slow/heavy, because updating widget states is costly.
In immediate mode, none of that matters. You don't have a parallel widget tree.
> Experience has shown us that an immediate mode API is the only sane way to program GUI applications I wonder how long till they pivot away from this belief. I feel like everyone in UI goes through this phase as some point, but in the end it doesn't scale to truly complicated UI
In my experience, it's the opposite. Immediate mode GUI, or at least a functional and declarative approach, is the only way I've seen it scale well. It's more modular and scale-independent. On the other hand, retained mode, or imperative/OOP approach to state management, becomes complicated and monstrous quickly; it's the dominant style and can be made to work OK, but typically hellish to maintain or develop beyond a…