W dniu 24 lutego 2010 11:59 użytkownik Jon Cruz <jon@...18...> napisał:
It is true that keeping things consistent is good and has it's place, but on the other hand the key is to focus on *tasks* and not on *commands*. In several tasks, keeping a given command in a certain spot will most likely make sense, but in *other* tasks it might make sense for some of them to move.
Yes, certainly; but the current choices in the combo box - "Widescreen" and "Custom" - are not tasks. They are toolbar layouts. It would be better if the task checkbox changed the available commands, while the toolbars could be dragged and docked to different edges of the window as the user wants and stay there.
UxManager is the "User experience manager" ("UX" is the current industry term that is related to things like "user interation", "human interface design", etc). It should manage the user experience overall. This is a fairly high-level component and will run several things.
"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".
(BTW, we have an awful lot of "managers", sounds like an invasion of suits :) )
One such job is to control the appearance of windows and sub-windows. It will also need to know context of the current work so it can properly adjust in real-time. Knowing where different windows are is very important here. It can move windows around. It can dock or float tool windows. It can bring up duplicate windows with special views (icon preview, animation timeline, rsvg preview, etc.).
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.
It can see that you are running on a netbook and default to have toolbars on the side. It can remember that last time you moved the toolbars back to the top, so this time it will leave them where you had them, etc.
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.
Basically the UxManage is supposed to be the AI that will run things and help you out as you work.
Can you provide more specific examples of "smart" behavior which would be triggered by this class? We should avoid trying to be smarter than the user, because it is usually very annoying.
Now, I do know that on the majority of current Linux distributions tr1/unordered_map is working well. I do not dispute that. But then on other systems, especially with compilers other than gcc, things are not as stable. (did you know Netware is still a supported OS with supported third party software?)
Every system that has (a correctly configured) GCC 4.0.2 or later will work. However, I just noticed we can circumvent this problem by using the Boost versions of unordered containers. I recall that they didn't want to work for some reason when I first tried them, but I'll try again.
Regards, Krzysztof