[Kst] Patch for proposed change to Data Manager dialog

[Brisset, Nicolas]

> Well, its important if you run into any more compile errors 
> that are workable...
Right now, I have a libtool error 1 problem on Solaris I haven't figured
out yet. On Linux I managed to compile after the qhbox.h fix, but it bus
faults on startup :-( I have to investigate so that I can at least give
you useful information to find and fix the problems, but I really
haven't had so much time these last few days.

> > 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.
Yes, I have seen that sort of thing, e.g. in amarok. But I fear it does
not support multiple search strings as I suggest. If I input "vector,
phi" it will look for that exact string and most probably return nothing
instead of lines matching both patterns "vector" and "phi". Regexps are
in fact a bit too hackerish for the regular user, and considering the
probability of having commas in objects names I think it would be a good
"delimiter". And even if a name contains a comma, it will be shown so no
big deal here.  

> > 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 hope so ! Even I could do it :-) 
 
> > - 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.
Yes, I think this is so easy that we should do it in any case.

> > - distinguish between user plugins and system-wide plugins somehow 
> > (color or "*" or anything better)
> 
> What does the user care where the plugins come from?
The first problem is that there is nothing that prevents you from
writing a plugin that has the same visible name in the list as a system
plugin. And if you once installed a couple (or even a lot) of custom
plugins, some of which may not even work in the meantime, the list can
grow very long. At some point (like in my case, where I have some custom
plugins that are development versions of things I then committed to
trunk !) this becomes hard to manage. I just think it could be useful to
distinguish custom plugins, though for some users (like those who don't
have any) that sure doesn't bring a lot :-)

> Ah, I like this idea of building categories dynamically.  
> I'll look into it.
Cool :-) What I'd suggest then is to implement that, and then build a
text file with a list of available plugins with a couple of columns:
plugin function name, visible name, description, categories. I'm pretty
sure we can converge on a set of useful categories, some plugins may
appear in more than one although in general we should try to avoid that
I think. And to solve the above wish (distinguish custom plugins) we
could arrange for them to appear in a "Custom plugins" category along
with the functional category the user may add in the plugin itself.
Sounds good to me :-)

Thanks for your support,

Nicolas