[Nepomuk] Nepomuk facets

[Sebastian Trüg]

Please find attached another go at the facet class and a draft for some
FacetModel methods.
Currently my version of Facet is not a QObject and does not emit changed
signals. IMHO we simply need a container to store the possible choices
in. The model could then take care of the rest.

Have a look at it and share thoughts, please.

Cheers,
Sebastian

On 06/21/2010 01:36 PM, Sebastian Trüg wrote:
> On 06/21/2010 12:23 PM, Alessandro Sivieri wrote:
>> 2010/6/21 Sebastian Trüg <trueg at kde.org <mailto:trueg at kde.org>>
>>
>>     The thing is that I would like the make the facet stuff public API for
>>     KDE 4.6. That is why I am picking on it and being a pita. :P
>>
>>
>> :D
>> Then I can search a different term for "Term", but "Facet" must retain
>> its name, which is its academia name :)
> 
> Do we really need an extra public class for Term? Isn't that something
> that can be handled internally?
> 
>>     Do you actually want to create different representations for different
>>     types of facets. The only exception I can see is the rating. But that
>>     could easily be filtered out and added as a separate gui element.
>>
>>
>> Well, currently my answer should be "yes" (looking at Sembrowser), but
>> actually is "no": in the Web world, faceted browsing does not use
>> different representations for facets, it uses a uniform one, so in the
>> end I am for uniform representation also here :)
> 
> And are you really using different representations? The way I see it you
> have only different representations for exclusive and non-exclusive
> groups. The latter being tags.
> 
>> The only thing I am objecting here is that a model should support only
>> one facet (or one facetgroup, following your name), because I really
>> don't know if it makes sense to show more than one facet in the same UI.
>> Even if you use the same representation (say, a listview), then each
>> listview should have its model instance, and each model instance should
>> have one facet, and each facet n terms.
> 
> Then a model does not makes any sense at all anymore. :)
> The way I see it the list of facets (and here I am using your wording -
> the correct one) needs to be handled by one manager class anyway. And if
> that class is flexible enough (via addFacet methods or subclassing) then
> there is no need for anything else.
> After all you will always need all facets and not just one of them.
> 
> Cheers,
> Sebastian
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facet.h
Type: text/x-c
Size: 3671 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20100625/e87e8e20/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facetmodel.h
Type: text/x-c
Size: 2746 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20100625/e87e8e20/attachment-0001.bin