[Kst] Patch for proposed change to Data Manager dialog

[Adam Treat]

On Thursday 11 January 2007 1:37 pm, Brisset, Nicolas wrote:
> > 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

Well, its important if you run into any more compile errors that are 
workable...

> 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.

The current one has a klistviewsearchlinewidget now.  That does allow for 
filtering on specific stuff.

> > 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 :-)

Sounds feasible :)

> - 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..." ?)

The hint at top would be good.

> - distinguish between user plugins and system-wide plugins somehow
> (color or "*" or anything better)

What does the user care where the plugins come from?

> 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.

Ah, I like this idea of building categories dynamically.  I'll look into it.

Adam