13 ms·

On the Road to Pure Go X11 GUIs

198 points by wolfgke 8y ago

kodablah 8y ago
> 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 8y ago
  he mentions that in the previous paragraph: > First, people have naturally written bindings for Qt, GTK+, ui, ...
  - kodablah 8y ago
    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 8y ago
What happend to using native platform controls? All these toolkits look out of place on any platform.
- jermaustin1 8y ago
  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 8y ago
    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.
    - tonyedgecombe 8y ago
      Some of us still care.
    - kitsunesoba 8y ago
      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 8y ago
        > 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 8y ago
        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.
- Asooka 8y ago
  X11 doesn't have native controls. The closest would be motif, or Xaw, but nobody sane uses those. GTK and Qt are both equally "native". Chrome uses its own GTK-derived UI lib, IIRC . As long as OP's ui implements accessibility and follows the desktop's settings as close as feasible, I see no problem.
- jerf 8y ago
  "What happend to using native platform controls?" This appears to be X11-specific, and X11 essentially does not have native platform controls. Also if you're in X11 you've quite likely already given up any real hope of all your windows looking the same. You also seem to be casually assuming this would be cross-platform, but this would be the equivalent of implementing something in raw Win32 API calls. There's zero cross-platform concerns here, on the grounds it'll never be cross-platform. In fact, given that it's pretty likely the move to Wayland would be completed by the Linux community before this project could reach a point where it would be something you might consider using seriously for a non-trivial project, it's debatable whether it's even good for one platform.
- jimjimjim 8y ago
  even in win32 land this idea is going away. more and more windows applications are theming/drawing their own look and feel onto their UIs to give more consistency across the organization's applications rather than consistency with windows.
ericfrederich 8y ago
I thought X was on its way out?
- fpoling 8y ago
  It has been on the way out for the last 10 years. I suspect that X11 outlives Wayland simply because the latter will be replaced by yet another technology but X11 applications will still be supported.
- danmg 8y ago
  For the past 30 years or so...
- PopsiclePete 8y ago
  X has been dying for possibly longer than Apple. Which is quite impressive.
  - emidln 8y ago
    X, along with FreeBSD and Lisp have been dying for a few decades now at least. I think the quote goes "doesn't look any deader than usual".
    - bitwize 8y ago
      I think the eventual goal is to get the major DEs and toolkits to stop supporting their X backends in the near future. Then X would be effectively dead but for ancient legacy applications. This has already happened for ALSA with some applications. If you want to use BlueZ or Firefox, your options are either PulseAudio or no sound at all under Linux.
      - kevin_thibedeau 8y ago
        They will still support X as an independent server application no different than running Xorg in Windows or MacOS. That can never be obsoleted.
    - 8y ago
UI_at_80x24 8y ago
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.
- sumitgt 8y ago
  > Every single encounter I have had with Go has been a burning pile of unpleasantness. Can you elaborate? > It may be fast but it's fragile FWIW. Go explicitly focuses on language stability over fancy new features.
  - slaymaker1907 8y ago
    > Go explicitly focuses on language stability over fancy new features. I think that might be the problem... C is probably the most stable language around in terms of features, but it is probably the language that is most prone to bugs and security flaws that is in common use.
    - sumitgt 8y ago
      Yes, but it is very difficult to introduce the same kind of bugs in Go code considering you are no longer doing intricate memory management, etc.
    - laumars 8y ago
      C also has raw pointers, manual memory management and a bunch of other unsafe practices that Go doesn't. In comparison to C, Go is practically a scripting language.
      - slaymaker1907 8y ago
        Totally agree there. However, I think the metaphor might still hold that Go applications are brittle due to lack of features due to the ugly hacks you have to use to get around the lack of features. For instance, due to the heavy usage of manual error checking, it can be very easy to call a function and forget that it returns an error thereby ignoring that error. Bringing down your whole application due to a single error is bad, but silent failure is almost always much worse.
JaggerFoo 8y ago
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 8y ago
  > 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...)
iamgopal 8y ago
Why not leverage skia ?
dagenix 8y ago
> 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 8y ago
  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 8y ago
    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.
  - pjmlp 8y ago
    Mac OS never had any PostScript-based display architecture, NeXTStep and Sun Views did. OS X replaced PostScript with Quartz, which uses a PDF like architecture.
- Asooka 8y ago
codedokode 8y ago
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 8y ago
  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_ 8y ago
    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.
cliffordthedog 8y ago
> 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.
c-smile 8y ago
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.
- deleted 8y ago
  [deleted]
- yjftsjthsd-h 8y ago
  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 8y ago
    Or Tk, yes, if you prefer buttons a la turrets of Panzerkampfwagen VI Tiger and musik of Sabaton.
    - oblio 8y ago
      I’m going to borrow this comparison when someone recommends Tk :))) Solid tech, but c’est la vie, software still folows fashion, as you so amusingly showed :)
    - kevin_thibedeau 8y ago
      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.
emersion 8y ago
>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 8y ago
  > 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 8y ago
    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 8y ago
      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 8y ago
        Synchronous round-trips for atoms were there in 1980s' X11.
int_19h 8y ago
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 8y ago
  "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.
srikz 8y ago
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
alexis_read 8y ago
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/eth16074.pdf http://e-collection.ethbib.ethz.ch/ecol-pool/diss/fulltext/e... Might be best to port this to Go?

