Praxis Software Structure Model

Module Boundaries: apps/linux_uconsole_gtk

Explain the package/module boundaries, number of files, number of symbols and cross-module dependencies of apps/linux_uconsole_gtk.

Package Diagrams candidate / high 0.1.0 · 34aad0bffa2f / main

How to read the diagram

Technical complexity analysis

Relationship with business complexity

Governance Suggestions

UML/Technical Diagram

flowchart LR
  package_node["apps/linux_uconsole_gtk"]
  dependency_1["apps/esp32_lvgl"]
  package_node --> dependency_1
  dependency_2["apps/linux_sim_shell"]
  package_node --> dependency_2
  dependency_3["apps/linux_cardputer_zero"]
  package_node --> dependency_3

Coverage

Drill-down of semantic elements in the diagram

  1. apps/linux_uconsole_gtk package

    apps/linux_uconsole_gtk is the central engineering boundary of the current Package Diagram, used to observe its own scale, dependency direction and drill-down technical complexity.

    Technical role
    Technical organization boundary: It aggregates the files, symbols and cross-module relationships under apps/linux_uconsole_gtk into a discussable engineering unit.
    Why it appears
    Local repository evidence observes enough files, symbols, or cross-module relationships under apps/linux_uconsole_gtk that it deserves to be promoted to a package-level entry in the software structure model.
    Relationship meaning
    The arrows pointing from apps/linux_uconsole_gtk to other nodes in the figure indicate that the current boundary relies on external packages/modules; it is dependent or called 41 times by other modules and depends on or called external modules 43 times, which is used to determine whether it is more like a stable reuse boundary or an orchestration/bridging boundary.
    Drill-down intention
    Drilling down on this node can continue to view the key components, structural collaboration slices, running links, deployment nodes and complexity hotspots within apps/linux_uconsole_gtk to understand how this project boundary carries functional changes.
    Business association
    This node is not the business story itself, but the Use Case that falls into apps/linux_uconsole_gtk in the organization/process model can refer to this as the technology bearing boundary. The current association is still CANDIDATE.
    Impact of change
    Modifying the public entry, dependency direction, or directory boundary of apps/linux_uconsole_gtk may affect the verification paths of component diagrams, sequence fragments, deployment configurations, and related business stories that reference it.
    Confidence
    high

    Evidence

    • package scope: apps/linux_uconsole_gtk
    • Module path: apps/linux_uconsole_gtk
    • Number of files: 54
    • Number of symbols: 697
    • Depends on or called by other modules: 41
    • Depends on or calls external modules: 43
    • apps/linux_uconsole_gtk/APP_SHELL_MANIFEST.md
    • apps/linux_uconsole_gtk/CMakeLists.txt

    Risk

    • If you only regard this node as a directory name, you will miss its responsibility as a stable project boundary.
    • If signs of dependency on external modules continue to increase, it may be a sign that the boundary is taking on too much orchestration or bridging responsibility.

    Problem

    • The current warehouse evidence has not yet explicitly traced the package to a Use Case; therefore, the business association remains a candidate.
  2. apps/esp32_lvgl package

    apps/esp32_lvgl is the currently observed external technology boundary dependency of apps/linux_uconsole_gtk; it indicates that the current module is not implemented in isolation, but requires the help of another set of engineering capabilities to complete its responsibilities.

    Technical role
    Cross-module technology dependency boundary: The current package requires another package/module to provide capabilities, contracts, configuration or operation support.
    Why it appears
    Local repository evidence observed a cross-module factual relationship between apps/linux_uconsole_gtk and apps/esp32_lvgl, so the dependency was put into the Package Diagram instead of just hidden in the code import/call.
    Relationship meaning
    apps/linux_uconsole_gtk -> apps/esp32_lvgl indicates that local warehouse evidence observes cross-module relationships; it explains the technical dependency direction, but does not directly prove the business process.
    Drill-down intention
    Drill down into apps/esp32_lvgl to view its own Package Diagram, and then continue to enter its components, structures, sequences or hotspots to determine whether the current dependency falls on the entry, runtime, tool registration, model adaptation or infrastructure boundary.
    Business association
    apps/linux_uconsole_gtk If hosting a user-visible capability, the dependency on apps/esp32_lvgl may be a runtime mechanism, an extension point, or a governance constraint for that capability. This business association needs to be confirmed by the Use Case evidence of the organization/process model.
    Impact of change
    Modifying the public interface, path or running mode of apps/esp32_lvgl may cause chain changes in the call chain, packaging entry, agent workflow or UI behavior of apps/linux_uconsole_gtk.
    Confidence
    high

    Evidence

    • dependency edge: apps/linux_uconsole_gtk -> apps/esp32_lvgl
    • apps/esp32_lvgl/APP_SHELL_MANIFEST.md
    • apps/esp32_lvgl/CMakeLists.txt
    • apps/esp32_lvgl/library.json
    • apps/esp32_lvgl/README.md
    • apps/esp32_lvgl/src/esp32_lvgl_app_shell.cpp
    • apps/esp32_lvgl/src/esp32_lvgl_app_shell.h
    • apps/esp32_lvgl/src/esp32_lvgl_arduino_app_registry.cpp

    Risk

    • Cross-module dependencies can only prove technical relationships, but cannot directly prove business relationships.
    • If this dependency only exists for implementation convenience, future changes may cause boundary drift or implicit public toolboxes.

    Problem

    • Current evidence does not demonstrate that apps/linux_uconsole_gtk's dependence on apps/esp32_lvgl is directly related to a Use Case, runtime command, or configuration decision.
    • The current dependency direction is a candidate according to the warehouse fact record, and no architectural decision document has been found to prove that it is a stable boundary.
  3. apps/linux_sim_shell package

    apps/linux_sim_shell is the currently observed external technology boundary dependency of apps/linux_uconsole_gtk; it indicates that the current module is not implemented in isolation, but requires the help of another set of engineering capabilities to complete its responsibilities.

    Technical role
    Cross-module technology dependency boundary: The current package requires another package/module to provide capabilities, contracts, configuration or operation support.
    Why it appears
    Local repository evidence observed a cross-module factual relationship between apps/linux_uconsole_gtk and apps/linux_sim_shell, so the dependency was put into the Package Diagram instead of just hidden in the code import/call.
    Relationship meaning
    apps/linux_uconsole_gtk -> apps/linux_sim_shell indicates that local repository evidence observes cross-module relationships; it explains the technical dependency direction, but does not directly prove the business process.
    Drill-down intention
    Drilling down into apps/linux_sim_shell, you can view its own Package Diagram, and then continue to enter its components, structures, sequences or hotspots to determine whether the current dependency falls on the entry, runtime, tool registration, model adaptation or infrastructure boundary.
    Business association
    apps/linux_uconsole_gtk If hosting a user-visible capability, the dependency on apps/linux_sim_shell may be a runtime mechanism, an extension point, or a governance constraint for that capability. This business association needs to be confirmed by the Use Case evidence of the organization/process model.
    Impact of change
    Modifying the public interface, path or running mode of apps/linux_sim_shell may cause chain changes in the call chain, packaging entry, agent workflow or UI behavior of apps/linux_uconsole_gtk.
    Confidence
    high

    Evidence

    • dependency edge: apps/linux_uconsole_gtk -> apps/linux_sim_shell
    • apps/linux_sim_shell/APP_SHELL_MANIFEST.md
    • apps/linux_sim_shell/CMakeLists.txt
    • apps/linux_sim_shell/README.md
    • apps/linux_sim_shell/src/linux_sim_app_shell.cpp
    • apps/linux_sim_shell/src/linux_sim_app_shell.h
    • apps/linux_sim_shell/src/linux_sim_runtime_entry_adoption_probe.cpp
    • apps/linux_sim_shell/src/linux_sim_runtime_entry_adoption_probe.h

    Risk

    • Cross-module dependencies can only prove technical relationships, but cannot directly prove business relationships.
    • If this dependency only exists for implementation convenience, future changes may cause boundary drift or implicit public toolboxes.

    Problem

    • Current evidence does not demonstrate that apps/linux_uconsole_gtk's dependence on apps/linux_sim_shell is directly related to a Use Case, runtime command, or configuration decision.
    • The current dependency direction is a candidate according to the warehouse fact record, and no architectural decision document has been found to prove that it is a stable boundary.
  4. apps/linux_cardputer_zero package

    apps/linux_cardputer_zero is the currently observed external technology boundary dependency of apps/linux_uconsole_gtk; it indicates that the current module is not implemented in isolation, but requires the help of another set of engineering capabilities to complete its responsibilities.

    Technical role
    Cross-module technology dependency boundary: The current package requires another package/module to provide capabilities, contracts, configuration or operation support.
    Why it appears
    Local repository evidence observed a cross-module factual relationship between apps/linux_uconsole_gtk and apps/linux_cardputer_zero, so the dependency was put into the Package Diagram instead of just hidden in the code import/call.
    Relationship meaning
    apps/linux_uconsole_gtk -> apps/linux_cardputer_zero indicates that local repository evidence observes cross-module relationships; it explains the technical dependency direction, but does not directly prove the business process.
    Drill-down intention
    Drilling down apps/linux_cardputer_zero, you can view its own Package Diagram, and then continue to enter its components, structures, sequences or hotspots to determine whether the current dependency falls on the entrance, runtime, tool registration, model adaptation or infrastructure boundary.
    Business association
    apps/linux_uconsole_gtk If hosting a user-visible capability, the dependency on apps/linux_cardputer_zero may be a runtime mechanism, an extension point, or a governance constraint for that capability. This business association needs to be confirmed by the Use Case evidence of the organization/process model.
    Impact of change
    Modifying the public interface, path or running mode of apps/linux_cardputer_zero may cause chain changes in the call chain, packaging entry, agent workflow or UI behavior of apps/linux_uconsole_gtk.
    Confidence
    high

    Evidence

    • dependency edge: apps/linux_uconsole_gtk -> apps/linux_cardputer_zero
    • apps/linux_cardputer_zero/APP_SHELL_MANIFEST.md
    • apps/linux_cardputer_zero/CMakeLists.txt
    • apps/linux_cardputer_zero/packaging/trailmate-cardputer-zero-applaunch
    • apps/linux_cardputer_zero/packaging/trailmate-cardputer-zero.desktop
    • apps/linux_cardputer_zero/packaging/trailmate-cardputer-zero.png
    • apps/linux_cardputer_zero/README.md
    • apps/linux_cardputer_zero/src/cardputer_zero_input_method_port.cpp

    Risk

    • Cross-module dependencies can only prove technical relationships, but cannot directly prove business relationships.
    • If this dependency only exists for implementation convenience, future changes may cause boundary drift or implicit public toolboxes.

    Problem

    • Current evidence does not demonstrate that apps/linux_uconsole_gtk's dependence on apps/linux_cardputer_zero is directly related to a Use Case, runtime command, or configuration decision.
    • The current dependency direction is a candidate according to the warehouse fact record, and no architectural decision document has been found to prove that it is a stable boundary.

