[Kst] Patch for proposed change to Data Manager dialog

[Brisset, Nicolas]

> I have just tried this and I think it goes in the right 
> direction (especially removing the double dialog, which is 
> indeed very annoying), but not quite as far as it should. As 
> a matter of fact, I repeatedly see users struggling with the 
> data manager to find objects in awfully long and flat lists. 
> One of the usability improvements I wanted to suggest was the 
> addition of filters to the datamanager. I think we can find a 
> way to make this UI provide a filtering means as well as 
> shortcuts for the creation of new objects.
> I'll try to give a more concrete spec as soon as my ideas 
> have matured a bit...
I still haven't managed to compile a working kst especially as I have
had very little time for that but I have seen the commits. I principally
like the idea of the listview with filter and think it will fullfil
filtering needs quite well. It probably also deviates too much from the
classical (designer) use to have a stacked list (or whatever it's
called) used for filtering. The only improvement I'd suggest is the
ability to also filter by type thanks to a combobox, or even better (and
simple): filter with a regexp or simple comma-separated list of strings
so that you could write e.g. "vector, phi" and get a list of only
vectors with phi (case-insensitive I guess) in their name.

> I also think there are some usability issues like hackerish 
> names and items that appear in multiple places for no reason 
> a standard user would figure out.
To be more constructive on that comment, here is what I'd suggest.
First, change a couple of labels:
- "Primitive Objects" -> "Data Input"
- "Data Objects" -> "Data Analysis"
- "Fit objects" -> "Fits"
- "Filter objects" -> "Filters"
In short, use names that are less technically-oriented :-)
- I also think that some very important data objects (Curve, Equation,
Spectrum, Histogram, Image, CSD) are buried in a too long list of less
often used ones right now and they should be "promoted" somehow, maybe
grouped with "Vector" and "Matrix" in "Basic Objects" even though that
category does not exist in terms of C++ classes (but who cares ?)
- then, add a label at the top of the stacked list to indicate that
clicking below will create a new object of that type (maybe "Create
new..." ?)
- distinguish between user plugins and system-wide plugins somehow
(color or "*" or anything better)

In fact, the categories are not really user-friendly even with better
names. I think the better approach here would be to add a method like
registerCategory(const QStringList&) to plugins that would do more or
less the same as the "fit" or "filter" tags there used to be in the .xml
description (by the way, where have these gone ?). That is, indicate the
kind of plugin it is and in which category it should appear. We'd build
the list of categories dynamically then.

Nicolas