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.
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?
I'm curious what you would consider to be a better UI kit. Personally I think Material Design is the smoothest and most professional looking thing out there. Everything else seems too cartoonish or just overall less appealing to me.
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.
Not the OP, but I personally find it very flat, and very much lacking in contrast. I tend to find my eyes scanning and hunting for things all the time with Material Design.
Also not OP, but I too dislike Material. My main issue is that interactable controls don't stand out. Sometimes it takes me multiple seconds to recognize a button.
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.
It's too long for an HN comment. There are so many things to consider. The safe choice is probably to not use Material UI. Here's a nice article from the point of view of someone who decided against it. The comment thread is good too. https://medium.com/techtrument/bye-bye-material-design-acaeb...
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."
Fyne doesn't appear to follow the material ui guidelines very closely. Probably to its credit. Here's some screenshots: https://github.com/fyne-io/examples/
It seems to borrow the icons and some widgets, but not so much the container elements.
I think it works fine on a phone especially if you don't follow it 100%. On websites and desktops however I just really don't like it. Its hard to explain but the feeling is just bland and awkward.
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 :)
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?
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.
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.
No direct relation. This is more akin to Qt. It's an Application and GUI framework for Desktop. It draws its own widgets with a vector based approach as does every modern gui framework I believe.
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.
> 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.
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.
> 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.
> 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.
Qt is the industry standard for software in the computer graphics industry. It's definitely easy to write big applications with it and imho its very easy to work with.
> 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.
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.
> most notably text can neither be selected via keyboard nor mouse and rightclick doesn't work
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.
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/ doesn't actually contain any references to material design.
"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:
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.
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.
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.
> 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])
That's an example of bad documentation: the image shows all buttons without shadow, but then goes on to explain that contained buttons (the thing most people would call a button, as opposed to links etc) are "distinguished by their use of elevation and fill", with elevation obviously being represented by a shadow.
The rest of the page also always shows contained buttons with shadow, just that one picture showing them all together doesn't.
>> 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".
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.
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.
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.
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.
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.
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...
> 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.
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 :).
> 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 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.
I'm glad to see you're receptive to the shortcomings, not only in accessibility but other fields. In a world of arrogant GTK+ developers, it's refreshing not to be told "lol no, shut up".
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.
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.
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.
Safest bet may be to just embed Chromium or Firefox's engine respectively. Chrome may or may not be easier from what I've seen and should give fairly good cross platform support. Though should be modular, as any applications using it will pick up some bulk.
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)?
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 :)
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!
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...
> 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!
94 comments
[ 4.4 ms ] story [ 123 ms ] threadQt 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.
And does it use old-school stateful components, or new-school "reactive" components?
Lots of applications from DOS days (...and before) did that.
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 :)
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.
[1]: https://docs.enlightenment.org/efl/current/
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.
[0] https://www.fltk.org/
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.
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...
[2] https://material.io/design/environment/surfaces.html
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
[2] https://html.spec.whatwg.org/multipage/#toc-semantics
[3] https://www.w3.org/TR/wai-aria-practices-1.1/
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.
[1] https://www.microsoft.com/design/fluent/
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 :).
1: https://github.com/fyne-io/fyne/wiki/Vision
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.
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.
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!
https://blackrockdigital.github.io/startbootstrap-creative/
https://fyne.io/js/creative.js
[1] https://github.com/zserge/lorca
On a more basic level it comes down to whether you want to code pure Go or HTML/CSS as well...