-
Notifications
You must be signed in to change notification settings - Fork 476
Reducing coupling in Material
There needs to be a way to have child components in the Toolbar, Pagestack area, and sidebar to communicate. Currently global properties are used and are tightly coupled to children making it difficult to use and test components in isolation. The thing is that in Material Design the contents of the titlebar and page stack are different physical visual containers, but they reside as part of a complete unit, but they need to be cohesive with each other. There needs to be a way to allow them to integrate bidirectionally but allow them to live without each other if they are not needed.
This approach is currently used by the Theme and Unit components. This works well since they are global to the entire application and without them there is no sane way to control the look and feel. The big difference with them is that there can only really be one theme, or one set of units methods. In theory you could have multiple windows with a material application. This is not very common on tablets but in the desktop world of dual monitors you will want to be able to have more documents open at a time. I have a low opinion of MDI in general so I prefer multiple top level windows. This could be accomplished with multiple application instances, but what if you want to go from desktop to tablet view? It would be nice to have an application that can morph to the current form factor. The other issue with singletons is if you have an application wide instance it can become a dumping ground of properties and functions.
This is like the singleton, but you have to pass it into children you want to have the properties. The issue here is that you pretty much have to pass in this object as an argument to every component. You also easily have multiple levels of properties without needing to reconstruct bindings. This is a big problem when models and delegates are involved.
Attached properties are interesting because you can give the child component a controlled amount of information as to what the parent wants it to know about. The key issue with them is that they are only accessible in the immediate child component scope, so bindings are a bit cumbersome from delegates. They also need to be created via C++ plugins, so there would have to be a C++ base object for everything, and that may not be realistic.
This is an interesting idea that has come up before to handle list views with "drilldown." An advantage of this approach is that the page stack, toolbar and other top level components become delegates that render the page model as they see fit. So say a tablet toolbar can make buttons larger, while a desktop toolbar may be smaller. It can also allow for flexibility with dealing with overflow, and relay out for letter vs landscape. The big problem with this approach is that the model doesn't really know much about the outside world. Normally for pure data this is not a problem, but since our model is a container of UI elements they would have to be able to cope with something else manipulating their size, layout and even function. This isn't always a good thing. It can also cause a madding maze of signals and slots to communicate between the model and the delegate. If you need to pass information back from the view you also get issues with tight coupling again.