Drill-down UML

Function node: launchSettingsLayout component · contains

Open the function node: launchSettingsLayout to confirm which specific object within apps/linux_uconsole_gtk is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_settings_layout.cpp, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

function is located in apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_settings_layout.cpp#L110. It coordinates multiple external objects or capabilities and is used to explain technical collaboration and change impact.
Function node: makeLabel component · contains

Open the function node: makeLabel to confirm which specific object within apps/linux_uconsole_gtk is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_widgets.cpp, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

function is located in apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_widgets.cpp#L9. It is reused or relied on by multiple objects and is used to explain technical collaboration and the impact of changes.
Function node: makeSettingsRow component · contains

Open the function node: makeSettingsRow to confirm which specific object within apps/linux_uconsole_gtk is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_settings_layout.cpp, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

function is located in apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_settings_layout.cpp#L22. It is reused or relied on by multiple objects and is used to explain technical collaboration and change impact.
Function node: refreshUi component · contains

Open the function node: refreshUi to confirm which specific object within apps/linux_uconsole_gtk is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_shell.cpp, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

function is located in apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_shell.cpp#L285. It is reused or relied on by multiple objects and is used to explain technical collaboration and change impact.
Function node: refreshMap component · contains

Open the function node: refreshMap to confirm which specific object within apps/linux_uconsole_gtk is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_map_logic.cpp, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

