On Mar 2, 2010, at 10:50 AM, bulia byak wrote:
The preference mechanism is good for storing sets of data, but hooking it in to the low-level of each widget construction function is not how we should implement it.
It's not hooking into low-level. It's the other way round. All levels just use prefs for storing their data. The way my toolbars are positioned is clearly a piece of data I want to store and preserve.
Yes, yes.
But the key here is *which* bit of code store *which* pieces of information and in *what* format. As they say, the devil is in the details.
So under different circumstances, different settings are pertinent. Either the low-level needs to know the entirety of possible context information, or something higher up needs to run settings instead.
Something low-level like a button might be made to do something the equivalent of:
if (Inkscape::Application::getGlobalApp()::getWindowCount() > 0)
etc. In this case something at the lower levels is looking *up* through the program organization and searching for global information that it has been hardcoded to know something about.
Generally it has been taken that it is better to have low-level components encapsulated and modular. If they do one thing and one thing only, and in a constrained manner, then it is much easier to do things such as reuse a software component in a different way or in a different location.
I think the color selectors might be a quick example from our codebase. They are used several places in our code, and do not read nor write any preferences themselves. Instead something a bit higher in the chain creates them, pushes initial values into them, listens to changes coming from them, etc.
On the other hand, the current style widget is a fairly complex object that contains a lot of specialized logic, etc. It has to track state and drive a lot of behavior. However, it still can do it's job no matter where in the UI it is placed, as long as it is hooked to a specific desktop widget. It is a fairly good bit of architecture, and is very reusable and modular.
Also I think *how* the current style widget is updated has a good example. Instead of "peeking out" via SP_ACTIVE_DOCUMENT() or such, the widget has it's dependency "pushed in" via its setDesktop() call. In theory we could do a simple floating dialog that creates and holds a single current style widget. That floating dialog could listen for the "active" desktop to change and then when it hears an update that dialog can turn around and "push down" into the current style widget by calling setDesktop() on it. That's the kind of approach I'm trying to look at.