Your idea
Here is my take on some things you may want to address before submission into GNOME Circle.
- Ensure all strings in your app adhere to GNOME's writing style and typography guidelines. I noticed some strings like in menus or in ActionRows in the preferences dialog weren't always using header capitalization.
- Try to make the app as adaptive as possible, so it can be used in small windows and on mobiles and such.
- In the 'Lyrics' and 'Queue' views in the sidebar, perhaps have a nicer view when no track is playing (Maybe an
AdwStatusPagewith acompactstyle with a title like 'No Song Playing'), rather than this empty space with a rectangle and controls that do nothing.
Screenshot From 2026年02月16日 23-15-52 - Playback controls should also be disabled/uninteractable when no track is playing.
OR, maybe just replace the whole of the sidebar's content (including the ViewSwitcher) with a compact StatusPage that just says something like 'Play a song to get started' or something. - More specifically with the queue page, try to improve consistency. For example, the subtitle of the 'now playing' track shows the artist name, while the subtitles of other tracks in the queue show the album name. The playback control buttons in the 'now playing' songs also have a different padding compared to the 'remove' buttons of the queued songs. I think there's a different padding between the title and subtitle too.
Screenshot From 2026年02月16日 23-32-00 - Improve accessibility of playback control buttons. Currently Orca has no way to read aloud the status of these buttons in a useful way. Consider making their popover labels react to their status. For example:
- 'Enable Shuffle' and 'Disable Shuffle' instead of 'Toggle Shuffle'.
- 'Play' and 'Pause' instead of 'Play / Pause'.
- 'Repeat Queue', 'Repeat Song', and 'Disable Repeat' instead of 'Toggle Repeat'.
There will likely be more things to address during the review process - but I'm not a designer so what I've listed are just concerns I predict would be raised if you submitted the app as it currently is. Preemptively addressing these should speed up the review process when you do apply. Also, make sure you've read the app criteria if you haven't already 😁.
Is there a similar feature in TIDAL?
N/A
Impact on usability
Tonearm is mostly useable
Tonearm Version
v1.3.1 β(r12.af078c6)
Package Manager / Packaging Method
Manual (Please describe)
### Your idea
Here is my take on some things you may want to address before submission into GNOME Circle.
- [x] Ensure all strings in your app adhere to GNOME's [writing style](https://developer.gnome.org/hig/guidelines/writing-style.html) and [typography](https://developer.gnome.org/hig/guidelines/typography.html) guidelines. I noticed some strings like in menus or in ActionRows in the preferences dialog weren't always using header capitalization.
- [ ] Try to make the app as adaptive as possible, so it can be used in small windows and on mobiles and such.
- [x] In the 'Lyrics' and 'Queue' views in the sidebar, perhaps have a nicer view when no track is playing (Maybe an `AdwStatusPage` with a `compact` style with a title like 'No Song Playing'), rather than this empty space with a rectangle and controls that do nothing.
- [x] Playback controls should also be disabled/uninteractable when no track is playing.
**OR**, maybe just replace the whole of the sidebar's content (including the ViewSwitcher) with a compact StatusPage that just says something like 'Play a song to get started' or something.
- [x] More specifically with the queue page, try to improve consistency. For example, the subtitle of the 'now playing' track shows the artist name, while the subtitles of other tracks in the queue show the album name. The playback control buttons in the 'now playing' songs also have a different padding compared to the 'remove' buttons of the queued songs. I *think* there's a different padding between the title and subtitle too.
- [x] Improve accessibility of playback control buttons. Currently Orca has no way to read aloud the status of these buttons in a useful way. Consider making their popover labels react to their status. For example:
- 'Enable Shuffle' and 'Disable Shuffle' instead of 'Toggle Shuffle'.
- 'Play' and 'Pause' instead of 'Play / Pause'.
- 'Repeat Queue', 'Repeat Song', and 'Disable Repeat' instead of 'Toggle Repeat'.
There will likely be more things to address during the review process - but I'm not a designer so what I've listed are just concerns I *predict* would be raised if you submitted the app as it currently is. Preemptively addressing these should speed up the review process when you do apply. Also, make sure you've read the [app criteria](https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/blob/main/AppCriteria.md) if you haven't already 😁.
### Is there a similar feature in TIDAL?
N/A
### Impact on usability
Tonearm is mostly useable
### Tonearm Version
v1.3.1 β(r12.af078c6)
### Package Manager / Packaging Method
Manual (Please describe)