2010/2/20 Jon Cruz <jon@...18...>:
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.
If the UI is incomplete, why is it in trunk? Wouldn't it be better to keep it in a branch until it's ready for general use?
The presentations you mentioned are not about moving toolbars around, they are about showing different sets of commands depending on the chosen task. When the task changes, the toolbars should not move around, so that commands common to several tasks stay in the same places.
- determine where the different forks of GDL have gone
- assess where the prime GDL is at the moment, and what changes would be needed
- coordinate with other projects that have forked and/or wrapped GDL and plan a unified C++ API.
- push needed changes upstream to the prime GDL.
- switch to using the prime GDL.
I looked at this some time ago, the only changes in our tree are: 1. Some fixes that probably deal with floating dialogs 2. Ability to use a pixmap images as the dockbar icon (original GDL requires stock items) In fact we might be able to compile Inkscape with stock GDL if we create stock items from our icons on the fly.
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?
I see what resources they can be applied to (dash patterns, markers, patterns, gradients, etc.) but the UI for operating on them needs significant changes in order to use tags in any way.
- 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.
I read that and the only relation I see is showing specifically tagged resources when a task is selected. UxManager (whatever that name means) should not manage all resources - it should only expose a method to get the current resource filter which could then be applied to resource selectors (e.g. the gradient selector).
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.
unordered_set / unordered_map are not the latest and greatest. They are available since GCC 4.0.0 which was released 5 years ago. By comparison GTK 2.10, which is the oldest version that has a chance of working with Inkscape, was released 4 years ago. It works absolutely everywhere, including MSVC and Intel C++, except the misconfigured Apple GCC. (Note that it's their fault, because they configured the compiler to use a non-matching set of standard C++ headers - their g++ 4.2.1 uses headers from g++ 4.0.0. If they didn't do that, it would work correctly.)
the immediate problem with unordered_map is that its use is buggy and prone to implementation issues
You are just making stuff up to excuse Apple from providing a broken toolchain. unordered_map is no more "buggy" or "prone to implementation issues" than std::vector or std::string.
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.
This is another reason to use unordered_set/map. They are more portable than the GCC-specific hash implementations we used before. For example they also work with MSVC and Intel C++, whereas __gnu_cxx::hash_set/map doesn't.
Regards, Krzysztof