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

Allow for configuring the default values of properties. Provide a machine readable file that includes all default values of properties for each widget

Aperta
  • Qualcosa non va?
#3,815 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
java
Ambito
tooling

Direzione di ricerca

Start by locating where Phoebus widgets define their property defaults and how those definitions are exposed to clients. Compare the proposed machine-readable file with the alternative of generated documentation, then identify how either approach can cover every widget and property. Done means clients can reliably determine omitted property values, with the result kept in sync when defaults change.

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

Descrizione

It is legal in phoebus to have a bob file that defines a widget that omits most of the property tags. Any omitted tags will have some default value, which of course will not be available to a client that reads just the xml.

This is problematic for cases where we'd like to do things like check the state of a set of screens against some condition. Unless we happen to know what the default value of a particular property is for a particular widget, we cannot perform the check if the xml does not include the information.

Of course, I could open the editor, drag a widget, and see what the initial value is, but this is a brittle solution that is subject to breaking if the defaults ever change. It would be good if the default values for all properties for all widgets were in a machine readble (i.e. json or yaml) file with a defined schema somewhere that clients could read for a base state. Alternatively, it would be good if at least there were a automatically updated document that listed all of these default values in the documentation.

For context, I am developing a linter for phoebus screens: https://github.com/NSLS2/phoebuslint. It works pretty well but I am running into things like this:

Have a rule that checks if a widget is outside of the bounds of a screen. The screen is configured to be 400 x 600, but since 600 is the default width it is omitted in the xml. The linter doesn't know about this and defaults to 0, so every widget gets marked as out of bounds.

For now, I've hard coded the default value, but it would be great if we could put together a more robust solution.

Lingua principale
Java
Stelle
130
Fork
132
Merge medio
2g 11h
PR unite (30g)
19

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

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 ControlSystemStudio/phoebus

Tutte le issue di ControlSystemStudio/phoebus

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.