Fyne: Cross-Platform GUI in Go Based on Material Design
github.com
github.com
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/ doesn't actually contain any references to material design.
[1] https://raw.githubusercontent.com/fyne-io/fyne/master/img/wi...
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...
See any of the (many) "Learn More" and "View All" buttons.
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
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.
> 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
Links and buttons have significantly different representations in accessibility, right-click, and keyboard behavior.
The rest of the page also always shows contained buttons with shadow, just that one picture showing them all together doesn't.
> It looks much closer to Microsoft's "fluent design".
It's a bit of a digression, but Fluent Design (esp. 2.0, but even 1.0) actually has very similar requirements of light, surfaces [materials], and casting shadows. It's a more nuanced approach than Material Design, which can somewhat be summed up as Material Design imagines the application as a stack of paper and cardboard and Fluent Design has both a subtler concept of "materials" (not every thing needs to be obviously stacked like a three-tiered 2.5D layer cake when displayed in 2D) and a broader concept of "materials" than Material Design (Fluent throws in things like glass-like parts, "acrylics", glinting metal bits, etc).
I understand what you probably meant that it looks like Microsoft's Windows 8.x-era "modern" designs, but I find it useful to point out that Fluent Design and Material Design have nearly converged at this point and Fluent Design is a lot more like Material Design than people think. (To the point where I'd argue today that a lot of the best Fluent Design stuff is better at Material Design than Material Design stuff.)
Does this not sound almost exactly like the Material Design quote above? [1]
> The physical world is our vocabulary. Fluent speaks in light and shadow, in spatial dimensions, in the weave and fold of fundamental materials.
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.
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.
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.
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.
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.
Of course YMMV, but i wouldn't discount it
FLTK [0] might fit some of this, at the cost of being somewhat ugly.
I thought Red was just a weird language for making UI.
From their main page:
> It has been a tough year 2018, filled with roller-coasters and instability. The constant dropping of the crypto markets has forced us to change our plans pretty much every three months, in order to cope with that market uncertainty and our diminishing means. Though we have taken measures to ensure the proper funding for Red project for the next few years, so no worries on that side. All that has slowed down work on Red's core and even our new C3 language.
Sciter( https://sciter.com )/Go (https://github.com/sciter-sdk/go-sciter) has pretty compact API and is of 5mb of size. Yet full set of basic input widgets including WYSIWYG editor and print/print-preview. Yet H/W accelerated graphics with support of Acrylic and Vibrant theming: https://sciter.com/blog/page/2/
Are you referring to text inside a text input? or some generic label? If it's labels check to see if they have an flag/option for this, but i'd guess that traditionally GUI library's gtk, winform, etc... have never defaulted to allow text to be selected or right click, but can be enabled with certain flags are set.
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 :)
Qt and GTK I could see being seen as 'cartoonish' because the default themes on many distributions are fat, shiny, bubbly, and look like they firmly belong in the 2000s.
Cocoa, maybe because of the vivid blue? Or that person hasn't seen Cocoa since before they moved away from the glowing blue bubbles, although I think they still look nicer than Material.
Apart from that, I simply dislike the look. It oft reminds me of Windows' Metro due to the sharp edges and corners. I'd prefer Apple's UI design over Metro although I am a Windows / Linux user.
One more thing, looking at Android apps, they sometimes use many different color tones without any underlying meaning. Or such an obscure meaning, that I still struggle understanding it.
As for the vitriol, here's a quote from the comments on the above post:
"As much I agree with you about what it has given to the community, as I disagree about not being fair to criticise it. Every creation should be criticised, especially if it’s unquestionably used by millions. Otherwise we won’t get anywhere. Criticism is not bad, even if it is done harshly. Especially in the age of corporations and their visually subliminal effects on an entire civilisation, I cannot possibly promote discouragement to criticism like you do."
It seems to borrow the icons and some widgets, but not so much the container elements.
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 :)
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!
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
For these projects, accessibility is always coming at a later date, never baked in right from the start.
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.
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.
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 :).
I think you've inflated the expectations by creating a 1.0 release, that's a point where you'd expect things like accessibility to be included. Had it still been 0.x then you'd get a lot more leeway on missing features.
It would also be great to list these limitations on the main page, anyone that finds those limitation important can then avoid it, they'll be a lot less annoyed than someone who invested a lot of time learning to use Fyne only to discover the limitations.
And does it use old-school stateful components, or new-school "reactive" components?
Lots of applications from DOS days (...and before) did that.
On a more basic level it comes down to whether you want to code pure Go or HTML/CSS as well...
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.