[FEATURE] Comprehensive GUI design for all FIXS config.yaml settings

[yunlishao]

Workflow: One Issue, One Branch, Three PRs

All work on one branch (e.g., feature/#121-gui-design), with three sequential PRs:

PR	Deliverable	Description	Prerequisite	Due
PR 1	Review & disposition of PR #103	Review PR #103 in detail, comment on it with findings, and recommend how to proceed (accept as-is, request changes, close and start fresh, or merge and refactor). Deliverable is the PR #103 comment thread itself — no code changes needed.	None	Feb 23
PR 2	GUI design & wireframes	Comprehensive layout design covering all config.yaml sections, conditional show/hide behavior, subscription block UI patterns, and YAML generation workflow. Output: wireframes/mockups + design doc committed to doc/gui-design/.	PR 1 completed	Mar 16
PR 3	Framework recommendation	Research GUI frameworks independently, pick one to recommend with justification (why it fits FIXS needs, ease of use, cross-platform support, maintainability). Output: short write-up in doc/gui-design/.	PR 2 merged	Mar 23

How to work

1. Create branch feature/#121-gui-design from main
2. Reference this issue in each PR (e.g., "Part of [FEATURE] Comprehensive GUI design for all FIXS config.yaml settings #121")
3. @Kazawaryu reviews and approves each PR before merge
4. For PR 1 specifically: post your review directly as comments on PR #78 / Add GUI for non-developer users #103, then link back here

---

Roles

• Developer: @sarayureddyyy — implement and submit PRs
• Reviewer: @Kazawaryu — review and approve PRs before merge

---

Is your feature request related to a problem?
Issue #78 proposed a simple GUI for non-developer users, and PR #103 delivered an initial implementation focused on IPG CarMaker co-simulation scenarios (CarMaker-SUMO and CarMaker-Simulink-SUMO). However, the current GUI effort has several limitations:

1. Narrow scope: The PR #78 / Add GUI for non-developer users #103 GUIs (GUI_CM-Sumo.py, GUI_Simulink-CM-Sumo.py) only cover CarMaker+SUMO workflows. They do not expose any of the config.yaml settings — users still need to manually edit YAML for SimulationSetup, ApplicationSetup, XilSetup, CarlaSetup, SumoSetup, etc.
2. Hardcoded paths/parameters: SUMO launch parameters (port 1337, step length 0.1, etc.), CarMaker paths (C:\IPG\carmaker\...), and config file names (RS_config_release.yaml) are hardcoded rather than driven by the YAML configuration.
3. No config.yaml editing: The GUIs are process launchers (pick files, click Run), not configuration editors. Users cannot view or modify any of the ~60+ YAML fields documented in doc/ConfigSetup.md.
4. Separate GUI per workflow: There are three separate GUI scripts (GUI_CM-Sumo.py, GUI_Simulink-CM-Sumo.py, GUI_Simulink-CM-Sumo_loop.py) rather than a unified interface that adapts to the selected workflow.

Describe the solution you'd like
This issue is a design-only task. The goal is to produce a comprehensive GUI design document that covers all current config.yaml settings. Implementation will follow as a separate issue.

Design Philosophy

The existing FIXS pipeline reads config.yaml and sets up co-simulation correctly. The GUI should act as a wrapper/front-end that helps users configure and generate valid config.yaml files for their desired simulation, without breaking the existing YAML-driven workflow. The GUI outputs a .yaml file (e.g., via an explicit "Generate YAML" / "Export config.yaml" button) that FIXS components consume as they do today.

Deliverables

1. Audit of current GUI effort — Document what PR #78 / Add GUI for non-developer users #103 covers, its limitations, and what is missing relative to the full config.yaml spec.
2. Comprehensive GUI design — A design (wireframes, layout descriptions, or mockups) for a unified GUI that can:
   • Load/save/create config.yaml files with full coverage of all sections:
     • SimulationSetup (12 fields: EnableRealSim, EnableVerboseLog, SimulationEndTime, EnableExternalDynamics, VehicleMessageField, SelectedTrafficSimulator, TrafficSimulatorIP/Port, SimulationMode/Parameter, TrafficLayerIP/Port)
     • SumoSetup (6 fields: SpeedMode, ExecutionOrder, EnableAutoLaunch, SumoConfigFile, NumClients, RuntimeLibraryPath)
     • ApplicationSetup (EnableApplicationLayer, ApplicationPort, VehicleSubscription, DetectorSubscription, SignalSubscription — including the complex subscription block schema with type/attribute/ip/port)
     • XilSetup (EnableXil, AsServer, VehicleSubscription, SignalSubscription, DetectorSubscription)
     • CarMakerSetup (9 fields: EnableCosimulation, EnableEgoSimulink, CarMakerIP/Port, TrafficRefreshRate, EgoId, EgoType, SynchronizeTrafficSignal, TrafficSignalPort)
     • CarlaSetup (12 fields: EnableVerboseLog, EnableCosimulation, EnableExternalControl, UseVehicleTypeAsBlueprint, CarlaServerIP/Port, CarlaClientIP/Port, CarlaMapName, CenteredViewId, TrafficRefreshRate, InterestedIds)
     • VehicleMessageField selection (30+ available fields documented in ConfigSetup.md)
   • Conditionally show/hide sections based on workflow (e.g., hide CarlaSetup when not enabled, hide CarMakerSetup when not using CarMaker)
   • Explicitly generate config.yaml — Provide a clear button/action to export the configured settings as a valid config.yaml file that FIXS can consume directly
   • Optionally launch and monitor simulations (integrate the process-launcher functionality from PR #78 / Add GUI for non-developer users #103)
   • Validate configurations before saving (required fields, port conflicts, path existence)
3. Design decisions — Recommend UI patterns for complex structures like subscription blocks (dynamic list of subscription entries, each with type/attribute/ip/port). Also recommend GUI framework with trade-off analysis — framework choice is still open for discussion.

Reference Materials

• doc/ConfigSetup.md — Complete YAML field reference with types, defaults, and notes
• CommonLib/ConfigHelper.h — C++ structs defining all config sections (SimulationSetup_t, ApplicationSetup_t, XilSetup_t, CarMakerSetup_t, CarlaSetup_t, SumoSetup_t)
• CommonLib/ConfigHelper.cpp — Parser implementation showing defaults and validation logic
• PR #78 / Add GUI for non-developer users #103 files: tests/ipgGUI/Python/GUI_CM-Sumo.py, GUI_Simulink-CM-Sumo.py, guiUtils.py
• Existing test config.yaml files in tests/ subdirectories for real-world examples

Additional context

• The coding/implementation of this GUI design will be tracked in a separate follow-up issue.
• The subscription block schema is the most complex UI challenge — each subscription has a type (ego/link/point/vehicleType for vehicles; intersection for signals; detector for detectors), an attribute map with varying keys per type, and ip/port lists.

Related

• [FEATURE] Simple GUI for non-developer users #78 — Original GUI feature request
• PR #78 / Add GUI for non-developer users #103 — Current IPG GUI implementation (open)

[sarayureddyyy]

FIXS Research.pdf

Update from 3/2 meeting, PR2 in progress

[sarayureddyyy]

PR 2 wireframes, check before merge

WireframesPR2.pdf

[sarayureddyyy]

PR 3 framework recommendation, check before merge

Framework_Recommendation.md

[yunlishao]

@sarayureddyyy the design looks fine and I think your suggestion for PySide6 is ok. Please create a \gui folder, make a final design documentation, with both your wireframes and descriptions of your design, put in the gui folder, and make a PR. Then you can start another issue to actually working on the GUI development