Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#3,815 5 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
java
Domain
tooling

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Java
Stars
130
Forks
132
Avg merge
2d 11h
Merged PRs (30d)
23

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ControlSystemStudio/phoebus

All issues in ControlSystemStudio/phoebus

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.