Hi, Le 10/06/2016 15:34, Tudor Girba a écrit :
Hi,
On Jun 10, 2016, at 10:24 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote: ...
Another thing that doesn't work too well with Spotter: I like to restrict the scope to a single package / group of package, either before the search, or after (making it easy to turn off large subsets of the search results).
Some scoping can be easily added. For example, if we would add a Senders processor for a Package we could scope it for that package.
This is effectively what I use, but linked with scoping in the browser: scope, then search. It's like taking your conversation metaphor around: start sustained, increment or create new threads by search. My interface uses the finder; I wondered at one point if I could reuse Spotter instead (i.e. have a spotter bar instead of the finder bar I have at the moment in the browser).
To scope this for a group of packages is where things become more interesting. The current idea is to allow each processor to provide a typed group and provide processors in that class. For example, diving-in-category of a package category, could provide us not a plain collection, but a PackageCollection (or PackageGroup), and there we could again have processors like Senders. This is something we need to play with some more.
Any related ideas?
I'm not sure creating groups per processor is a good idea. I know that I rely a lot on the fact that the groups are constant to be able to use them. If they were changing based on the processor, then I would find that very messy: imagine a classification where the group GUI contains different packages depending on whether you're searching for a sender, a pragma or an implementor? At the same time, I'm the only one using a complete and constant set of groups of packages for years already among you, so I know my results can't be generalized. Thierry
Cheers, Doru