Looking through https://crates.io/category_slugs, I noticed that there's nothing for general graphical programs. There's a category for command line utilities, games, finance, scientific software, and text editors, but it's not clear how something like a terminal emulator or a graphical irc client would be categorized.
We have gui, graphics, and rendering for subtly different kinds of library crates that are used to create graphical applications, but nothing for graphical applications themselves.
This seems like an oversight.
As the rust gui ecosystem becomes more and more mature, this omission seems more and more glaring.
The contents of crates.io are primarily libraries, not applications — published “binary crates” are usually developer tools, often ones associated with a library. Those that are applications are mainly there to be installed via cargo install, a very limited package manager that cannot properly install graphical applications, because it only installs an executable and no supporting files, and on every desktop/GUI platform I know of,[1] such supporting files[2] are required.
I believe crates.io should not gain any further features suggesting that it is reasonable to publish applications there, unless and until there is a mechanism to install those applications properly. Until then, such applications should be distributed by the same distribution channels as applications written in e.g. C++ — distro package managers, app stores, downloading an installer, etc.
In my experience, there's a strong expectation that all rust crates are available on crates.io. There's also an incentive to start publishing right away, before anyone snipes your crate name.
Additionally, if this is the official position of crates.io, it should probably be documented somewhere, as nothing on the homepage or category page even remotely suggests that.
edit: nevermind, I mixed up a UI problem with metadata problem.
Being a graphical application is mostly orthogonal to the application's purpose. You can have a GUI for accounting, GUI for compression, GUI for scientific work, GUI for managing game mods, etc.
This raises question whether it's even useful as a category on its own. You wouldn't browse the category to find something specific – you don't look for "a graphical program", you look for something to solve your domain-specific problem that happens to have a GUI for convenience.
command-line-utilities and external-ffi-bindings categories have the same issue. They're cross-cutting categories that end up having all things for all purposes.
CLI/GUI, as well as std/no-std, sync/async would be good filters for any category.
It's also worth noting that the difference between an application and a gui widget is increasingly negligible with the existence of lib+bin crates. for example, alacritty is available as either.
Leaving it to be just a keyword leads to problems with ambiguities and inconsistencies, since there's no clear direction when to use which keyword, and there's no syntax checking rejecting mistyped keywords.
Having another categorization field in Cargo.toml would be excessive. Although some categories are more cross-cutting than others and would benefit from being presented differently, that's more of a UI problem.