
Fyne: Cross-Platform GUI in Go Based on Material Design - theBashShell
https://github.com/fyne-io/fyne
======
themacguffinman
Congrats on releasing, that's a huge feat. A Go GUI app is an interesting
concept, it definitely has compelling advantages like single binary targets
and inherently cross platform code.

I do take issue with the repo description "Cross platform GUI in Go based on
Material Design" though. Looking on the screenshots in the README (eg [1]), I
can't see how this is actually based on Material Design, other than using some
material design icons. The widgets don't even follow the basic spirit of
Material design [2]:

> Material Design UIs are displayed in an environment that expresses three-
> dimensional (3D) space using light, surfaces, and cast shadows.

It looks much closer to Microsoft's "fluent design".

Maybe the repo description was accidentally left unchanged? It's weird that
the public website [https://fyne.io/](https://fyne.io/) doesn't actually
contain any references to material design.

[1] [https://raw.githubusercontent.com/fyne-
io/fyne/master/img/wi...](https://raw.githubusercontent.com/fyne-
io/fyne/master/img/widgets-light.png)

[2]
[https://material.io/design/environment/surfaces.html](https://material.io/design/environment/surfaces.html)

~~~
tyingq
_" Material Design UIs are displayed in an environment that expresses three-
dimensional (3D) space using light, surfaces, and cast shadows"_

Somewhat amusing because my biggest issue with Material Design is buttons I
don't know I can click, because they are flat and have no depth or shadows:

[https://storage.googleapis.com/spec-host-backup/mio-
design%2...](https://storage.googleapis.com/spec-host-backup/mio-
design%2Fassets%2F1rI63_05lNHyMtSwrnzXJ1Erg0TbkSDTY%2Fbuttons-types-all.png)

~~~
wongarsu
People for some reason always think just because things are flat in material
design they shouldn't have shadows. Or maybe it's just people calling lots of
things material design that really aren't.

~~~
tyingq
Maybe taking cues from the official docs. My picture is from the Material
Design website.
[https://material.io/design/components/buttons.html#](https://material.io/design/components/buttons.html#)
(scroll down to types)

~~~
fastball
Most of the buttons on that page have a shadow though...

~~~
tyingq
Okay then, the buttons on their home page have no shadow:
[https://material.io](https://material.io)

See any of the (many) "Learn More" and "View All" buttons.

~~~
peteretep
In that case they have outlines, and are clearly buttons?

~~~
dmitriid
Design flexibly -> Learn more. It's a link (hover over it). For some reason
it's displayed as a button.

Develop across platforms -> platform links. All links are links.

Collaborate seamlessly -> View Tools. It's a link (hover over it). For some
reason it's displayed as a button.

Further down the page.

Applying typography -> Learn more. It's a link (hover over it). For some
reason it's displayed as a button.

Applying typography -> Related -> Typography. It's a link. But it's displayed
as plain text, and you wouldn't know it's a link until you hovered over it.
And even then the only clue is cursor changing to pointer (if your status bar
is turned off, good luck figuring out it's a link).

What's new -> Develop -> Cards. It's a link. That looks like plain text.

\----

And that's the main problem with anything coming from Google. Their pages and
designs are wildly inconsistent and contradict their own guidelines. ANd
sometimes it looks like they are implemented by the main character from Split.

My favourite example is is their Google Maps "design":
[https://pbs.twimg.com/media/Dq2_soxWsAEqKWo?format=jpg](https://pbs.twimg.com/media/Dq2_soxWsAEqKWo?format=jpg)

~~~
codetrotter
Regarding links vs buttons, when you talk about the difference between these,
are you referring only to “a” vs “button” HTML elements or something else?

That’s an implementation detail. I often use anchor elements and style them as
flat buttons.

Or are you referring to whether clicking a button triggers an action on the
page vs navigating your browser elsewhere?

To me a flat button is a design element that I use for actions that I want to
call out to the user. These actions could be either on the page or they could
be browser navigation triggers.

For example, to me a link to “learn more” about a product can legitimately be
styled as a flat button in many cases.

That being said, flat buttons need to be used correctly. And I think material
design, at least in the way it has been put to use in most products, is
neither aesthetically pleasing nor intuitive. But flat or “flattish” design
can work especially well for buttons and links that you want to call out
without having them totally steal the focus.

For example I am currently working on a tiny side project creating a countdown
timer for pitch rehearsal, pitching, talks and presentations, for the person
on stage to look at. It is intended for desktop use only currently. It’s a
work in progress and I’ve not yet implemented the functionality fully so I am
hesitant to link to it yet. Anyway, in that side project I make use of flat
buttons for both some on-page actions and for a link leading to another page.

~~~
dmitriid
> Regarding links vs buttons, when you talk about the difference between
> these, are you referring only to “a” vs “button” HTML elements or something
> else?

> That’s an implementation detail.

It's not. These are semantically different elements.

> For example, to me a link to “learn more” about a product can legitimately
> be styled as a flat button in many cases.

"Many cases". What cases might that be, and what is the exact difference
between a link to "Learn more" and a link to "Related -> Typography"?

Funnily enough, material design guidelines state the following:

\--- quote ---

Buttons. Usage. [1]

Buttons communicate actions that users can take. They are typically placed
throughout your UI, in places like:

\- Dialogs

\- Modal windows

\- Forms

\- Cards

\- Toolbars

....

\--- end quote ---

> That being said, flat buttons need to be used correctly.

Indeed. <a> means a link to a different page, or a place on the same page.
<button> means an action. This is especially true for assistive devices. <a>
and <button> behave and interact differently with the content around and
inside them (see 4.5.1, 4.6 and 4.10.6 of the HTML Standard [2], and 3.13, 3.5
and 4.3.4 of WAI-ARIA [3])

[1]
[https://material.io/design/components/buttons.html](https://material.io/design/components/buttons.html)

[2] [https://html.spec.whatwg.org/multipage/#toc-
semantics](https://html.spec.whatwg.org/multipage/#toc-semantics)

[3] [https://www.w3.org/TR/wai-aria-practices-1.1/](https://www.w3.org/TR/wai-
aria-practices-1.1/)

------
PhilippGille
I tried it several months ago and some basic things still don't work, most
notably text can neither be selected via keyboard nor mouse and rightclick
doesn't work either. The scroll bar doesn't work. I got a "panic: runtime
error: index out of range" during some interaction with the fyne_demo.

It was similar when I tried it the last time. I reported the bugs and most got
resolved quickly by the maintainer, but in the current state I wouldn't
recommend it for anything serious.

Sadly, there aren't many _well-maintained_ GUI libraries for Go. And even less
that don't have dependencies on something like GTK or that don't use HTML and
a web view.

I wish the author best of luck with this project, I'll check it out again in
half a year or so.

~~~
marmaduke
> And even less that don't have dependencies on something like GTK or that
> don't use HTML and a web view

Most GUI libs supporting all the typical stuff are gonna be fat like GTK or
suffer from underwhelming API... or do you ha e a counterexample (Id like to
know)?

It seems like it would be neat for all these non C/C++ languages to band
together to produce a reusable GUI runtime which can be operated via RPC... or
declarative YAML. If everyone didn’t need to rebind all of Qt we would surely
have GUIs for even the most niche languages.

~~~
jstimpfle
> via RPC... or declarative YAML.

or CORBA...

More seriously. I'm not too familiar with Qt, but when I had to do a project
in it I really hated how anti-modular it was. While it gets high praise from
many people, I don't think it's possible to write sane software in it. It's
bloat. Even though MFC (which I have to fight currently) is probably worse.

Instead, what we need is a simple API with opaque handles and C function
calls. No fancy OOP or macro preprocessors. Simple OpenGL style. At least
regarding portability, OpenGL made sane choices I think.

Immediate Mode GUI (IMGUI) has been a trend in the last years, and there are a
few popular libraries like DearImGUI, but my impression is they are optimized
for quick-and-dirty work. It seems that control and clarity is traded away for
small local reductions of keystrokes.

~~~
adrianratnapala
> Instead, what we need is a simple API with opaque handles and C function
> calls. No fancy OOP or macro preprocessors. Simple OpenGL style.

Something like the enlightenment foundation libraries might be what you
want[1]. I haven't tried it out properly, but I liked the look of it from the
docs, it's a C api and moderately minimalistic.

However, even with C APIs, all these things end up with something like "fancy
OOP" (after all, even Gtk is a C Api). That's because GUI widgets seem to be
one of the few places really well suited to OO ideas like inheritance and non-
trivial getter-setters.

[1]:
[https://docs.enlightenment.org/efl/current/](https://docs.enlightenment.org/efl/current/)

~~~
flukus
> However, even with C APIs, all these things end up with something like
> "fancy OOP" (after all, even Gtk is a C Api). That's because GUI widgets
> seem to be one of the few places really well suited to OO ideas like
> inheritance and non-trivial getter-setters.

How much of the GObject system is there for the benefit of Gtk and C
developers and how much is there for interop with other languages and gui
builders though? Programming against the C API it seems to be very much not
OOP, you're always casting to a base class to call methods on that level, it
doesn't appear that the OO system is used much internally.

~~~
pjmlp
Xlib Athena Widgets, OpenLook, and CDE were also pretty much OOP in C.

------
nyrulez
I like it.

But as a new user I have some feedback: For a GUI framework, I hardly see any
screenshots, videos, list of widgets and so on. I want to see how deep the GUI
framework goes compared to my other choices. I think it fails to answer the
most pressing questions any first timer would have. Even a FAQ would be really
useful.

The list of features is quite information-free, nothing specific from a
developer's perspective.

I know focus is on the code here, but would greatly appreciate some more
visual documentation before anyone dives into the code :)

~~~
genericone
Also what I noticed, very few visual examples on the main website, was turned
off fairly quickly, is this what they want? To filter out developers like me?

~~~
bovermyer
You seem pretty quick to assume malicious intent behind a design choice you
disagree with.

------
ebg13
Congratulations on the 1.0 release, but...and I hope you don't take this the
wrong way...why would I ever want to use material design if I don't have to?
IMO everything made using it is a UX nightmare, looks awful, and treats the
user worse than not using it.

~~~
thebruce87m
I can’t seem to see any screenshots of the framework, but does Material Design
specify eye-searing white as the background colour or are there other options?

~~~
jimjimjim
You can specify light or dark modes/themes. The github page has examples of
both.

------
photonios
First of all, congratulations on shipping! That by itself is quite a feat.

There's lots of valueable feedback in this thread. Don't get discouraged by
it. It's an interesting project in its early stages and it has a lot of
potential. Keep it up, we need more people like you :)

------
brute
> Fyne ships with two themes by default, "light" and "dark". […] The default
> is dark

As someone who uses dark-themes for absolutely everything, which sometimes
requires quite some hassle (I am looking at you Slack), I welcome the trend to
offer a dark theme next to a light one. And having dark as default is even
better. Thank you!

------
ctoth
No mention of Accessibility so I am kind of assuming any software you write
with this will be totally unusable for those that use screen readers, speech
recognition-based controls, etc.

~~~
tyingq
I assume since it's using OpenGL that even more mundane stuff, like "select
text", and "copy" might not work.

Edit: Yes, appears to be an issue, but it does sound like they plan on making
it work: [https://github.com/fyne-io/fyne/issues/67](https://github.com/fyne-
io/fyne/issues/67)

~~~
zapzupnz
Far too many of these sorts of toolkits are planning to make accessibility a
thing when systems' native toolkits do it out of the box and integrate well
with integrated and commercial accessibility software.

For these projects, accessibility is always coming at a later date, never
baked in right from the start.

~~~
andydotxyz
Unfortunately it is a matter of hours in the day. Accessibility relies on
things like focus handling that are just not ready yet. Maybe we released too
early or maybe it was sensible to get a basic but solid release together to
build on. I expect that time will tell.

~~~
zapzupnz
For people who don't have any particular accessibility needs, time will tell.

For those of us who do, time has told us _again_ and _again_ and _again_ and
_again_ and _again_ , and we're kinda sick of time telling us to just hold
tight when everything we need is right there in the native frameworks.

~~~
andydotxyz
I’m sorry for the frustration. I agree that these things should not be put off
indefinitely. If we are able to get the project to a place where there is some
commercial support then it gets much more likely that we could make this
happen.

Every project has to start somewhere and as you can tell from this comment
page there are many groups of users who feel we have not met their
expectations...

~~~
mwcampbell
> Every project has to start somewhere and as you can tell from this comment
> page there are many groups of users who feel we have not met their
> expectations...

I imagine that level of criticism must be demoralizing. (That's why I didn't
pile on, though I've been vocal about accessibility on similar threads about
other toolkits.)

Just so I can understand where you're coming from, what's your motivation for
developing yet another custom toolkit, despite all the challenges and all the
table-stakes requirements that haven't yet been met? There must be some reason
you feel this is a worthwhile use of your time, but I don't understand what it
is.

~~~
andydotxyz
We’ve tried to share the aims of the project in the wiki[1].

Basically having seen the revolution in usability, software design and raised
expectations on mobile it was frustrating that desktop had stagnated. Having a
toolkit that was slim, easy to learn, cross platform and sweet looking seemed
like a worthwhile challenge :).

1: [https://github.com/fyne-io/fyne/wiki/Vision](https://github.com/fyne-
io/fyne/wiki/Vision)

------
lazyjones
Some critique: you talk about a cross-platform GUI "for the desktop and
beyond", but what platforms does it support? After seeing a mobile phone on
the title screen, I expected at least some info about mobile support, but
apparently it's desktop-only at this time. Some typical platform icons would
help very much in avoiding confusion.

~~~
andydotxyz
A fair point. At this time it is desktop only but the design of the API does
not limit this. People are looking at mobile and web drivers but this will be
a fair distance off I expect.

------
qwerty456127
Cool. But how well does it integrate with the OS and screen readers? "We use
OpenGL" sounds like it might have problems with this part.

~~~
andydotxyz
At the moment that is lacking - we intend to add it in a future version as
accessibility is important

------
smaddox
Does this do minimal updates, or does it rerender the whole window every
frame?

And does it use old-school stateful components, or new-school "reactive"
components?

~~~
analognoise
Just as a point of reference: redrawing the whole screen when something
changed is about as old a concept as you can get.

Lots of applications from DOS days (...and before) did that.

------
sansnomme
Congrats on shipping! It looks amazing, do you plan to support Material Design
2.0 too? Also performance-wise, how does this compare to Flutter (which uses
Skia underneath)?

------
nixarn
Awesome job! A super simple way to create crossplatform Go GUI apps, just want
I want!

------
johnisgood
Do I want lorca[1] or fyne? I know that they are different, but which one
would you go with and why?

[1] [https://github.com/zserge/lorca](https://github.com/zserge/lorca)

~~~
andydotxyz
Well the obvious reason would be if your users may not have Chrome installed?

On a more basic level it comes down to whether you want to code pure Go or
HTML/CSS as well...

------
napsy
I tried the included demo a bit but it seems the code is fairly unstable. A
couple of clicks here and there and the program crashes. But it looks really
promising!

~~~
andydotxyz
Can you help us and report the issue on GitHub please? There must be something
different about your interaction or setup as the developers have not seen that
app crash in a long time...

~~~
epaga
Probably this -> [https://github.com/fyne-
io/fyne/issues/161](https://github.com/fyne-io/fyne/issues/161)

~~~
andydotxyz
Thanks, I think there is a patch nearly ready for that, will roll out a hotfix
as soon as that is done and I expect a 1.0.1 in a few days

------
steve_taylor
Interestingly, the Fyne website uses Bootstrap rather than one of the many
Material Design implementations.

~~~
benbristow
It's a free theme

[https://blackrockdigital.github.io/startbootstrap-
creative/](https://blackrockdigital.github.io/startbootstrap-creative/)

[https://fyne.io/js/creative.js](https://fyne.io/js/creative.js)

------
bnolsen
Not bad but still by and missing features like tabbing between elements.

------
happppy
Great work. I wanted something like this in GO for desktop application
development.

------
qwerty456127
Does it have tree views and data grids? Does it have HTML renderer view?

~~~
andydotxyz
None of those are in yet. Tree views and data grids require a data binding API
that we have not yet decided on. HTML view is going to be difficult on Linux
as we don’t want to bring in GTK or Qt - but we will get there.

~~~
qwerty456127
Great to know you are considering these. Introducing these will make Fyne a
real Thing.

As for the data binding API - sure, this is an extremely important part to
architect so it will be both easy/concise and flexible. Yet, IMHO, tree and
grid views are vital for practical use. I can't easily imagine an app I could
make without these.

As for HTML view - having a full browser widget like Qt WebView would be very
cool but it's not a primary necessity. A simple HTML renderer able to display
a plain HTML document without user inputs and without JavaScript (just
paragraphs, lists, tables and pictures, some basic CSS for text formatting
perhaps) would already be extremely useful.

~~~
andydotxyz
For the simple text markup views we will support markdown as it has those
features. After that we could consider HTML...

~~~
qwerty456127
Great. But please don't forget to support ways to define where a line of text
should never be broken (i.e. nbsp) and where it always should. Many markdown
implementations don't support the standard double-space notation so you have
to use the html br tag instead.

------
qwerty456127
i/? message box background icons look ugly.

------
fuddle
Looks interesting. How does it compare to Electron?

~~~
jrockway
It doesn't ship Chrome, for one thing.

~~~
analognoise
Wait, you mean to tell me you can get "HELLO WORLD" on screen without carrying
around 100MB of "app" and 10 million lines of browser?

~~~
neop1x
...and develop without "npm install" of 2 GB of dependencies?

