Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Revisit structure of “System” menu

Aperta
  • Qualcosa non va?
#1,455 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
html
Ambito
design, frontend

Direzione di ricerca

Start by reviewing the component in app/templates/custom-elements/menu-bar.html and the current System and Help menu structure. Consider the stated constraints and possible approaches, then document the agreed structure in a nearby comment. Done means the menu organization has been decided and the component documentation reflects it.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement medium small

The “System” menu keeps growing as we add new features. In Pro, the ”System” menu can contain up to 8 items:

Screenshot 2023-06-19 at 18 02 16

(Note, “Logout” is conditional, i.e. only shown if user authentication is enabled.)

Before we add the next item to the “System” menu, we want to revisit the structure of it. We should also write up a few sentences as documentation, probably as comment somewhere in the <menu-bar> component.

Considerations

On a high-level, our menu(s) should be…:

  • Neat: the more items a menu contains, the harder it is for users to grasp its structure, and to find where things are.
    • There certainly is no hard limit in regards to items-per-menu, but 8 items on the same level (without any sort of grouping / division / sub-structure) feels quite a lot already.
  • Intuitive: the menu labels should be straightforward, and the menu structure should “feel” right – i.e., logical and consistent.
    • E.g., “System” implies “global”/“device-wide”, whereas “View” implies “local”/“client-side”. And “Actions” are operations against the target machine.
  • Practical: often-used items should be easy to reach, whereas less-used functionality can be “stashed away” somewhere.
    • One example here is the “About” menu item in the “Help” menu. You could argue whether that’s the right place, but the “About” dialog is really not that important in day-to-day usage, so it shouldn’t reside in “System” for example, to avoid clutter.

Some random notes for reference:

  • We mix items in the “System” menu that fall into slightly different categories. E.g., “Hostname” and “Virtual Media” are true properties of the device’s system, whereas e.g. “Log Out” is actually client-specific state, or “Update” is kind-of a meta functionality. We certainly don’t have to nail the semantics 100%, but maybe that realization helps us to think about the structure internally.
  • One constraint is that some items should stay in place for historical reasons. E.g., “Logs” could theoretically be moved somewhere else, but the problem is we’d have to change a lot of documentation and public support posts then.
  • Potential approaches to clear up the menu structure could be:
    • Sub-menus
    • Menu separators
    • A new top-level menu
  • We already introduced a new top-level menu “Help”, which allowed us to move “About” out of from the “System” menu.
Lingua principale
Python
Stelle
3.5k
Fork
291
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di tiny-pilot/tinypilot

Tutte le issue di tiny-pilot/tinypilot

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.