On Feb 17, 2010, at 1:48 PM, Krzysztof Kosiński wrote:
I have some doubts about the adaptable UI feature.
Part 1: UI issues
- The UI mode selection combo box (called "Task" for some reason) has
usability problems: 1. it jumps around when changing mode, so every time I change it, I have to find it again to try another mode; 2. when the main commands toolbar is vertical, it causes a very large horizontal padding on it, even when it's hidden in the overflow menu.
Yes, the UI is not done yet. Focus was given to implementing the functionality first, with the UI to naturally follow via "form follows function". This has allowed others to try it out and provide guiding feedback, including many from linux.conf.au.
- Tearing off toolbars does not adjust their size to fit the controls.
If I tear off a toolbar from a small window, I get a toolbar with an overflow menu. If I tear off from a maximized window, I get a toolbar with lots of unused space. This makes tearing off highly useless.
No, it does not.
That is the behavior that was researched and settled upon some time ago (I'm surprised you did not raise this issue a few releases ago). Although you personally do not like it, that behavior makes things *very* usable for many people out there. One segment of the userbase that preferred it that way are those with laptops and netbooks.
You mention that you get a toolbar with lots of unused space. That is because you get exactly what you ask for. When torn off, the toolbar keeps the size that it held while docked. If you want larger toolbars just tear them off while the window is larger. If you want smaller toolbars then just tear off when the window is smaller. It leaves the user in complete control with no need to write any additional code.
Among other things this turned out to be a very simple yet usable way to prevent toolbars from becoming to large for the screen. (I know that MS Windows imposes a sytem-wide limit on sizes, but most other OS's do not). If you care to take a pass at creating a better solution, please let me know. I have most of the research from when that was originally done, and can pass on to you all the base requirements (such as that "too large" problem) that something more "automatic" would require.
- Toolbars can be torn off but can't be attached in a location
different that the original one. This is because they use GtkHandleBox, for which the docking position is fixed. At the same time GDL has a widget named GdlDockBar which sounds like a true dockable toolbar (but it might as well be something else, I don't know).
Yes, GDL needs some major refactoring. It was originally forked into our codebase when GDL was heading in a different direction, and was not interested in the bulk of the changes we wanted. It also was targeting a more "kitchen sink" approach than it is taking now.
What needs to happen is
1) determine where the different forks of GDL have gone 2) assess where the prime GDL is at the moment, and what changes would be needed 3) coordinate with other projects that have forked and/or wrapped GDL and plan a unified C++ API. 4) push needed changes upstream to the prime GDL. 5) switch to using the prime GDL.
There is quite a set of different tasks to work on in all this, so it is a perfect area for you (or any others) to lend a hand in. It would be greatly appreciated, and by more than just the Inkscape community.
Part 2: UxManager class
- UxManager::setTask: Magic constants in switch.
Yes. Temporary code to enable working on the feature. Once the functionality comes clear, the needed UI becomes much easier to implement.
- UxManager constructor: "tags" is created but doesn't do anything.
... yet.
The tags code provide needed functionality for the UI, and has been used already for some experimental work (AKA not clean enough for trunk). Additionally there are people in other projects who are interested is sharing that code, so going into the trunk sooner rather than later was a request. It is also the reason the tags files need to stay pure C++ and not use GTK+.
- What is the point of having several desktops attached to one UxManager?
Read the papers on adaptive UI, watch Michael Terry's presentation, etc. Let me know if that still has not become clear once you go over the source material.
Part 3: util/ege-tags.h, util/ege-tags.cpp
- ege-tags.h: It supposedly implements
http://create.freedesktop.org/wiki/ResourceTagging but at present I don't see any place in Inkscape that could make use of tagging.
See the notes above on "tags".
However, if you are saying that you can not visualize areas of our interface and data resources that could benefit from having tags applied, then that is a very different issue. Is that what you were trying to state?
- Even if the aforementioned specification was good, the UxManager
class apparently tries to do two completely unrelated things: manage external resources and change the UI mode.
No, it does even more than that, *HOWEVER* those are NOT unrelated at all. Once you review the source material on adaptive UI then it will be easier to explain "big picture" architecture.
- TagSet: if I understand correctly what this class attempts to do, it
should use std::tr1::unordered_map<Tag, int> with appropriate hash and equality predicates instead of the combination of std::vector<Tag> and std::map<std::string, int>.
No. Not at all.
One of the prime things we want to do is keep our codebase working for a wide range of end users and distros. We do *NOT* want to require the latest and greatest of each and every library. Thus the unordered_map template is one that needs to be avoided as much as possible. My prime concern there at the moment is that it is a new thing that is just going in and is not yet 'standard' (behavior, implementation, use, etc.) on even the newest few platforms, let alone the range we would like to keep covered.
But I do want to take care and emphasize that the immediate problem with unordered_map is that its use is buggy and prone to implementation issues on the main few platforms we initially target. Use of buggy/problematic types/code should be minimized.
And more important to this specific case is that you need to keep in mind that projects other than Inkscape are wanting to share that code. Keeping it clean and more portable thus gains in importance.
Part 4: other problems
- toolbox.cpp:1578: code related to changing the UI layout uses a
switch to assign function pointers. Polymorphism should be used instead.
No, it should not.
If you review the overall use of things there (ignoring the temporary use of int's to pin tasksets) you'll see that the int used in the switch is coming in through a public enum value on the public API (or the rough equivalent thereof). Polymorphism really won't contribute anything at this point in time, and most likely will add significant complexity. Complexity is the enemy, and should be minimized whenever practical.