Giters

areweguiyet / areweguiyet

A website built for the Rust community

Home Page:http://areweguiyet.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Tag suggestions

dxenonb opened this issue · comments

commented

Please let us know if you have any suggestions for tags! We should do a pass on all the crates currently listed.

My quick thoughts:

  • Soft real time suitable
  • Flexbox-like layout
  • Functional UI
  • DSL (these libraries use a custom DSL for layout or formatting)
  • Backend agnostic
  • Backend
  • Native
commented

Reviewing 2+ years later, documenting a rough thought that crossed my mind:

Define tags more clearly as "a checklist describing how a crate operates". Examples:

  • uses window abstraction written in rust
  • UI and style declared in Rust source files
  • Supports HTML
  • Supports CSS
  • Uses custom DSL for style, content, or layout
  • Uses platform native rendering (actually native)
  • 100% rust (only bindings are to native APIs)
  • Emulates platform native rendering ("native")
  • Supports multiple rendering backends (this is more generic) ("Backend agnostic")
  • Provides implementations for another crate ("Backend")
  • Targeting/supporting 30+fps soft real time
commented

Linking other discussion about tags/categories:

commented

Response to #84 (comment). In general I think the categories you outline there makes a lot of sense!

These three categories answer the questions "How do I/Can I build an app right now? And what % of the stack is Rust?"

  • full lifecycle, batteries included frameworks: they help develop/package/update your app (e.g. Electron if it was Rust)

Isn't this basically only Tauri currently? Though I guess it would be good to have more of such projects anyhow, so making them more prominent is valuable.

  • GUI frameworks: crate(s) that provide a full rendering/layout/interaction for some platform(s)

E.g. Azul, Druid, Dioxus, Egui, Imgui, Conrod, Iced, Relm, ...?

And in the platform-specific camp: Cacao, Slint, WinSafe/native-windows-gui, maybe yew?

Feels like all the interesting crates end up in this category, could consider splitting it up, perhaps roughly along the axes described in this talk by Raph Levien? Anyhow, still better than the status quo.

  • GUI bindings: crates that make it easy to use an existing non-Rust GUI framework

E.g. bindings for GTK, FLTK, Qt, Sciter, ...?

These three answer the questions "How do I, uhh, do UI-ish stuff, in Rust?":

  • BYOUI (build/bring your own UI): crates that lack one or more major parts needed to build a functioning app, but could be key if you're building your own framework (e.g. webrender, HTML/CSS rendering related crates) or integrating in a complex existing application

Hmm, I'm not sure this one is that interesting? WebRender and such crates are not really something that the vast amount of users would want to ever touch? Probably more interesting to group it with the below category.

  • GUI-relevant crates: e.g. fontdue, wgpu, winit, stretch, bindings to low platform level APIs

Agreed.

  • GUI-relevant tools: tools that help ship/design/packaging Rust apps, but aren't linked in an executable

Agreed, especially the "packaging" part.

Separately from these categories, I think having a set of "supported platforms" would also be useful? Perhaps listing every platform it supports, or maybe we can keep the split at "desktop", "web" and "mobile", since that is usually what users would be interested in knowing? And at least fairly usually, it's easier to make a library that works for one of those three than make something that works for all of them.

commented

Separately from these categories, I think having a set of "supported platforms" would also be useful?

Agreed, as I'm writing this... this feels like the biggest first question for anyone.

Re: Full lifecycle

Indeed, it may only be Tauri - I think the idea is, we want to choose categories around an "ideal ecosystem." If there is only one framework in a category, then the user quickly sees that the ecosystem is still immature! (we should include some copy explaining that)

Feels like all the interesting crates end up in this category

The categories I listed would definitely be not evenly distributed, for better or worse.

I imagine, we want to be like arewegameyet, but instead of the landing page showing different game engine modules, our landing page shows these different categories (and maybe.... some featured or most used frameworks, if we can fairly do so). Then, within each, like you say, we split them up.

I am unsure if each category would have the same sub-categories - for batteries-included-frameworks, it might just be platform support, and this category would always be smallest. If it is really lop-sided, maybe we display all batteries included frameworks on the homepage, then a section with the sub-categories for "mid-stack" GUI frameworks, then a section that links to tools and utility crates.

Hmm, I'm not sure [BYOUI] one is that interesting?

As a game dev, it is my favorite 😅.

  1. I'm going to explain below how my brain is grouping projects... maybe it will suggest better names for categories. I'm struggling with exact criteria, at any rate.
  2. When we're "finished" here, we likely have to document our choices/tagging rules... Do you think a CRITERIA or ORGANIZATION markdown file would suffice?

