On Feb 23, 2010, at 1:44 PM, Krzysztof Kosiński wrote:
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?
Well, first of all the *feature* is ready for some general testing, even though the UI is not yet polished. We discussed this in the chat room, and many people asked me to put it in. In fact, I even had people come up to me at linux.conf.au the few days after I checked in and ask for a "wishlist" that turned out to be in the code already.
Second, this is new functionality, and does not break nor change old functionality. The worst case is that some of the items are taking a bit much horizontal space (well... that one toolbar takes waaaaaay too much)... however that only becomes visible if someone is trying the new functionality. That's been our policy since the beginning. Potentially risky changes or changes to existing behavior should be done on a branch, but otherwise things should go in trunk to gain exposure and avoid bit-rot.
(branches and #ifdef both count as high potential for bit-rot. Avoiding that, and especially the #ifdef case, had been one of Mental's well justified pet peeves.)
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.
No, not really.
Perhaps it was that they focused first on sub-setting the functionality, and did not *initially* address moving of items.
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.
There were some interesting things in those presentations, but some might have been quite subtle. I can assure you, though, that I spent quite a lot of time with Michael Terry and his team. We were going over all sorts of issues (did you happen to catch the one on movement templates?) and I first asked a lot of questions to be sure I had the correct understanding of what was presented.
- 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:
- Some fixes that probably deal with floating dialogs
- 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.
That might be true for the current behavior. However we really need to *improve* the behavior. This has also been discussed some with the current GDL team, and other projects who themselves have branched or re-branched GDL.
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.
Oh, no. Not really.
There are many subtle things about our UI that actually make it not nearly as much work as you might think. For example, the code that runs the set of swatches shown at the bottom and side of the window is generic code that was designed to show any type and not just colors. In fact, the code is already in there that has gradients also showing up.
So, first adding a "jump to tagged item" functionality is probably a day or so's work.
Filtering the view to only matching tags is probably not that much work either. Things are based on "previewables" that are objects that can be previewed. Add "getTags()" to that interface and then the PreviewHolder (I think that's the class) can be tweaked to filter the view. It is already presenting the data set in a dynamic and rearranging manner.
- 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).
No, that is not the design intent of UxManager.
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.
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.).
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.
Basically the UxManage is supposed to be the AI that will run things and help you out as you work.
... Therefore the UxManager needs to be a single instance that is aware of more than just a single window on a document. If it were per-desktop then even a single document would end up with several.
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.)
Just look through our autoconf setup. There are many such issues. And hash_set has been around for much longer, but it is just as optional as unordered_map. (remember, the tr1 items are just a suggestion).
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.
No, I'm not.
And, yes, std::vector and std::string *ALSO* used to have problems. I've shipped software in those days too, and a little config magic made it works beautifully then too. Even system calls such as strstr() might be a problem on certain platforms (ask me about Sun some time if you are wondering).
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?)
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.
A bit... but then again just a tiny bit of autoconf work will make our code use whatever is best for the platform it is compiled on.
But... many times (please note this, as you seemed to have missed this before) using those might not be the best choice. I'm not saying I know that this is one of those cases, but that it *might* be so we should take just a little time to check (I'm trying to stress that we just need to check, and that I'm not sure of things one way or the other yet). Very often instead of trying to make certain operations faster it is better to actually just not do those operations and take a different approach instead.
I'm seeing the potential here of the type of optimization Michael Abrush wrote about where the code optimizations might get to improve performance by a factor of 10 whereas the high-level change of approach can get 100 times the performance. (He also stressed actually measuring to be sure the theoretical actually showed up in the real program).