KCategoryView modification proposal

[Rafael Fernández López]

> First we need data structure to take into account categories, only so we
> can
> have a reusable view. This means that we have to create a model for data.

I was going to work on that right now. I need to refactor
KCategorizedView, since it does things (as sorting) that are not related
to a view in the theorical picture, so... yeah, that is what I was going
to do. I am moving "Category" concept itself to the model, too,
instead of having a "Categorizer".

> The
> problem is to have a very fast structure. Please, take into account that
> using
> a c++ object for items and categories can be make fast by using a custom
> allocator, that is a new operator that use a pool (very fast).
>
> We need that, so we can not only reuse this view in others projects, that
> have
> different requirements from Dolphin, but we can use it in others Dolphin
> view
> (as column one). It will be a valuable addition for kde.
>
>
> So I propose to have this structure :
> We have categories containers that owns the items.
> Each container has a state (closed/open), a bounding rectangle for the
> gadgetry and a total space rectangle taking into account the contained
> items.
>
> Each item has a pointer to the real item, a bound rectangle relative to
> the
> parent, a sequence index and a backpointer to the parent.

Mmmm, sounds good.

> With these information we are able to open close categories in a hurry,
> because the calculations are done in the resize/populate phase only.
> The calculation of positions are done at the category first (bounding
> rect),
> then at item. Taking advantage from the fact that the categories are much
> less
> numerous than items we can put some others optimization.

Okay, but here is my question: we could have had this into account very
far before (when starting KCategorizedView indeed). So by design (not
because it wasn't possible, everything is possible, well, almost :), I
thought that (un)folding categories wasn't probably a good feature. That
makes the view harder to use with more hot-spots, and then you have a
beautiful problem: when you fold 3 categories of 8, when you go back to
that folder (or whatever, I don't want to focus KCategorizedView always to
Dolphin, because if a general-use view, but I will do for this example),
then you save which categories were folded or not ?

I really think we shouldn't do every thing Windows do, but yeah, of course
if this is a requested feature it will be done, without any doubt. And I
don't care putting my efforts to something that is wanted-by-everybody,
but I really wonder here if this is so much overengineering a view for
making it (un)folding. And I really wonder if it is necessary.

> The code is almost compiling, but I have few time to finish it and, if you
> agree on this analysis, we can develop it together. In adjoint I have
> little
> qt experience.

Yeah, but please take in count I'm going to do some work these days on
KCategorizedView, so we will probably have to adapt your patch to the
changes only to test it.

Since this is for 4.1 or further, we will do it well. Let's make it work
as a charm as it is right now (without (un)folding feature), then in the
case it is a popular-wanted-feature, we can work on it deeply for 4.1, or
4.2. You know, people love to see this kind of improvings from version to
version, so we reserve ourselves the power to surprise users :)

> For example, when we are looking for the mouse click position we can do a
> binary search in the categories array, then in the selected category
> items.
> If the category is closed, we can use its real size by ignoring items.

I even don't think a binary search on categories is needed. You won't have
(in general, I guess), more than 100 categories.

> I report the 2 data structures as a sample:
> // Gli item
> class KCategoryItem {
>     QModelIndex itemIndex;
>     QRect       bounds;
>     int         sequenceIndex; // sequence
>     KCategoryContainer *parent;
>     public:
>     KCategoryItem::KCategoryItem(KCategoryContainer theParent, const
> QModelIndex index, const int sequence)
>     {
>         parent          = theParent ;
>         itemIndex       = item;
>         sequenceIndex   = sequence ;
>     }
>     KCategoryItem::~KCategoryItem()
>     {
>     }
>
> };
>
> class KCategoryContainer {
>         QString        Name;
>         QRect        TotalBounds; // including childrens
>         QRect        ActualBounds;        // if closed or open
>         QBool        isClosed;                // Or Open
>         QVector<KItemCategory> items;
> public:
>
>     KCategoryContainer::KCategoryContainer(const QString & theName)
>     {
>         Name = theName ;
>         isClosed = false ;
>         items = new QVector<KItemCategory>();
>     }
>
>     KCategoryContainer::~KCategoryContainer()
>     {
>         items->clear();
>     }
>
>     void insertIndex(const QModelIndex index)
>     {
>         KItemCategory *pNewInsert = new KCategoryItem(index, items.size()
> );
>         items.append(pNewInsertzs);
>     }
>     void CalculateSize();
>     int itemCounts() const
>     {
>         return item.size();
>     }
> };