In the web world, I picture something like this:

  • Category 1 (complete full lifecycle solutions): Electron, Next.js, Nuxt.js, (Flutter?, Angular?)
  • Category 2 (complete projects that meet all your UI needs, but don't require tooling): React, Vue
  • Category 3 (BYOUI): the web components API
  • Bindings: N/A
  • plus Tools and Utility libraries

And then for Rust, my brain is grouping things like this:

  • Category 1: Tauri, Slint, Dioxus
  • Category 2: Azul, Druid, Iced, maybe rui, (and Relm, because it implements it's own component system over GTK+, right?)
  • Category 3 (BYOUI): Imgui again?, Iced's backends?, WebRender, conrod
  • Bindings: [...]
  • plus Tools and Utility libraries

My realizations:

  • we still want to allow a project to appear on multiple pages/categories
  • pinning down criteria for the categories as I originally posed them may prove impossible...

But at any rate, I see our mission as trying to display things in terms of the level of control and practicality.

E.g., as a project manager, you start by only considering Category 1 solutions. Category 1s at a minimum provide a component model or DSL; if it takes over your build pipeline, it is also automatically C1.

If you are a stubborn NIH hobbyist, making a game, or integrating a UI in a complex existing application, Category 1 is generally unsuitable because it's too opinionated.

In Category 2, again there are some high level crates, some that provide DSLs or component abstractions, but you wouldn't expect to deal with writing your own layout algorithms, parsing and managing loaded fonts, etc.

But, defining Category 2 gets annoying, because WinSafe and Imgui seem much lower level than say Relm, Druid, or Iced...

A binding (Relm, Cacao, WinSafe) is also Category 2 if it implements any higher level abstraction than the underlying API. (otherwise, we relegate bindings to their own category... because platform APIs suck, Qt and GTK+ are losing to web, etc)

And then Category 3 is essentially anything that "orchestrates something" - WebRender and perhaps some of the backends for other libraries like iced would fall here. I would be open to kicking C3 for now, since they also fit as utilities. (My motivation to highlight the existence of C3 is because it's another place where the ecosystem is lacking... Lots of people probably want to design their own app architecture, but don't want to fiddle with wpgu, or all the intricacies of input)

commented

Agreed about documenting criteria, don't know what is best here, a CRITERIA.md sounds fine to me.

Yeah, I feel like the boundary between category 1 & 2 is fairly well defined, whereas category 3 is less so. I'll try it out in a PR, and then we'll see how wel the categories fit the current crates.

commented

I have a few requests for tags.

embeddable

Which means that you can use it in your game [engine]. This would help gamedevs figure out their choices if they wanted to add UI into their game. eg: egui. OTOH, something like gtk-rs (and its variants) would take over event loop and not allow us to embed them.

dynamic or runtime UI

Allows you to construct widgets or ui components at runtime. This will allow plugins/scripts to dynamically create widgets at runtime and add them to the window. some gui crates rely on traits for widget functionality and Any to identify a widget's type. But it means that dynamically created widgets don't have a unique type ID (Any). Same goes for crates which use DSLs, but don't provide a runtime interpreter for those DSLs. eg: slint provides a dynamic interpreter for its DSL to enable dynamic widgets. But i think crates like qt will statically compile qml.

Multi Window

supports launching multiple windows within the same app/process. eg: fltk. as a counter example, egui/eframe only support a single window by default.

Context Menu supported

if the gui has proper support for menus/context menus. Slint UI, for example, doesn't support context menus yet slint-ui/slint#38 . I know its kinda arbitrary, but i think a gui that supports context menus and a gui that doesn't are at different maturity levels imo.

Immediate vs Retained mode

Obvious.

commented

Agreed that most of these can be useful, see also my draft PR for changing the tag system to categories instead.

Immediate vs Retained mode

I disagree that immediate vs. retained is obvious, there's a whole spectrum in between that - I would link to a blog post here about it, but I can't seem to find it now...

commented

I disagree that immediate vs. retained is obvious

I meant that the reasoning for displaying the tag is obvious. Not that its easy to split crates into one of them. Most crates like egui, imgui, yakui, fltk, gtk, qt, flutter etc.. fall into only one of the categories. For more mixed mode crates, we can have a new tag called mixed mode, or we can use both tags to represent that fact.

Maybe we should define what tags and categories are.

  1. I assumed tags are similar in functionality to keywords on crates.io eg: https://crates.io/keywords/imgui . They allow us to add hashtags, which allow us to "group" a bunch of crates without any particular structure.
  2. categories are similar to categories on crates.io https://crates.io/categories/gui , which provide a clear hierarchy like a tree. eg: gui -> rendering -> skia, here skia belongs to rendering category which belongs to gui category.
commented

Request for tag: tray icon / menu support.

So far I've found Tauri and https://crates.io/crates/tray-item support cross-platform tray icons & menus. Is anybody aware of any others?