function is located in apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_map_logic.cpp#L1243. It coordinates multiple external objects or capabilities and is used to explain technical collaboration and change impact.
Function node: main component · contains

Open the function node: main to confirm which specific object within apps/linux_uconsole_gtk is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor apps/linux_uconsole_gtk/tests/uconsole_meshtastic_node_payload_smoke.cpp, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

function located in apps/linux_uconsole_gtk/tests/uconsole_meshtastic_node_payload_smoke.cpp#L89, coordinates multiple external objects or capabilities to explain technical collaboration and change impact.
Function node: launchMapLayout component · contains

Open the function node: launchMapLayout to confirm which specific object within apps/linux_uconsole_gtk is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_map_layout.cpp, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

The function is located in apps/linux_uconsole_gtk/src/platform/gtk/gtk_uconsole_map_layout.cpp#L105, which coordinates multiple external objects or capabilities and is used to explain technical collaboration and change impact areas.
Function node: expect component · contains

Open the function node: expect to confirm which specific object within apps/linux_uconsole_gtk is responsible for entry, orchestration, adaptation, contract or sharing responsibilities. Focus on checking the code anchor apps/linux_uconsole_gtk/tests/uconsole_meshtastic_node_payload_smoke.cpp, and whether its referenced/calling relationship and external dependency/calling relationship mean that changes will spread.

function is located in apps/linux_uconsole_gtk/tests/uconsole_meshtastic_node_payload_smoke.cpp#L15. It is reused or relied on by multiple objects and is used to explain technical collaboration and change impact.
Candidates for external collaboration: launchSettingsLayout Technical Hotspots technical_hotspot · risk_detail

View candidates for external collaboration: launchSettingsLayout Technical Hotspot Whether this complexity signal will increase the cost of reading, modifying, testing or regression of apps/linux_uconsole_gtk.

This symbol connects multiple external objects or capabilities and may have orchestration, aggregation, or override responsibilities.
Candidates that are widely reused: makeLabel technology hotspots technical_hotspot · risk_detail

View widely reused candidate: makeLabel Technology Hotspot Whether this complexity signal will increase the cost of reading, modifying, testing or regression of apps/linux_uconsole_gtk.

This symbol is referenced or called by multiple codes, which may be a shared core, implicit interface or change diffusion point.
Widely reused candidate: makeSettingsRow Technical Hotspot technical_hotspot · risk_detail

View the widely reused candidate: makeSettingsRow Technical Hotspot Whether this complexity signal will increase the cost of reading, modifying, testing or regression of apps/linux_uconsole_gtk.

This symbol is referenced or called by multiple codes, which may be a shared core, implicit interface or change diffusion point.

Evidence

Problem