I have lots, lots of questions about this. Let's put the idea,
implementation details right now are very very abstract, since we are
sitting the idea.

What I think it would be the best thing... [please take in count not only
showing items, take in count we need to give support for selections,
keyboard selections, keyboard navigation...] is (don't know if it would
work only with this):

- Having containers as you say. They know their absolute position to the
top of the view, and their size, taking in count all elements that live in
it.

- Having elements into containers. Each element knows its relative
position to the container (and probably the absolute position to the top
of the view).

> NOTE: Column view on Mac is very annoying. I can't have a bird's view over
> my
> files. I can imagine a categorized view with a thin line separing
> different
> blocks of files. ( or maybe different colors). Let's doing right this
> time.

Haven't ever tried Mac. For the detailed view I think Windows XP's is a
very good approach.

> bye
> Luca Bellonda

Bye,
Rafael Fernández López.

2007/7/31, lbell at tsc4.com <lbell at tsc4.com>:
> >> So this kind of technical conversation, has to be private or public?
> >> If you prefer to have it public (but it will generate a lot of traffic, I
> >> think) feel free to post our mails to kfm developer mailing list
>
> >Yeah, from my point of view this conversation should be public. As always,
> >the more eyes looking, the less errors committed by design, better code.
>
> >Bye,
> >Rafael Fernández López.
>
> So I post in list
>
>
> I want to discuss about how to improve KCategoryView including the
> possibility of reusing it in others projects.
> The target can be Kde 4.1 or 4.2 is not a problem, if we can build a
> powerful feature.
>
> First we need data structure to take into account categories, only so we can
> have a reusable view. This means that we have to create a model for data.
> The problem is to have a very fast structure. Please, take into account
> that using a c++ object for items and categories can be make fast by using
> a custom allocator, that is a new operator that use a pool (if we ever
> need it).
>
> We need that, so we can not only reuse this view in others projects, that
> have different requirements from Dolphin, but we can use it in others
> Dolphin views (as the column one). It will be a valuable addition for kde.
>
> So I propose to have this structure :
> We have categories containers that owns the items.
> Each container has a state (closed/open), a bounding rectangle for the
> gadgetry and a total space rectangle taking into account the contained
> items.
>
> Each item has a pointer to the real item, a bound rectangle relative to the
> parent, a sequence index and a backpointer to the parent.
> With these information we are able to open end close categories in a
> hurry, because the calculations are done in the resize/populate phase
> only.
> The calculation of positions are done at the category first (bounding
> rect), then at item. Taking advantage from the fact that the categories
> are much  less numerous than items, we can put some others optimizations.
> For example, when we are looking for the mouse click position we can do a
> binary search in the categories array, then in the selected category
> items.
> If the category is closed, we can use its real size by ignoring items.
>
> The code is not yet compiling, but I have few time to finish it and, if
> someone agree on this analysis, we can develop it together. In adjoint I
> have little qt experience.
>
>
> I report the data structures as a sample:
> // Gli item
> class KCategoryItem {
>     QModelIndex itemIndex;
>     QRect       bounds;
>     int         sequenceIndex; // sequence
>     KCategoryContainer *parent;
>     public:
>     KCategoryItem(KCategoryContainer *theParent, const QModelIndex index,
> const int sequence)
>     {
>         parent          = theParent ;
>         itemIndex       = index ;
>         sequenceIndex   = sequence ;
>     }
>     ~KCategoryItem()
>     {
>     }
>
> };
>
> class KCategoryContainer {
> 	QString	Name;
> 	QRect	TotalBounds; // including childrens
> 	QRect	ActualBounds;	// if closed or open
> 	QBool	isClosed;		// Or Open
> 	QVector<KCategoryItem> items;
> public:
>
>     KCategoryContainer(const QString & theName): isClosed(false)
>     {
>         Name = theName ;
>         items = new QVector<KCategoryItem>();
>     }
>
>     ~KCategoryContainer()
>     {
>         items->clear();
>     }
>
>     void insertIndex(const QModelIndex index)
>     {
>         KCategoryItem *pNewInsert = new KCategoryItem(index, items.size() );
>         items.append(pNewInsertzs);
>     }
>     void CalculateSize();
>     int itemCounts() const
>     {
>         return item.size();
>     }
> };
>
> bye
>
> Luca Bellonda
>
>
>
>


-- 
Bye,
Rafael Fernández López.