
On the Road to Pure Go X11 GUIs - wolfgke
https://p.janouch.name/article-xgb.html
======
c-smile
A journey of a thousand miles begins with a single step. Indeed.

So you are at the first mile of that road...

On the second mile you will discover that X11 is just a protocol to present
bitmaps on monitor surfaces + plus generator of events coming from some of
input devices.

So on the third mile you will decide that you will need system of widgets and
you will get a tree of HWND's, GtkWidget* - UI DOM elements tree as an
ultimate abstraction.

Somewhere on the way further you will come up with the bright idea that look
and feel of those UI bricks in the tree needs to be customizable. So you will
try to invent style definition system/language. And CSS will be born again.

As a result, at N-th mile, you will end up with something close to Sciter/Go :
[https://github.com/sciter-sdk/go-sciter](https://github.com/sciter-sdk/go-
sciter) that already works not only on X11 but on Windows and Mac too.

~~~
yjftsjthsd-h
Or you can stop halfway and be content with it being functional even if it is
ugly. I'm pretty fond of Tk.

~~~
c-smile
Or Tk, yes, if you prefer buttons a la turrets of _Panzerkampfwagen VI Tiger_
and _musik_ of Sabaton.

~~~
kevin_thibedeau
Ttk enables modern widget rendering in Tk for those who can't appreciate the
benefits of drawing without pixmaps everywhere. Been available for 10+ years.

~~~
pjmlp
10+ years ago Tk was already outdated in what concerns UI design.

Motif widgets on System 7 and Windows NT/2000? No thanks.

~~~
lloeki
You missed the part about TTK, which makes TK use modern widgets, hence is
nowhere near like "classic" TK and very much native in terms of rendering.

See
[https://tkdocs.com/tutorial/widgets.html#button](https://tkdocs.com/tutorial/widgets.html#button)

~~~
pjmlp
Any GUI developer knows that UI/UX is much more than just rendering the same.

Back when Tk still mattered even the attempt to emulate Win32 L&F was just
partially done.

I very much doubt that it has improved.

~~~
mushiake
It's not emulation, it's wrapper on top of native ui toolkit. win32 for
windows, cocoa for macos.

~~~
pjmlp
I am speaking about when Tk mattered, around 2000's.

------
JaggerFoo
Though I do not dare enter the realm you describe, I applaud your quest for a
go-based X11 ecosystem and hope you find considerable help from the go
community to at least accelerate your vision/model to a proof-of-concept.

You may get the usual off-handed opinions when golang is involved - "Rust
...", "Yeah but Go doesn't ...", etc.

I do wish you had a timestamp of your article for reference in the future.

Cheers

~~~
kbenson
> I do wish you had a timestamp of your article for reference in the future.

Well, there are third party HN reply notifiers, sounds like someone should
make Remind-Me-HN. Then again, now that I've said that, I suspect there are
probably plenty of services that allow you to supply a note and email you at a
later date (other than just a calendar app...)

------
dagenix
> I keep thinking about Wayland. It's really a double-edged sword. Aside from
> my pet peeve that it by-design blocks, for inane security reasons, my
> favourite feature of sdtui, which is X11 selection stealing, it also offers
> no mode that would work over a network—for example, to transfer picture data
> you can only use EGL or shared memory.

"it by-design blocks, for inane security reasons" or "for inane security
reasons, my favourite feature of sdtui, which is X11 selection stealing".
Either way, ik curious what the inane security reasons are. Also, why is
blocking bad in Wayland?

It seems like one of the biggest complaints about Wayland is that it doesn't
work over a network. Does anyone actually work that way? I've tried it a few
times, and every time I tried it it turned out to be unusably slow.

~~~
majewsky
Wayland does not support network transparency because you're supposed to use a
VNC server. Making the X protocol network-transparent worked because draw
commands don't make for much traffic, but today you'd be hard-pressed to find
any X application that does not just send entire bitmaps (or rather, OpenGL
textures) to the X server. It's similar to how Mac OS moved away from a
PostScript-based display architecture, if my knowledge of Mac OS history is to
be trusted.

Having said that, I don't know if there are working VNC implementations for
Wayland. Due to Wayland's security architecture, a VNC server (or any other
thing that grabs screen contents) requires permission from (and thus
cooperation with) the compositor.

