search

vlang / ui

A cross-platform UI library written in V
MIT License
2.31k stars 155 forks source link

Base UI+UX model or resource for Generic UI + Linux/*nix (not macOS or Windows) suggestion #336

Open ylluminate opened 3 years ago

ylluminate commented 3 years ago

The work that the elementary OS folks are doing for release version 6 is quite impressive. There's a lot of consideration in everything UX related and it could be an excellent baseline or model / fork to follow for the default UI theme for V UI. This has been discussed before in context of the need to have a default UI implementation available and used in particular for Linux/FreeeBSD/etc. apps and simply as a baseline implementation before the fully tweaked out versions that match native macOS and Windows are implemented.

The following blog post is a good synopsis to understand the considerations and elements going into refinement and offers some entry point for the appreciation of this: https://blog.elementary.io/look-and-feel-changes-elementary-os-6/

It appears that they have a solid HIG (Human Interface Guidelines) that's not entirely dissimilar to what Apple did to ensure a cohesive and well respected UX in the industry.

The Granite library (with its accompanying assets), being LGPL3, appears to be compatible with V UI's GPL3, so that may be something that can be used directly to accomplish cohesion and a more efficient implementation in this respect as well vs coming up with everything from scratch.

NOTE: I am NOT talking about reusing actual code. I do understand that the code itself in Granite, for example, is NOT compatible with V UI, but only referring to assets (graphics) and guides.

dumblob commented 3 years ago

Just one thing I'd like to point out. The referenced blog post outlines solutions to some very painful problem Apple has with its UI libs. But Elementary actually solves it (unlike Apple) and provides an easy to use and quite thought through solution. That said, I'd even say, that Elementary has better UI guidelines (despite it being much smaller covering smaller number of cases) than Apple has!

ylluminate commented 3 years ago

After talking with Alex he has a concern that the elementary OS HIG + Granite foundation are not sufficiently compatible with the declarative UI methodology being used by V UI and therefore cannot be used. I was under the impression that this could be at least be largely repurposed or perhaps forked. We did see and discuss this interesting Unity-built prototype a year ago: https://www.youtube.com/watch?v=Yu_2e0LebNY

With this being the most recent (from 2 weeks ago) iteration of that: https://www.youtube.com/watch?v=lABT2zZcr2w

My goal in suggesting the elementary OS "Granite" foundation and/or HIG work is to facilitate a well defined target for a cohesive set of elements and considerations for a 0.1/alpha that can be easily customized or entirely replaced. Since we will have many themes (both a "Generic" one for general initial development and testing + Linux/*nix or V OS and native ones for macOS and Windows that emulate as nearly native look + feel (including keybindings) as possible), it seems reasonable to pick a starting point that's well defined and perhaps not as expansive as Apple's own excellent guide.

If this is indeed entirely incompatible with the declarative methodology and nothing can be salvaged from elementary's work, then sure, simply disregard this consideration. I'm not entirely convinced that this is the case, but I thought we should state this nonetheless.

ylluminate commented 3 years ago

Let me mention this since I failed to clarify (in that my mind was, at the time of initial writing, focused on assets and guidelines): I did not intend consideration for reuse Granite's actual code.

Sorry about that.

I could see a "fork" (sans any code) of the elementary OS HIG + assets (in Granite) fused with the DreamOS design concepts working for the "Generic Theme" as well.

dumblob commented 3 years ago

I read the whole elementary OS HIGs and there wasn't even one thing which would somehow prevent their use of any UI library I know of. So I'm really curious why elementary OS HIGs couldn't be used for V UI library apps.

Could someone clarify what the problem of V UI versus elementary OS HIGs could be? At best some counter-examples to get a grasp of what is meant by "not sufficiently compatible with the declarative UI methodology used by V UI".

dumblob commented 3 years ago

And if it's only about granite, then I say yes, it might be not fully compatible with the current state of V UI. But it's still full of very good examples how to approach those HIGs in practice on a library level. So I can definitely recommend granite for study purposes (at best by taking a look at some complex UI written with granite).

ylluminate commented 3 years ago

@dumblob I believe that this assertion of incompatibility is from my failure to initially indicate that I was not referring to code reuse. Mentally I was thinking about non-code assets + the HIG and it didn't cross my mind to better define this. I think pulling and and all non-code assets from any and all elementary OS libs/repos that could be useful in defining a homogeneous UI+UX would be useful. If we want to mix in or alter them to line up with that very interesting DreamOS Unity UI prototype, then that's also great, but yeah, I think using a well thought out guideline that is essentially macOS / iOS compatible is a winning proposition since this should also be usable to define simpler user experiences such as Windows, etc.