8 ms·
Fyne, a cross-platform GUI toolkit written in Go
- trentthethief 4y agoI really wanted to like it but the ui is very unappealing to me.
- syeare 4y agoI'd take a UI uglier than this and customize it rather than electron.js any day
- 0x20cowboy 4y agoSame. I encourage the project to get some UI / graphic designers on board, and do what they say. I mean, even just looking at the web site the spacing is odd, the animations are a bit all over the place, and it just looks slapped together. That kind of thing is totally cool for a cli tech product, but for something specifically supposed to be UI based… And the product screen shots have similar issues. Doing this stuff is very difficult so no shade intended - I’d love a de facto, nice looking, non cgo Go widget library. I wish them great success.
- moondev 4y agoLooks like it's possible to provide a custom theme, curious if there are more examples of this go run github.com/fynelabs/notes@latest
- httpsterio 4y agoI had a look at most apps built with it and I think it's perfectly fine. There was a lot of variability in how the widgets were used and styled so if something looks bad, I wouldn't attribute it to the library.
- IshKebab 4y agoI agree, though it's not as bad as something like FLTK. Also if you're writing Go there are basically no alternatives. Still, kind of boggles my mind why some GUI toolkit authors put so much effort into a project but don't do the relatively small amount of work to make it look nice so people will actually want to use it. It wouldn't take much more than fixing the margins and padding to be honest.
- ajwillia_ms 4y agoFor v2.3.0 (next big release) we have a UI refresh done by a graphic designer. Very exciting :)
- deleted 4y ago[deleted]
- jitl 4y agoWhat about this API makes it “modern”?
- jollybean 4y agoLiterally any clear and well defined UI API in 'Go' would be 'modern' relative to the arcane, byzantine messes that are out there. Even QT, a C++ standard is quite complicated. Android/Java is a bit bloated though workable. Flutter is 'modern' but quite opinionated and quite complex for what it needs to be.
- simion314 4y ago>Even QT, a C++ standard is quite complicated What is complicated about Qt ? You have widgets and events(called signals) , you have clear way to do layouts and powerful ways to extend things. My only complaint is not about the API but is abut C++, when I was working with Qt4 there were not good official or unofficial but stable bindings to memory managed languages. So personally for a quick side project I don't want to use c++, since is a side project some ugly and slow Electron app will be good enough and if I were on Windows I will probably do a C# Windows form app , or a Java Swing app.
- pjmlp 4y agoNowadays that isn't the way to use Qt. You would use QML, which is quite similar to JavaScript, alongside the quite nice designer tooling, while implementing in C++ the code that needs high performance. Additionally QML also gets compiled to native code anyway. Although on Windows only apps, I would also use C#. Java Swing is nice (yep I own the Filthy Rich Clients book), however it is basically stagnant since Java 8, minus bug fixes, HiDPI and Metal backend.
- simion314 4y agoThe UI part is not the issue, if you decide to use Qt you still need to do your "business" logic in c++ , then eventually you get some memory leak and have to setup tools to investigate what is the issue. What would be a great feature for Qt is to have a way to make the GUI with QML but implement your actual work in C#,python,Java. So you would need a way to connect the GUI with data types and functions from this languages. I remember Qt company tried at one point to offer Java,C#, Python official bindings but that effort failed, is probably hard. Maybe an alternative to electron would be a JVM based modern GUI framework, something maybe inspired from the best parts of WPF, MXML and QML. And I am thinking JVM because you have access to Java's big standard library to do desktop like things like file,network IO and also have access to the native OS if needed.
- syeare 4y agoSpent a solid minute trying to toggle the slider for "Toolkit" until I scrolled doen and realized it's just an icon
- jalino23 4y agohahaha
- deleted 4y ago[deleted]
- password4321 4y agoI feel like the repo is a better starting point. Mobile support is pretty cool! I also saw some demo of it running over the web in-browser, Blazor style, but I'm not sure where that's at these days. https://github.com/fyne-io/fyne https://github.com/fyne-io/fyne https://news.ycombinator.com/item?id=22291150 https://news.ycombinator.com/item?id=22291150 (2020) https://news.ycombinator.com/item?id=19478079 https://news.ycombinator.com/item?id=19478079 (2019)
- PhilippGille 4y agoTheir web driver is in technical preview as per the v2.0.0 release notes: https://github.com/fyne-io/fyne/releases/tag/v2.2.0 https://github.com/fyne-io/fyne/releases/tag/v2.2.0
- andydotxyz 4y agoYeah just install the latest helper (`go install fyne.io/fyne/v2/cmd/fyne@latest`) and run “fyne serve”. Your Fyne app will load in a browser via WASM or GopherJS (depending on browser).
- kretaceous 4y agoI explored couple of methods to develope desktop/mobile GUI with Go a few weeks ago. These are some of them: 1) Fyne (https://github.com/fyne-io/fyne) Popular. Native functionalities like trays, etc. Mobile app possible. Looks okay. 2) Gio (https://gioui.org/) Looks okay. Customisable. Tailscale Mobile app is made with this. 3) Wails (https://github.com/wailsapp/wails) Easy WebView for Go. Lacks native functionalities. 4) Sciter (https://sciter.com) embedded in Go Haven't explored much. 5) Giu (https://github.com/AllenDang/giu) Based on Dear ImGui. Doesn't look very polished. P.S. I settled on Gio for the mobile app and ditched the desktop app altogether.
- deleted 4y ago[deleted]
- socialdemocrat 4y agoWhy not Gtk? It looks quite nice and has a great GUI designer. I used to do UI mock-ups with Glade just because I thought it was so well thought out.
- deleted 4y ago[deleted]
- _2paq 4y agoAll the GTK4 apps I know all exclusive to their specific platforms. Most of them are being made exclusively for GNOME. Some of them have been made exclusively for elementary. I'm not interested if it's technically possible to create DE and WM neutral GTK4 apps. I'm interested if neutral apps are being made, which they aren't, whatever the reasons may be. I doubt it's a good choice for cross DE and WM apps on Linux, let alone cross platform apps.
- Santosh83 4y agoDoes GTK work for targetting mobile platforms, like your parent wanted?
- 4y ago
- sciel 4y agomark
- oefrha 4y agoI really tried to develop several cross platform GUI apps in Go, using various frameworks. The result was far from satisfactory. My advice: don’t bother, just use Qt. Or Electron if you can stand the resource usage. Or maybe Flutter, I have no experience with that; maybe I should give it a try.
- PainfullyNormal 4y ago> don’t bother, just use Qt. Or Electron... Qt and Electron are horrible options. What makes modern GUIs so complex that nobody's able to come up with a viable alternative that's simpler, faster and smaller? Whenever I talk to video game programmers, they scoff at the idea that UI is a difficult problem to solve. And they're right. They can get a computer to draw hundreds of complex 3d objects 120 times a second. Why can't we draw some text and a box 60 times a second so my window doesn't skip when I scroll?
- jb1991 4y ago> Why can't we draw some text and a box 60 times a second so my window doesn't skip when I scroll? Battery, for starters. If desktop UIs were all written like games, nobody would carry their laptops anywhere. Because they all be plugged in at home.
- hsn915 4y agoWhat do you think your screen is doing all the time? You can't blit to the screen once and then "freeze" it. Your computer/phone is blitting pixels all the time.
- jb1991 4y agoMost games are immediate mode graphics. An operating system cannot function efficiently if its graphics are not more like a retained mode system. There’s a big difference between the two.
- 4y ago
- gjvc 4y agoif it has a decent TreeView I'd be interested
- euroderf 4y agoTreeView is what I need too, and Fyne is (AFAICT) about the ONLY Go widget kit that includes one. And it is ugly too, but let's see what the Fyne 2.3.0 facelift brings :-D
- euroderf 4y agoI see iup-go too has a treeview, but it won't compile, complaining about having been compiled with another version of macos.
- ajwillia_ms 4y agoYes includes a tree :)
- deleted 4y ago[deleted]
- pjmlp 4y agoI think it looks rather nice, and could be used for an Oberon like inspired experience. Although since Go plugins support is stagnant, probably some kind of OOP IPC like D-Bus or gRPC, could be used for the concept of commands, viewers, gadgets and REPL. Not the same, but could be approachable. Anyway, nice work.
- Aeolun 4y agoAll of these are nice, but why do all of them use material design? That basically rules them out for me.
- hsn915 4y agoMaterial design a disaster in terms of UI and UX. - Flat UI - Lots of wasted space - No clear distinction between element types - Bland, lacking of color.
- danielvaughn 4y agoAgreed. I don't understand why designers like it so much. It's awful.
- chakkepolja 4y agoI believe it has to do with mobile support. Material design works well on mobile.
- andydotxyz 4y agoI guess most figure it is easier than creating their own design language as that is tremendously difficult (for engineers ;) ). Most figure if it is good enough for Android (and simile enough to Win10 and much modern iOS) it’s probably good enough for us.
- ClawsOnPaws 4y agoAs expected, same problem as all the other UI toolkits. Tried several of their apps, was able to use none of them with a screen reader or other accessibility tools. It's nice if you draw the UI directly to the screen, but you skip a lot of steps that OS vendors took to make sure your app can be used by as many people as possible. So always keep that in mind if you're going to use any of these GUI toolkits for your own project!
- andydotxyz 4y agoYea this is a big gap. It is planned but the task is huge. Once we have sufficient sponsorship or financial support in place you can be assured it will come.
- mwcampbell 4y agoWould you be willing to consider using a non-Go library via a C API for this? I'm working on AccessKit [1], a cross-platform abstraction over the various platform-specific accessibility APIs. It's written in Rust, and it doesn't yet have a C API, but that's planned. I'm aware that using cgo complicates build requirements, particularly on Windows, but it looks like you're already dependent on cgo on Windows (unlike, say, Gio). [1]: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit I know I haven't yet done much with it this year. Hopefully I'll start doing substantial work on this again in the next few weeks. Threads like this one remind me that the world is waiting.
- andydotxyz 4y agoYes, we have actually considered AccessKit in our discussions :)
- survirtual 4y agoPlease continue working on this. After years of work and having a novel backend infrastructure figured out for something that may have a lot of value for people, I have simultaneously been completely unsatisfied with frontend options — and I’ve tried nearly all of them. Accessibility is a major issue in almost all I tried, and closed source, vendor-specific UI options are not acceptable. The main one I’ve been very interested in these days is called Makepad. Also written in Rust, still early in dev, but they need a lot of help on the accessibility front and their codebase is trying to do everything else. But the techniques are what I have been looking for in a UI kit. Anyway, I imagine there are a lot of cases like theirs. The main issue is most of us do not have these accessibility issues. That domain knowledge needs to be collected and distilled into a framework that is open & simply covers most cases by its inclusion. Many JS frameworks have a lot of care in this regard, but their performance and dep hell make me want to avoid them (however tempting their ease of use may be). Long story shot: this is very much needed and when I have time I would be willing to contribute. Rust derive macros would be very powerful with implementing accessibility features.
- meling 4y agoCan Fyne be configured/themed to look like macOS Desktop app?
- jonathanstrange 4y agoNo, that's not possible. Not only that, Fyne makes some questionable layout choices in conflict with platform UX guidelines. For example, it insists on underlining multiline text edit fields to indicate focus, which looks horrible and confuses users.
- andydotxyz 4y agoOr doesn’t use OS components on any platform. Having a theme that makes them look similar is at best uncanny valley and at worst a huge waste of time for toolkit and developers. Every OS version update tweaks the design I’m an attempt to look new or unique - try to do that across the 5 or more desktop and 3 mobile OS UIs that it supports and you’ll see how every year it would be a full time job just adapting to those trends.
- jonathanstrange 4y agoIn case you're wondering, I've recently compared Go desktop GUI options[1], and there is also a new contender with new bindings to IUP[2]. The bottomline of my post is that Giu and Gio are good for small applications, Fyne is only okay for mobile platforms, and otherwise you should use either IUP (lightweight) or Gtk4 or Qt for full desktop apps. [1] https://slothblog.org/No_Good_Go_GUI.html https://slothblog.org/No_Good_Go_GUI.html [2] https://slothblog.org/IUP_for_GO.html https://slothblog.org/IUP_for_GO.html
- Tozen 4y agoThe problem with that is jumping around to the many different GUI toolkits, where many prefer or are trying to minimize the number.
- jonathanstrange 4y agoThe idea is that you choose the GUI toolkit that best suits your requirements, of course.
- davelondon 4y agoWill Fyne run on a Raspberry Pi Zero without a desktop environment? e.g. fullscreen with no other distractions other than the app? I'm making a touchscreen interface and I'd like something to boot directly into a UI with no other OS visible on screen...
- tyingq 4y agoIt appears to use glfw, so there's this: https://www.glfw.org/docs/3.3/window_guide.html#window_full_screen https://www.glfw.org/docs/3.3/window_guide.html#window_full_... But it would still be x11 or wayland underneath...it doesn't support direct Linux framebuffers.
- andydotxyz 4y agoWe test on rPi4 but you will need X or Wayland to boot the graphics driver and run your fullscreen app at this time.
- madeofpalk 4y agoIs this a "native app"?
- andydotxyz 4y agoIt depends on your definition. It installs and runs as native with the speed expected because it is compiled for the platform. It does not use the OS UI components for forms/buttons, but many built-in apps don’t even do that now so the definition is kindof changing I feel.