Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

111111111 #3938

Closed
ghost opened this issue Aug 1, 2024 · 2 comments
Closed

111111111 #3938

ghost opened this issue Aug 1, 2024 · 2 comments

Comments

@ghost
Copy link

ghost commented Aug 1, 2024

No description provided.

@actionless
Copy link
Member

@Elv13
Copy link
Member

Elv13 commented Aug 20, 2024

One extremely common use case in a tiling window manager is to remap 1-9

We willfully don't want to document specific use cases. In the past, there was some helper functions for common things. However, everybody definition of "common use cases" and how they should behave was different. They have been deprecated and most of them removed.

The API documentation document what the API is and what it does. We attempt to provide working code examples of how those API elements behave. The development doc has them for over 60% of the 10000+ API elements. All of them unit tested. This is very time consuming to write. We also aim to be consistent on this. The example show how it behaves, they do not attempt to show how to use them. Because everything is documented consistently, after a non-negligible learning curve, the users tend to be able to quickly figure out the "how" using the documentation.

Assigning floating windows to specific programs.

Yes, this is confusing. The problem is sadly not easy to document since different application implement their windows differently. Please use xprops to see what the application did and base your rules on that. There is no single answer that works for everything. Us attempting to do some kind of abstraction would be futile. There would always be more corner cases to cover. Chasing them all would result in unmaintainable code.

This is the docs on theming

The page you are looking for is https://awesomewm.org/apidoc/documentation/06-appearance.md.html . This is the list of all theme variables. Yes, some links are broken, I know. However, most work. From those links, click Click to display more and this will show the Used by: table. Click on those links to see the associated properties with the corresponding examples of valid values. Again, we cannot document how to make Awesome "pretty" because everybody's definition of "pretty" is different. What is called what is documented here https://awesomewm.org/apidoc/documentation/03-declarative-layout.md.html . Adding tutorial for how to skin every single elements would make the documentation too large and thus harder to navigate. We intend to document the behavior of everything rather than do tutorials.

This is the docs for awful.spawn [...] an infinite loading spinner.

This happens because the application does not implement the startup notification protocol properly. There is no way for us to detect that. There is doc on how to ignore it. A more modern fix would be to delegate this to systemd using cgroups. This will require some code and while on my todo list, I didn't do it yet. It would also only works for users of systemd, with all the political backlash this would cause. Gnome and KDE used to rely on the startup notification protocol, but have both since moved to cgroups. This is why more and more application ship with the broken startup notifications. Nobody complain anymore, so it doesn't get fixed.

@ghost ghost changed the title [Feature Request] Vastly improve documentation 111111111 Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants