Support more ResultType

Having such ResultTypes sounds reasonable to me, but let's ignore the implementation details for now, and think about the `Support more ResultType` topic a bit more:
This bugreport made me realize that the ResultType system as we have it right now does not scale very well. Right now we have 15 different types, and a bugreport like this one will add another eight. At some point we will end in an usability nightmare, where it will be hard for our users to find out which ResultType they want in their query. I must admit it's even right now hard for me to think about the correct type when designing a query, and i expect others, who do not think about zeitgeist daily, having even more problems with them.
So, I think it is the right point in time right now to the about the more general question "How can we support more ResultTypes in a user friendly way?" - and at the end of this process we can easily add the ones requested in this bugreport.

One way which just came into my mind to make things easier to understand is to use a flag system, like

MostRecent = 0x01
LeastRecent = 0x02
MostPopular = 0x04
LeastPopular = 0x08
[...]
Events = 0x0100
Subjects = 0x0200
Actor = 0x0400
[...]

This way the ResultTypes we have right now can be written as

MostRecentEvents => MostRecent | Events
LeastRecentSubjects => LeastRecent | Subjects

And when we feel like adding a new `target` like Interpretation or Manifestation all we have to do is to add two new values

Interpretation = 0x0800
Manifestation = 0x01000

I really don't think that using binary flags helps usability. On the contrary. It just leaves the door open for a tonne of new types of bugs.

How about 'LeastRecent | Subjects | Events' what does that do?

Another problem with the flags system is that it severely limits the number of result types we can have. Consider that extensions (like the FTS) can also "add" their own result types. And by "add" I mean that they export and API like FindEvents() but allow some extra result types in there, but also the default ones - which will then fall back to the normal API for sorting and grouping.

I actually think the current way we do it is pretty nice.

2010/10/7 Mikkel Kamstrup Erlandsen <email address hidden>:
> I really don't think that using binary flags helps usability. [...]
> I actually think the current way we do it is pretty nice.

+1

--
Siegfried-Angel Gevatter Pujals (RainCT)
Free Software Developer       363DEAE3