~~~
emersion
GNOME and KDE have working support for remote desktop. Weston supports RDP.
Sway (and other wlroots-based compositors) have been working on protocols to
support it.

------
srikz
It's so interesting to see a sudden surge in desktop GUI frameworks (or at
least a sudden surge in interest if not actual new tools). I have been
exploring this area for the last few weeks for a new project and have stumbled
across the obvious ones like Qt, GTK, WkWidgets, JavaFx (which IMO has so much
potential but not much development is being done now) and interesting ones
like Juce, Sciter, NanoGUI.

Of course, the elephant in the room is Electron, which in a way showed how
much a new take was required in this area but also has a lot of limitations
wrt app size, processing power etc.

The one I have been following (or rather waiting eagerly) is Scenic by Boyd
Multerer which was incidentally announced / released yesterday after being
shown in a very early state last year at ElixirConf. I find the approach of
leveraging Elixir and OTP for GUI very interesting and the video should give
you a good idea [1]

[1]:
[https://www.youtube.com/watch?v=1QNxLNMq3Uw](https://www.youtube.com/watch?v=1QNxLNMq3Uw)

------
kodablah
> With that out of the way, I've been able to find

Don't forget the quite popular
[https://github.com/andlabs/ui](https://github.com/andlabs/ui), albeit missing
several needed widgets (but work is active there and the base C lib at
[https://github.com/andlabs/libui](https://github.com/andlabs/libui)). Granted
uses Cgo but that should not be a deal breaker for interfacing w/ the native
OS libs.

~~~
aeosynth
he mentions that in the previous paragraph:

> First, people have naturally written bindings for Qt, GTK+, _ui_ , ...

~~~
kodablah
Ah, I must've missed it initially. Regardless, seems with enough constraints
you can justify NIH. Granted the project has merit on its own but not sure why
they are so afraid of Cgo when doing native OS interaction.

------
adamzegelin
What happend to using native platform controls?

All these toolkits look out of place on any platform.

~~~
jermaustin1
This has always been my feeling. Unless you are a designer and are trying to
design a consistent look and feel for your application, why wouldn't you just
design for the native look and feel?

~~~
civility
As more and more apps are web based, this seems like an antiquated notion.
Consistency lost, and I doubt it's important any more. Why should "desktop
apps" follow those rules at all? Even Apple and Microsoft violate their own
rules with their flagship applications.

~~~
kitsunesoba
I disagree simply because the push toward electron and the like are rooted
more in developer convenience and the corporate drive to turn client
developers into a one-size-fits-all dirt cheap bottomless resource than in any
kind of user preference.

Also, a big part of an individual’s platform preference boils down to things
like conventions, look + feel, workflow, etc. By using electron one is tossing
these choices made by the user in the garbage bin in favor of whatever the
developer feels like supporting or what the designer thinks would be fun to
design.

~~~
aikah
> Also, a big part of an individual’s platform preference boils down to things
> like conventions, look + feel, workflow, etc. By using electron one is
> tossing these choices made by the user in the garbage bin in favor of
> whatever the developer feels like supporting or what the designer thinks
> would be fun to design.

Other multi-platform toolkits do not do better. They all violate platform's
conventions. QT, Swing, GTK and co do have their own look and feel and
conventions that do not match the platform's they are in, so I don't see how
worst the web is in that aspect. Don't single out web techs on that specific
aspect.

~~~
kitsunesoba
Qt at least tries to feel native (unless you’re using Qt Quick) and goes
further than the others listed in feeing native. If one cares, it’s pretty
easy to make a Qt app feel “almost native”.

That said, I favor projects that have per-platform true native clients with a
platform agnostic core over those that chase the “dream” of write once run
everywhere. Transmission is a great example of how well this can work.

~~~
O_H_E
Yeah, I greatly respect transmission for that design

------
ericfrederich
I thought X was on its way out?

~~~
exikyut
Someone mentioned GTK3's Broadway backend in another comment.

Try this (the two mentioned commands come with the gtk3 package):

\- In one terminal, run 'broadwayd'

\- In another terminal, run 'GDK_BACKEND=broadway BROADWAY_DISPLAY=:0
gtk3-demo'

\- In __your Web browser__ , go to
[http://localhost:8080/](http://localhost:8080/)

\- Reattach jaw

~~~
O_H_E
Oh boy

What could be a real use case for that

------
emersion
>Ultimately, since I can't go wrong with X and I can go wrong with Wayland,
the choice was easy.

Keep in mind that Wayland has been designed by people who've been maintaining
X11 for years.

>it also offers no mode that would work over a network

X11 has a huge number of issues when it comes to network transparency. tl;dr
is: it's not designed for this, you should use a proper remote desktop
protocol instead. More info:

[https://www.youtube.com/watch?v=GWQh_DmDLKQ](https://www.youtube.com/watch?v=GWQh_DmDLKQ)

>Of that, EGL even requires Mesa and thus Cgo.

That's not true anymore. You can use the DMA-BUF protocol instead of wl_drm.
I'm not sure how to export a DMA-BUF without Cgo though… But that's a
different issue. If you're going to use the GPU you'll probably need Cgo
anyway.

~~~
kevin_thibedeau
> X11 has a huge number of issues when it comes to network transparency. tl;dr
> is: it's not designed for this

X is very much designed for network transparency. The modern extensions that
sling around pixmaps for every little graphical operation are what isn't. I
can still remotely run X11R5 clients thanks to X and its network support.

~~~
the_why_of_y
You can, if by "network" you mean low latency LAN. Modern network remoting
protocols work over high latency WANs as well, which X11 fundamentally can't
do because too much of the protocol requires synchronous round-trips.

~~~
kevin_thibedeau
You can run X over a WAN with the eyecandy turned off. It could be run over a
slow modem. The problem lies in everything that was tacked on assuming it
would only be used locally.

~~~
the_why_of_y
Synchronous round-trips for atoms were there in 1980s' X11.

------
codedokode
I think it would be much easier just to use Qt or GTK. Otherwise you'll have
to write your own widget toolkit, make it cross-platform, solve hundreds of
issues (like hotkeys not working in alternative keyboard layouts), this is
going to be a titanic work.

~~~
jcranmer
The goal of the project, apparently, is to make a GUI toolkit in Go with no
C/C++ dependencies whatsoever [1]. Of course going that route requires coming
to grips with the fact that using a raw display environment requires
implementing a lot of stuff like mapping keyboard events to actual text
strings.

[1] I guess we're supposed to ignore the fact that the X11 server is a massive
C application.

~~~
_ph_
But you don't link against the X11 server, you communicate via sockets with
it. So the client application has no direct dependency of the X server
implementation. Like a web server, the X server could be written in any
language.

------
alexis_read
If you're looking to program a GUI, you'd be best taking a look at Go's parent
AOS/ Active Oberon, and the accompanying GUI (Bluebottle : A Thread-safe
Multimedia and GUI Framework for Active Oberon):
[http://e-collection.ethbib.ethz.ch/ecol-
pool/diss/fulltext/e...](http://e-collection.ethbib.ethz.ch/ecol-
pool/diss/fulltext/eth16074.pdf)

Might be best to port this to Go?

------
iamgopal
Why not leverage skia ?

------
cliffordthedog
> It's an overlooked revolution!

wat?

Go is maybe past peak hype, but it dominates in the cloud/containers space and
is massively popular.

I don't like it, but this statement still seems odd.

------
int_19h
This is one of my frustrations about the Go community - it seems much more
enthusiastic than usual to reinvent the wheel in "pure Go" for what feels are
abstract ideological reasons, where other languages just wrap existing
libraries and call it a day.

I wonder if it's the little things about the experience that add up to that -
e.g. the usual approach to statically linking all Go code in a single binary
leads to no deployment dependencies, and Go community considers it a good
thing; but the moment you start invoking C code, you need to drag the
corresponding .so along. Or maybe it's the part where the weird stack
structure necessary to enable goroutines also impedes FFI performance, and
it's a language that's naturally fast enough for that penalty is noticeable.

Either way, the Go ecosystem feels... deliberately insular, for the lack of
better term?

~~~
jstewartmobile
" _weird stack structure necessary to enable goroutines also impedes FFI
performance_ " is probably the greater part of that equation.

Keeping parameters straight between Cgo and Go is another fine kick in the
nuts. That's true with almost every FFI of course, but with FFI from Python to
C, there's usually a little performance boost to make up for the pain.

Go however, is fast enough to begin with. FFI is all pain there.

------
UI_at_80x24
Regarding Go:

>Yeah, but your scientists were so preoccupied with whether or not they could,
they didn't stop to think if they should.

Sorry couldn't resist. I'm a Systems Admin. An old-fart at that. Every single
encounter I have had with Go has been a burning pile of unpleasantness. Most
recently, the Go-Ethereum client.

So, referring back to the quote; could we just not shoehorn this into
everything? It may be fast but it's fragile FWIW.

~~~
laumars
As an old time sysadmin I'd expect you of all people should know better than
to make assumptions about a programming language based solely on a small
handful applications written in that language.

The ironic thing is what you described ("fast but fragile") better describes
the traditional systems languages that are used to build X11 components: C and
C++. If I had to describe Go as a systems language I'd say it was the exact
opposite: slow but stable. Sadly it's also pretty inflexible for any real low
level stuff (in my experience).

~~~
fao_
> Sadly it's also pretty inflexible for any real low level stuff (in my
> experience).

Which is what the poster above you meant by fragile. C and C++ rarely break in
most spaces, these days. I can take a C library and expect it to build and
_just work_ 99% of the time, and I can build something in those languages and
expect it to be flexible enough to work most of the time as well.

~~~
laumars
If only that were actually true. I've done a lot of work porting C++ code to
various different flavours of Linux and Unix as well as compiling stuff for
Linux from working source and it's rare that things will "just work". Granted
a lot of time the real pain point is manually having to deal with dependencies
(even Go's old $GOPATH solution is better than the stanard C++ approach!).
Then you have compiler flags, compile time options, distribution specific
patch files, dependencies for the build scripts themselves, etc. And that's
before you've even touched on compiler specific variations, language versions
and undefined behaviours. There is a reason why the source-orientated
repositories like FreeBSD ports, Gentoo's portage and Arch's AUR have wrappers
around build scripts and it isn't because things "just work 99% of the time"
;)

Go does have its short comings, I'd be the first to admit that, but the actual
reason I started writing Go was because it was far less brittle trying to
write portable code than C++ and at the time I was having to do a fair amount
of cross compilation on platforms of other CPU architectures as well as
different host OSs (Rust wasn't mature at that point, .NET wasn't open source
and I've never enjoyed working with Java so I thought I'd give Go a try)

~~~
fao_
really? I find that usually automake systems, despite how disgusting they are
to deal with from a developer-standpoint, almost always tend to 'just work'
from a user-standpoint.

I can't really speak very much for C++ systems, as I understand the dominant
build system for that is CMake, which personally I have found completely
abhorrent from a user-perspective. (I once tried to build a 32bit program on a
64bit system, and CMake completely and totally refused to do so! There were no
override flag that actually affected the program, and it didn't look as if
there was any standard place to inject flags to the compiler, I still have no
idea how one goes about doing it, to be quite honest).

