Redo tags/categories

[madsmtm]

Work on fixing #21, by moving from a "tag"-based system to a "category" based system.

Relating to that issue, I've named the categories as follows:

1. Toolkit: Full lifecycle / batteries included.
2. Framework: Full rendering/layout/interaction, Rusty API.
3. Bindings: Bindings to non-Rust libraries.
4. Bring your own UI: [Still unsure about this one].
5. Utilities: Windowing, drawing, layout, ...
6. Tools: Packaging.

For now, I've enforced that a crate can only have one category; this may be too strict, but it helped me get an overview of the situation, and I think there can be value in defining the categories such that a distinct line can be drawn.

Additionally, I've tried to add an os field (should probably be named platform now that I think about it) that should give some indication of what platforms a given crate supports.

Finally, I'm experimenting with a technologies field, which would allow users to get a quick glimpse of what's happening under the hood:

• "native": Platform's native toolkit (on Linux, GTK is accepted as "native").
• "custom": Custom rendering and layout.
• "web": Uses web technologies.
• "gtk": Uses GTK.
• "qt": Uses Qt.

[dxenonb]

(tagging #82, which will be resolved by this)

• Hmm, I think with your framing of utilities, I would be happy to kick "bring your own UI". At some point in the future BYOUI could probably be summarized with a short write up explaining the choices you have to make and the types of crates you need to find or implement.
• Re: enforcing one category each, I think it is sufficient, and a good place to start at any rate, especially if we kick BYOUI

Re technologies, I think that's a great idea! My immediate thoughts:

• split web into HTML, CSS, flexbox
• "custom DSL" (non-HTML or non-CSS)

Re: "Toolkit" naming: might be good to run this by some folks to see if this name is clear. I have no personal objections, myself. I'll check with my local community if anyone has strong feelings.

What's the best way to support you in this? So far the diff looks good!

Do you think I should ask around for any design/UX brainstorming?

(FWIW: If you agree, I think this PR is shippable without any changes to the site map, - e.g., just grouping the crates under the category headings, under "Ecosystem")

[madsmtm]

this PR is shippable without any changes to the site map

I'm not sure what you mean? The "code"/templating part of the PR doesn't actually work yet, I have on worked on the organization of the data.

technologies

For this one, my own desire is to give people a quick glimpse of what basic trade-off the crate has made:

• Custom (rendering): Fast, Rusty (not strongly tied to something else, so a lot of innovation in developer experience can be done).
• Native: Accessibility, "look and feel".
• Web: Cross-platform, easy to get started (I already know a lot of web technologies and there's a lot of documentation out there about it).
• (I'm not sure GTK/Qt actually fit here).

I do think it is also desirable to know "what language will I be writing? Pure Rust? Some DSL inside Rust? Or will I be writing CSS/HTML/something else outside of Rust?

What's the best way to support you in this?

Being someone to bounce ideas off like you're doing right now is honestly great, just keep that going!

Aside from that, I'm envisioning some kind of "introduction" text for each category, possibly opinionated, and then we can show that on top of each ecosystem page, and then the crates below. So something like:

Bindings

GUI development in Rust is still young, and hard issues like accessibility is still work in progress ..., so another approach is to use an already established framework.

There are many possibilities here, as can be seen by the list of external framework bindings below, but if you have decided to go this route, we would currently recommend GTK because of it's huge community, and the ability to provide a fairly native UI on desktop platforms [or any other recommendation, just an example].

But if you or someone else would be up for writing that (or a draft of it), that'd be great!

[dxenonb]

this PR is shippable without any changes to the site map

I'm not sure what you mean? The "code"/templating part of the PR doesn't actually work yet, I have on worked on the organization of the data.

Apologies for the confusion. I meant, I am OK merging this with only minimal changes to the template, when the templating works. It is OK with me if the design isn't perfected in this PR, or if we don't add any new pages. (my "acceptance criteria" for this PR) (if you do decide to add new pages or change the design... that is also OK, but it could also be a second/future PR)

For this one, my own desire is to give people a quick glimpse of what basic trade-off the crate has made:

Ah yes, I see.

Aside from that, I'm envisioning some kind of "introduction" text for each category, possibly opinionated, and then we can show that on top of each ecosystem page, and then the crates below. So something like:

I'll try and get some copy for this in the next week.

(and thanks for your update in the other thread on your absence - no issue!)

[madsmtm]

Just found this blog post on build systems with some thoughts on what we're describing here as the "Tools" category.

[dxenonb]

Everything here looks pretty great to me - see comments for my feedback.

[dxenonb]

When I looked at this, I was confused where "extra" is coming from, until I realized this is where our "user data" frontmatter goes in Zola.

Do you know if there is a way we can import the metadata/front matter from a separate TOML file? I don't see an immediate way to do this, in which case... I'm not that worried about it.

If we can't separate the metadata easily, I'd add context about Zola to Contributing:

To submit a crate, add the crate to the relevant category's markdown file under the content/ecosystem directory (Toolkit, Framework, Bindings, Utilities, or Tools).

We are using Zola to generate the website: Zola renders a page for each of these files. The crate listing is provided as "front matter metadata" in these markdown files under the [extras] section. While the file is technically markdown, the front matter uses the TOML format (the same syntax as in Cargo.toml).

[dxenonb]

Maybe we should have a separate discontinued page; list some "historically significant/featured" crates as well as any others removed from the main pages (list would be chronological with optional "succeeded by" links, maybe grouped by the original type of Binding/Framework/Toolkit/etc).

[dxenonb]

Eek yea, if this was just an immediate mode library, it's somewhere between a tool and a framework, to me, in our current system of categorization.

But it links directly to the original C imgui via imgui-sys, and primarily provides a safe API with backends, making me comfortable saying "binding".

Does my logic check out?

[dxenonb]

GemGui is absolute Rust rewrite of Gempyre C++ GUI Library.

So, probably framework? (especially given that it looks like it packs your resources for you) It also falls under a web technology that supports the web platform.

[dxenonb]

Thanks for all your work and attention on this, and all things AWGY @madsmtm (the PRs, the issues... everything).

I've finally gone and written up some of the criteria/intro text I promised, along with some ideas for "official" criteria.

(And of course, please don't feel obligated to act on anything here on any timeline other than your own... I've certainly not been responsive on any timeline)

Wishing you a happy new year.

Frameworks

The Frameworks listed here are crates (often, suites of crates) or projects that enable developers to build GUI using Rust. Some frameworks target native APIs, others target the web or leverage web technologies like HTML & CSS. The bulk of these frameworks implementations are in Rust or are they are built around defining the GUI and event handling using Rust code.

Frameworks provide a large array of features required for every production GUI. However, unlike toolkits, frameworks do not aim to be end-to-end solutions. Their developers may not consider all things required for a production-ready project to be in scope, instead preferring flexibility to completeness.

Choosing a framework is a good choice when you require a great deal of flexibility or need to integrate a GUI solution into an existing project. If you're looking to hit the ground running with a more "batteries included" solution, be sure to check out AreWeGuiYet's toolkit listing.

To qualify as a framework:

1. the project does not qualify as a toolkit (e.g. because it is not end-to-end or considers some major GUI functionality out of scope)
2. the project is primarily written in Rust (or allows the user to primarily develop GUIs with Rust code)
3. the project provides substantially more than a safe API over a native GUI framework (making it a binding)
4. the project implements two or more big ticket features: rendering, event handling, layout, syling, custom widgets, A11y.

Bindings

The Bindings listed here are crates or projects that provide Rust APIs to existing GUI frameworks/libraries written in other languages.

GUI development in Rust is still young, and hard issues like accessibility are still a work in progress. Using bindings allows you to access more established ecosystems.

There are many possibilities here, as can be seen by the list of external framework bindings below, but if you have decided to go this route, we would currently recommend GTK because of it's huge community, and the ability to provide a fairly native UI on desktop platforms [or any other recommendation, just an example].

Projects qualify as bindings when they:

1. link to or use an existing non-Rust library for the bulk of their functionality
2. allow Rust developers to complete achieve some GUI related objectives
3. do not provide substantially more than a safe API over a native GUI framework

Utilities

The Utilities listed here are crates or projects that provide some GUI critical functionality, without being intended soley for a specific larger Framework, Toolkit, or Binding.

If you need complete flexibility or are writing your own GUI framework, these crates will provide critical functionality such as layout algorithms, color management, file parsing, rendering, and all things fonts. (this list is non-exhaustive!)

This section is not to be confused with Tools, which is intended primarily for programs (in/for Rust) that aid building GUIs. The crates and projects in this section are runtime-oriented or not useful on their own.

Projects qualify as utilities when they:

1. implement a very specific slice of functionality relevant to GUI (single concern)
2. are written in Rust!
3. runtime oriented, or not useful enough on its own to qualify as a tool
4. if developed for a larger framework, there should be a good reason it is relevant for users of other frameworks (or users building their own frameworks)

Keeping in mind, most utilities are 1-2 crates, rather than part of a larger suite of crates.

Tools

The Tools listed here are crates or projects (in Rust, for Rust, or very relevant Relevant to Rust) useful in developing GUI applications. This includes things such as build tools, packaging CLIs, and libraries intended for build.rs build scripts.

The criteria for tools is more subjective. Anything relevant to GUI development in Rust but not fit to be a runtime Utility can be considered a "Tool." If a crate is not necessarily runtime oriented, but also not complete enough on it's own to "feel like a useful tool," consider it a utility.

GUI Tool developers should find the Utilities section useful when exploring crates their tool can incorporate, whereas the tools listed here are for users wanting to build (and especially deploy) their GUI applications.