20,741
edits
Line 65: | Line 65: | ||
== Adding Widgets == | == Adding Widgets == | ||
In order to keep your dialog sufficiently generic, you'll want to refrain from adding too much custom functionality to it, and instead decompose your functionality into a collection of '''widgets'''. Widgets are GUI controls like a label, button, checkbox etc - i.e. these widgets have a certain appearance and may respond to events such as being clicked for example. Whenever you create custom widgets instead of adding all the code to a single dialog, you'll end up with reusable components that can be easily other in other dialogs. In addition, you are making sure to establish a losely-coupled design, so that your widgets are sufficient generic and do not contain any use-case specific logic. | |||
This means for example that a generic '''PropertyBrowser''' could be easily reused in other dialogs/windows requiring a corresponding property browser. But this also meanns that such a property browser widget should also be modularized, i.e. by using a lower-level '''ListView''' or '''TreeView''' widget and merely parameterizing that by showing properties. This approach has the added advantage that the corresponding '''ListView/TreeView''' widgets could be re-used in other places, such as for example an aircraft list, a [[Nasal Browser|Nasal Namespace Browser]]. | |||
Likewise, a widget-focused approach means that useful functionality like a [[Interactive Nasal REPL]] can be easily used in other places, without developers having to do any refactoring. | |||
We're also trying to make sure that Canvas Widgets can be easily used not just by GUI dialogs but also by Canvas-based instruments/MFDs - without any code duplication or Copy&Paste being required. | |||
== Using Layouts == | == Using Layouts == | ||
== Using Styling == | == Using Styling == |