198 points by wolfgke 8y ago

> 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 8y ago
he mentions that in the previous paragraph: > First, people have naturally written bindings for Qt, GTK+, ui, ...
- kodablah 8y ago
  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 8y ago

What happend to using native platform controls? All these toolkits look out of place on any platform.

jermaustin1 8y ago
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 8y ago
  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.
  - tonyedgecombe 8y ago
    Some of us still care.
  - kitsunesoba 8y ago
    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 8y ago
      > 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 8y ago
        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.
Asooka 8y ago
X11 doesn't have native controls. The closest would be motif, or Xaw, but nobody sane uses those. GTK and Qt are both equally "native". Chrome uses its own GTK-derived UI lib, IIRC . As long as OP's ui implements accessibility and follows the desktop's settings as close as feasible, I see no problem.
jerf 8y ago
"What happend to using native platform controls?" This appears to be X11-specific, and X11 essentially does not have native platform controls. Also if you're in X11 you've quite likely already given up any real hope of all your windows looking the same. You also seem to be casually assuming this would be cross-platform, but this would be the equivalent of implementing something in raw Win32 API calls. There's zero cross-platform concerns here, on the grounds it'll never be cross-platform. In fact, given that it's pretty likely the move to Wayland would be completed by the Linux community before this project could reach a point where it would be something you might consider using seriously for a non-trivial project, it's debatable whether it's even good for one platform.
jimjimjim 8y ago
even in win32 land this idea is going away. more and more windows applications are theming/drawing their own look and feel onto their UIs to give more consistency across the organization's applications rather than consistency with windows.

ericfrederich 8y ago

I thought X was on its way out?

fpoling 8y ago
It has been on the way out for the last 10 years. I suspect that X11 outlives Wayland simply because the latter will be replaced by yet another technology but X11 applications will still be supported.
danmg 8y ago
For the past 30 years or so...
PopsiclePete 8y ago
X has been dying for possibly longer than Apple. Which is quite impressive.
- emidln 8y ago
  X, along with FreeBSD and Lisp have been dying for a few decades now at least. I think the quote goes "doesn't look any deader than usual".
  - bitwize 8y ago
    I think the eventual goal is to get the major DEs and toolkits to stop supporting their X backends in the near future. Then X would be effectively dead but for ancient legacy applications. This has already happened for ALSA with some applications. If you want to use BlueZ or Firefox, your options are either PulseAudio or no sound at all under Linux.
    - kevin_thibedeau 8y ago
      They will still support X as an independent server application no different than running Xorg in Windows or MacOS. That can never be obsoleted.
  - 8y ago

UI_at_80x24 8y ago

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.

sumitgt 8y ago
> Every single encounter I have had with Go has been a burning pile of unpleasantness. Can you elaborate? > It may be fast but it's fragile FWIW. Go explicitly focuses on language stability over fancy new features.
- slaymaker1907 8y ago
  > Go explicitly focuses on language stability over fancy new features. I think that might be the problem... C is probably the most stable language around in terms of features, but it is probably the language that is most prone to bugs and security flaws that is in common use.
  - sumitgt 8y ago
    Yes, but it is very difficult to introduce the same kind of bugs in Go code considering you are no longer doing intricate memory management, etc.
  - laumars 8y ago
    C also has raw pointers, manual memory management and a bunch of other unsafe practices that Go doesn't. In comparison to C, Go is practically a scripting language.
    - slaymaker1907 8y ago
      Totally agree there. However, I think the metaphor might still hold that Go applications are brittle due to lack of features due to the ugly hacks you have to use to get around the lack of features. For instance, due to the heavy usage of manual error checking, it can be very easy to call a function and forget that it returns an error thereby ignoring that error. Bringing down your whole application due to a single error is bad, but silent failure is almost always much worse.

JaggerFoo 8y ago

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 8y ago
> 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...)

iamgopal 8y ago

Why not leverage skia ?

dagenix 8y ago

> 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 8y ago
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 8y ago
  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.
- pjmlp 8y ago
  Mac OS never had any PostScript-based display architecture, NeXTStep and Sun Views did. OS X replaced PostScript with Quartz, which uses a PDF like architecture.
Asooka 8y ago

codedokode 8y ago

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 8y ago
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_ 8y ago
  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.

cliffordthedog 8y ago

> 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.

c-smile 8y ago

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.

deleted 8y ago
[deleted]
yjftsjthsd-h 8y ago
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 8y ago
  Or Tk, yes, if you prefer buttons a la turrets of Panzerkampfwagen VI Tiger and musik of Sabaton.
  - oblio 8y ago
    I’m going to borrow this comparison when someone recommends Tk :))) Solid tech, but c’est la vie, software still folows fashion, as you so amusingly showed :)
  - kevin_thibedeau 8y ago
    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.

emersion 8y ago

>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 8y ago
> 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 8y ago
  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 8y ago
    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 8y ago
      Synchronous round-trips for atoms were there in 1980s' X11.

int_19h 8y ago

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 8y ago
"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.

srikz 8y ago

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

alexis_read 8y ago

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/eth16074.pdf http://e-collection.ethbib.ethz.ch/ecol-pool/diss/fulltext/e... Might be best to port this to Go?