• by heywire on 5/25/2024, 12:18:42 AM

    I’ll have to give this a look! I’ve been looking for a simple way to use Go to write an internal development tool which is basically just a form with some buttons and text fields. I tried Gio, but had a hard time with wrapping my head around it. Right now I’m using wails and like it much better. This looks interesting and worth a look!

  • by jerf on 5/27/2024, 2:09:26 AM

    "Cross-platform: Leveraging FLTK[1] & Cocoa[2], Spot works on Mac, Linux, and the BSDs with plans for native Windows support in the future."

    I'd seriously recommend that you consider cutting this. Perhaps keep the lessons you've learned to retain future flexibility, but get good on one toolkit first. GUI toolkits, GUI bindings, GUI in general drowns you in details as it is, volunteering to drown in several different underlying toolkit's details may sound appealing because you may feel like you're growing your metaphorical market, but what you will almost certainly end up with is doing all toolkits badly instead of even one toolkit well, and that won't be good.

    We've all heard about how the first 90% is 90% of the work, and then the remaining 10% is another 90% of the work. GUIs make that look like hopeless pie-in-the-sky optimism, where the first 10% is 90% of the work, and then the next 10% is ten times the work, and then the next 10% is another ten times the work. Trying to be cross-platform will strangle you.

    However, based on my experience with some similar previous discussions, I don't expect you to immediately buy and agree with my arguments. What I'll really suggest then is to keep what I've said here in the back of your mind, and when you find you're staring down the three toolkits that rigidly require a three-way mutually contradictory way of handling rich text or something, then think back to this post and consider giving yourself permission to drop all but the best-supported and/or most popular underlying toolkit.

  • by iamcalledrob on 5/25/2024, 10:37:14 AM

    I have been looking for something like this in Go for a while. I think there's a real opportunity for Go to provide a great developer experience for cross platform UI due to how simple the build process is. Speaking from experience, half the pain of cross platform development is managing build complexity, which Go basically eliminates.

    I'm curious how you'll end up solving for cross-platform layout when native controls have different intrinsic sizes per platform?

    This is something I haven't seen solved super well in cross platform toolkits.

    Wishing you luck though.

  • by allanrbo on 5/24/2024, 8:31:56 PM

    Was looking for something like this some years back. Though I wanted Windows support too. Ended up switching to C++ to use wxWidgets, giving me small self contained binaries.

  • by felipefar on 5/25/2024, 4:18:04 AM

    I'm curious to hear your take on this: what's the advantage of following the virtual control tree approach compared to instead updating directly the controls that are displayed to the user?

  • by sandreas on 5/25/2024, 11:00:38 PM

    Looks great! Thanks for sharing.

    Would you consider listing the supported platforms in the readme? I think that would be a pretty interesting piece of information:

      - Windows
      - Linux
      - macOS
      - *BSD
      - Android
      - iOS
      - Web
      - Tizen
    
    Maybe like it's on flutter docs: https://docs.flutter.dev/reference/supported-platforms

  • by KingOfCoders on 5/25/2024, 3:57:54 AM

    I applaud your effort, but cross plattform with no Windows support?

  • by Heliodex on 5/24/2024, 11:58:54 PM

    If only I had known about this (or judging by commit history, if it existed) ~3 weeks ago. I've been saying for ages that either React ported to Go or a React-like framework for Go would be an incredible development experience, so this looks perfect (I used to be a big hater of React.js until I was enlightened by React.lua).

  • by Fire-Dragon-DoL on 5/26/2024, 4:10:24 AM

    Main problem is that when you release on desktop, a web version is usually desirable (except for very niche apps that interact a lot with the OS).

    Alternatively, something that targets many platforms, including mobile.

    I've been searching for something for quite a while and the closest is qt and react native, both painful choices for various reasons

  • by getcrunk on 5/25/2024, 3:53:49 AM

    Fltk supports windows. Will you be using another solution and that’s why u don’t support windows yet?

  • by ygnasygnoimqwb on 5/24/2024, 8:24:32 PM

    > runtime.LockOSThread()

    > https://github.com/roblillack/spot/blob/main/ui/init_fltk.go...

    Does this imply GOMAXPROCS needs to be set to at least 2?

  • by scosman on 5/24/2024, 8:28:27 PM

    Cool!

    What does building for cross platform look like? Would love if there was a command that produced my MacOs .app and Windows exe without me having to dive into package management/containers/signing headaches per platform.

  • by gloosx on 5/26/2024, 6:58:10 AM

    This looks really cool but a bit incomplete and messy without XML-like syntax sugar for composing component functions. Is it even possible to extend Go like the JSX?

  • by jakjak123 on 5/24/2024, 10:35:16 PM

    Very cool idea!

    If someone implements GTK I would absolutely use it, its just fltk is no fun in Linux world

  • by zem on 5/25/2024, 6:12:35 AM

    interesting that this uses fltk; I've seen very few language bindings to it

  • by andrewfromx on 5/25/2024, 9:03:33 AM

  • by ASalazarMX on 5/24/2024, 6:51:43 PM

    I don't know how to take this in. On one side, it's great to have a cross-platform GUI toolkit that's easy to use; on the other side, it feels like a React-like UI is contrary to the spirit of simplicity and resource efficiency of Go.

    I'm sure it has its perfect use cases, though.

  • by kdma on 5/25/2024, 10:58:07 AM

    Just for curioristy why did you adopot a react-like model and not implement react-dom as projects like react native do?