This style of GUI predates Figma by decades.
We killed the desktop app, to free ourselves from the Wintel monopoly. We pushed the migration to the Web, because that was the unreachable niche for Microsoft and their monopolistic practices.
We succeeded, and as punishment, now we have to endure all these applications written in Node.js with Electron UIs. We won, but we have paid a high price for it.
In this context, Figma is nothing more than an afterthought. Something that appeared as a consequence, not the cause of anything.
And now we have 2 oligopolies instead of 1 monopoly, but in practice it's basically the same thing.
>We killed the desktop app, to free ourselves from the Wintel monopoly.
Bombastic nonsensical crap!
There is no "we”, period. That is a fallacy that you, not "we", impose upon yourself, and try to generalize it to, or foist it upon, everyone.
"We" didn't kill anything. and "we" were not slaves in the first place, so "we" didn't need to make ourselves free.
Maybe you, and some known to you, were slaves, or still are. Don't generalize vacuously.
This is not the multiple Oscar-winning award-winning Ben-Hur movie or the Biblical story of the ancient Israelites as slaves in Egypt or something like that.
Anyone, who wanted to, or at least, any reasonably large group of people (1), could have moved off, from Windows, if they wanted to, badly enough. In the early years of Windows, DOS was still there, right? And had plenty of good software on it, just not GUI-based. and there were some Unix versions around, including maybe some cheaper ones. I rememember Coherent Unix and ESIX, for example. I actually work on the latter, briefly, in an early job. Microsoft's own Xenix existed around the same time too, plus or minus a year or three, maybe.
(1) Say a few hundred or a few thousand people. As an example, they could have collected donations, and hired 20 to 50 smart computer science students, grad or undergrad, and / or professors and / or operating system developers, to create a better OS without the monopoly and bad practices of MS. You bet your ass, at least some people would have queued up for that.
Set up some rules for correct behaviour, and kick out anybody who did not comply.
>We pushed the migration to the Web, because that was the unreachable niche for Microsoft and their monopolistic practices.
So, your only option is to run away from an enemy? And do you think that the enemy cannot follow you there? What about WSL and Azure and what not? Ha ha. Never underestimate your enemies.
See the Stockdale Paradox. The Jim Collins version is a good one.
Now we "enjoy" the Chrome monopoly.
I mean, just try creating a GUI app even exclusively for Windows in 2024 : it was their strength in the past, it’s now the same pain as everywhere else.
Even Windows 11 uses multiple intricate UI frameworks from Microsoft, sometimes on the same screen without any UI coherence.
> InvalidOperation: Unable to find type System.Windows.Forms.MessageBoxButtons].
Add-Type -AssemblyName PresentationFramework
[XML]$form = @"
<Window
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
Title="MainWindow" Height="450" Width="800">
<Grid>
</Grid>
</Window>
"@
$NR = (New-Object System.Xml.XmlNodeReader $form)
$window = [Windows.Markup.XamlReader]::Load($NR)
$window.ShowDialog()So let's hope someone writes a wasm binding.
Seems like they've been involved in transpiling C projects, like TCK, to Go.
Some context: https://news.ycombinator.com/item?id=33197603
==previous message before my edit==
Oh, seems like this is made by CZNIC, the org that admins .cz TLD.
They've also done the Omnia Turris routers, KNOT DNS server or BIRD routing daemon...
Probably best known for their port of SQLite: https://pkg.go.dev/modernc.org/sqlite
I once read drh note that no-one had ever bought any copies of TH3. I'm not sure what that does or doesn't say.
But I would hope this is using TH3 in the development pipeline!
If it's a direct port, the branch coverage should be constructively similar so as to be just as effective a test as for the C version.
Modernc.org is kind of umbrella of his projects.
It's common to have HTML widgets in GUI toolkits, and some may even support MathML, but this here is a bit different.
I know tk has moved on but I have not.
https://tkdocs.com/images/tearoff.png
this used to be on by default in IDLE-python, but it seems they disabled it in more recent versions
you clicked tat dotted line and the menu detached and you could place it anywhere you wanted
I had attended a company course on X Windows, Xlib, and Motif programming, back in the day.
Motif might have been clunky or whatever, but was also powerful. That course was my first introduction to event-driven GUI programming and I was quite junior then, and didn't quite grok all the programming concepts involved, but a colleague, who was more knowledgeable, created a rudimentary MS Paint-like application, in about 1 hour or less, using Motif and C.
(Okay, he worked in the same company as me, but in a different city, so might have had the hardware and software resources to practice on X and Motif before the course, which I did not have.)
Search for 16.3.7 at:
https://www.oreilly.com/library/view/volume-6a-motif/9780596...
or search for tear-off menu at:
https://www.oreilly.com/openbook/motif/vol6a/Vol6a_html/ch15...
It's too ugly for "general-purpose" apps, but it looks to be perfect for internal management apps (control panels, tools). I'm definitely going to try it for my key-management server.
There are rather pleasant exceptions of course.
And I also don't like modern "Material Fuck You" UIs, FWIW.
That said, I can't even elaborate as to why I feel that way.
I'm totally fine with Material design, Fluent design or Apple's HIG, kde or gnome default looks. But this is just... not for me.
I wonder if a ui/ux expert could put into words why so many others feel the same.
Now it looks like a wonderful alternative to all the bloated, wasteful, Electron JS applications out there.
Unfortunately, GitLab is locked behind Cloudflare turnstile and I can't access the source code.
And linking against libtcl and libtk.
Out of curiosity, is that true for $(git clone), too, or just the browser access?
The examples show how to draw controls, but that’s the easiest and least interesting part of GUI apps
(Which needed to be old enough that it had old glibc, so someone with 10 year old OS doesn't complain. Linux.)
zig gets around that by using musl, right? or does it use old libc?
So it's not technically possible to compile to all platforms that Go runs on, only the platforms that the trans-compiler supports. And the resulting Go code is not that readable.
https://gitlab.com/cznic/libtcl9.0/-/blob/master/libtcl9_0_l...
https://pkg.go.dev/modernc.org/ccgo/v3
But it still improves cross-compiling, and results in a libc independent static binary, which is nice. And the work done on the trans-compiling is great.
It’s not bad.
It’s a misguided community thing.
Cgo is the correct choice for many domains (ui, gamedev, systems stuff) where you can’t use a network boundary as your “interacts with other languages”.
The language is opinionated; it’s not good at playing with others. It’s good at other things (network services, etc)… but you can and it’s not bad.
…it’s just hard, and people don’t like hard things.
That library (like this) claim “no cgo” when they use ffi is just ridiculous.
This one is particularly egregious in even supporting cgo!
Pure go my ass. You’re invoking c functions. It’s not pure go.
The distinction is in the tool chain; cgo is a better, first party solution.
Purego is an unstable (it is, read the repo!) workaround for people who a) don’t like the word “cgo” or b) dont like having a c tool chain.
…but realistically you have to interop with c code in many domains.
Sure, a pure world is great, but that’s not always possible.
People who don’t like cgo and choose purego are doing it for, mostly, optics (cgo is bad! This isn’t cgo… it’s ffi… totally different) and appear to fail to appreciate the technical distinction more complicated than they imagine, and they are still using c.
If I can I always pick pure Go solutions just for this reason.
So, it simplifies build pipelines, at the cost of being a bit slower in the runtime.
This is also nice to read about the topic: https://dave.cheney.net/2016/01/18/cgo-is-not-go
$ ldd libtcl9tk9.0.so linux-vdso.so.1 libXft.so.2 => /lib/x86_64-linux-gnu/libXft.so.2 libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 libXss.so.1 => /lib/x86_64-linux-gnu/libXss.so.1 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 libcups.so.2 => /lib/x86_64-linux-gnu/libcups.so.2 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 /lib64/ld-linux-x86-64.so.2 libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 libavahi-common.so.3 => /lib/x86_64-linux-gnu/libavahi-common.so.3 libavahi-client.so.3 => /lib/x86_64-linux-gnu/libavahi-client.so.3 libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5 libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
Yes, it is.
https://gitlab.com/cznic/libtcl9.0/-/blob/master/libtcl9_0_l...
So the "actual source" is still C, but it is CGo-less. Which is neat? But I am not sure how it performs in bigger apps, what are its limitations, etc.
One question though: app is primarily distributed through docker. Can docker app open a window somehow on all platforms? How?
