2010/2/24 Krzysztof KosiĆski <tweenk.pl@...400...>:
"User experience" is not a concept that can have its dedicated object
- every line of code in the program affects it. Similarly you can't
have meaningful "UsabilityManager" or "InkscapePopularityBooster" classes. What does "managing the user experience" actually mean? I am afraid that this class will quickly become a bag of unrelated things or a God object. There should be a better name for it, for example "ToolbarLayoutManager", "TaskManager", "CommandSet" or "TagStorage".
I agree with Krzysztof here. Jon, to me "user experience" is an almost meaningless marketing phrase. Could you try and find something better?
By the way your "eek" files, still in the codebase, are not exactly a good naming example either, even if you invent a backronym for them :)
For icon preview and RSVG preview, I see no reason to have an extra class to create them - just create a preview dialog in response to action activation like any other. Docking would be better left to GDL and the user (unless you have some specific examples where something more complex needs to be done). Moving windows is a bad idea - the window manager should do it.
We have something similar for normal and fullscreen modes: the set of visible toolbars and other elements is different and independently remembered in these modes. In any case, this code should then be combined with the new "ux" code.
For user setting persistence we have preferences - it's better to add whatever functionality you need to them. The logic to determine where the toolbars should be by default based on screen resolution can be put somewhere in the toolbar creation code.
Definitely, all UI for this feature, whatever it is, should be in Preferences.