2007/2/19, Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On February 18, 2007, Rafael Fernández López wrote:<br>> As some users (and myself too) missed the categorization powerful tool for<br>> Konqueror/Dolphin and similars, I've started a bit on it. This new class<br>
> (attached) is right now locally at kdeui/itemviews. The idea is that the<br>> list view, should inherit from this class, and of course, rewrite the<br>> method. This particularly is useful on the new class I'm writing:
<br>> KListView. KListView will give all the benefits for drawing categorized<br>> items in the viewport, so a new list view that wants to add own<br>> categorization, the only thing have to do is inherit KListView and rewrite
<br>> this method. As easy as that. On paintEvent() method at KListView, the<br>> model() will be asked if it is really a QSortFilterProxyModel. If so, it<br>> will ask this method with the corresponding<br>> QSortFilterProxyModel::sortRole() method.
<br><br>sounds like a lot of subclassing, particularly if there are N different views<br>that subclass KItemCategorization (KItemCategorizer?) as then one would need<br>to subclass each listview for each type of categorization (or have one
<br>categorizer that does all kinds of categorizations?)</blockquote><div><br>The main idea is that:<br><br>class KListView<br>    : public QListView<br>    , public KItemCategorization<br><br>so another list views that want to change the categorization will inherit from KListView (where the method is virtual, and returns a QString() by default), and override that method.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">would it be cleaner to simply expect one to sub-class KItemCategorization and<br>
have a setCategorizer(const KItemCategorization& categorizer) method in the<br>listviews? that way one could write categorizers for each type of data set<br>(e.g. one for photos vs one for eBooks or whatever) as desired and re-use
<br>them with whatever listviews support that categorization. this prevents<br>destroying and creating listviews just to change the categorization and would<br>allow greater re-use of categorization code.<br><br>one could also have setCategorizer take a pointer instead of a reference and
<br>take ownership of the object if that's easier ... though pointers are a bit<br>uglier, they can be easier to test for and "clear" (pass in 0)..<br><br>also, the screenshot you provided is from windows. do you have a shot of it
<br>working in kde? (just curious =)</blockquote><div><br>I haven't written paintEvent to take in count this yet. I have to start it when have a bit more time (by the end of this week). This needs some thinking too, for having in count right-to-left languages.
<br></div></div><br><br>Bye,<br>Rafael Fernández López.