Qt-interest Archive, December 2006
Re: QAbstractItemModel with external data source/model
Message 1 in thread
On Tuesday 14 November 2006 11:26, Bjørn Ullevoldsæter wrote:
> Hi.
>
> I know there has been some discussions around the use of QModelIndex and
> its InternalPointer to reference items in the data source when
> implementing a custom data model based on QAbstractItemModel.
>
> In our case, we are developing a C++ library with an external tree based
> data source, which also acts as its own model. That is, the library
> communicates with the Qt "wrapper" layer by means of our own indeces.
> Eg. The interface in the qt code recieving a change in the data source
> looks like this:
>
> void entries_added(const tree_index& begin_index, int count);
>
> This means that I don't have access to a persistent tree item (like in
> the simple TreeView example:
>
> http://doc.trolltech.com/4.2/itemviews-simpletreemodel.html
>
> My problem is then: How to store a reference in QModelIndex, using the
> InternalPointer (I suppose??) to an object which is only an index, not
> the actual tree item? Hash table is not the answer.
>
> My problem would be solved if QModelIndex::InternalPointer could take
> some sort of ownership of my tree_index, so the lifetime of a
> QModelIndex object and the corresponding tree_index followed each other.
>
> I'd, appreciate any view on using QAbstractItemModel with an external
> data source, when the implementation gets a little more complicated than
> simply using internal pointers to existing tree items.
>
> Thanx!
>
> Bjørn
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
Reading through the thread please correct anything I got wrong from my
understanding. You recieve information about an internal model such as this:
void entries_added(const tree_index& begin_index, int count);
And tree_index is a short lived variable that points to some long term
internal structor.
Qt's itemview classes require that QModelIndex's don't change over time. For
example I should be able to call index(0, 0) several times and always get the
exact same QModelIndex. If you could put a tree_index pointer inside a
QModelIndex it would be different every time which is were you are today.
But If the tree_index has a operator== you could make a list or hash and then
put the lookup value in the create index. Or if you had access to an id of
the tree_index you could use that which would be even better.
-Benjamin Meyer
--
[ signature omitted ]
Message 2 in thread
Thanx for the reply. We have actually changed our internal library
architecture now and rejected the tree_index approach in favour of an
API that give access to persistent tree items of a known type.
This means that my case is solved. I'm simply using AbstractItemModel
with QModelIndex and its internal void pointer as it is implemented in
4.2 today.
But, having to use a void pointer and static cast, is clearly a sign of
inadequate design, so I would, as others have suggested in this thread,
also like to see some kind of typing of QModelIndex's internal_pointer
and/or some sort of lifetime management of the pointed-to object. A
possibility to provide a custom deleter, maybe, like in
boost::shared_pointer?
Regards,
Bjørn Ullevoldsæter
Benjamin Meyer wrote:
> On Tuesday 14 November 2006 11:26, Bjørn Ullevoldsæter wrote:
>> Hi.
>>
>> I know there has been some discussions around the use of QModelIndex and
>> its InternalPointer to reference items in the data source when
>> implementing a custom data model based on QAbstractItemModel.
>>
>> In our case, we are developing a C++ library with an external tree based
>> data source, which also acts as its own model. That is, the library
>> communicates with the Qt "wrapper" layer by means of our own indeces.
>> Eg. The interface in the qt code recieving a change in the data source
>> looks like this:
>>
>> void entries_added(const tree_index& begin_index, int count);
>>
>> This means that I don't have access to a persistent tree item (like in
>> the simple TreeView example:
>>
>> http://doc.trolltech.com/4.2/itemviews-simpletreemodel.html
>>
>> My problem is then: How to store a reference in QModelIndex, using the
>> InternalPointer (I suppose??) to an object which is only an index, not
>> the actual tree item? Hash table is not the answer.
>>
>> My problem would be solved if QModelIndex::InternalPointer could take
>> some sort of ownership of my tree_index, so the lifetime of a
>> QModelIndex object and the corresponding tree_index followed each other.
>>
>> I'd, appreciate any view on using QAbstractItemModel with an external
>> data source, when the implementation gets a little more complicated than
>> simply using internal pointers to existing tree items.
>>
>> Thanx!
>>
>> Bjørn
>>
>> --
>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>> "unsubscribe" in the subject or the body. List archive and information:
>> http://lists.trolltech.com/qt-interest/
>
> Reading through the thread please correct anything I got wrong from my
> understanding. You recieve information about an internal model such as this:
>
> void entries_added(const tree_index& begin_index, int count);
>
> And tree_index is a short lived variable that points to some long term
> internal structor.
>
> Qt's itemview classes require that QModelIndex's don't change over time. For
> example I should be able to call index(0, 0) several times and always get the
> exact same QModelIndex. If you could put a tree_index pointer inside a
> QModelIndex it would be different every time which is were you are today.
> But If the tree_index has a operator== you could make a list or hash and then
> put the lookup value in the create index. Or if you had access to an id of
> the tree_index you could use that which would be even better.
>
> -Benjamin Meyer
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 3 in thread
On Wednesday 15 November 2006 14:13, Charley Bay wrote:
> IMHO, the Qt Model/View is very well designed, with a quite
> serious Achilles' Heel in QModelIndex. It's hurting me, and
> I believe others, in "common cases". (Not to overstate, it merely
> means I can't use the model/view infrastructure in cases it was
> designed to be used -- the costs are too high.)
By costs, do you mean that for the common tree scenario it is often easiest to
create an internal tree structure or performance issues that you are finding?
QModelIndex was never designed to carry items, but to just be references to
internal objects.
-Benjamin Meyer
--
[ signature omitted ]
Message 4 in thread
> Charley spaketh:
>> IMHO, the Qt Model/View is very well designed,
>> with a quite serious Achilles' Heel in QModelIndex.
>> It's hurting me, and I believe others, in "common
>> cases". (Not to overstate, it merely means I
>> can't use the model/view infrastructure in cases it
>> was designed to be used -- the costs are too high.)
Benjamin Meyer respondeth:
> By costs, do you mean that for the common tree
> scenario it is often easiest to create an internal
> tree structure or performance issues that you are
> finding? QModelIndex was never designed to carry
> items, but to just be references to internal
objects.
It makes sense that QModelIndex merely *references*
objects (and that's how I'm trying to use it).
However, the current QModelIndex implementation
*assumes* all items referenced within a given model
will be of the same type. (The model must know
how to cast the void* inside QModelIndex, without any
hints.)
I think that assumption fails for a number of "normal"
cases. After all, in a tree, "leaf" and "node" items
aren't the same type. (Some of the previous thread
discussed the merits of demanding that "leaf" and
"node" share the same base class, but I claim that
can't/won't be done in many normal cases.)
If QModelIndex could reference my existing instances,
all would be well. (For example, if QModelIndex had
a "char" that I could treat as "MyEnumType", then I
would know how to cast the "void*" that is stored
inside the QModelIndex.)
All of the previous thread talked about the merits
of this and other work-arounds.
My reference for "the costs are too high" relate to
the only other work-around that seemed reasonable:
Make a "shadow" tree of my custom wrappers, so that
the QModelIndex would reference the wrapper type,
which has type information to point at the "real"
thing. Synchronizing my "wrapper tree" to the "real
model tree" is costly, made even more difficult
because I don't know when the QModelIndex is done
referencing a given wrapper instance.
That lead to another possible QModelIndex design
change: If QModelIndex would *wholly contain* a
wrapper, then I don't mind using wrappers (because
I wouldn't have to manage a monstrous tree of them
synchronized to my real model).
For example (a possible QModelIndex design change):
QModelIndex replaces the internal void* with a
"QModelIndexState*" (or some Qt-name) that allows
QModelIndex to take ownership (and delete) the
referenced thing. It could *always* delete the
non-null referenced thing, or it could call a
virtual "QModelIndexState::isOwnedByQModelIndex()"
to determine if it should be deleted. Users like me
would derive from QModelIndexState to create our own
"wrappers" with whatever model context we needed,
knowing the wrappers will be cleaned up with the
lifecycle of the QModelIndex.
In summary, I see two reasonable options for
QModelIndex design changes:
(1) QModelIndex add a char/short that I can use as
"MyEnum" to know how to cast the void*.
Pro: Really simple to implement.
Con: Increases the size of QModelIndex.
(2) QModelIndex references a QModelIndexState that
it owns or references.
Pro: Very flexible and powerful, doesn't add
to the current size of QModelIndex.
Con: QModelIndex doesn't have a void* anymore
(existing code must change), and users are
forced to implement a wrapper.
What do you think -- does this make sense?
--charley
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
[ signature omitted ]
Message 5 in thread
I still dont understand, why you are willing to have the trolls re-write/re-impl the Model/View architecture, and all its complexities/nicities... Because you dont want to write a wrapper struct/class for your heterogenous container problem.
I understand that you feel (with no corroborating evidence but your own history of development) that most if not all custom models will have a heterogenous data pointer (if they are using the data pointer at all).
However, I feel, (with no corroborating evidence but my own history of development), that you can take 2 approaches to the Model approach. Use it as a GUI only system, and thus, should have a layer of abstraction between the GUI and core datastructures. So, creating a wrapper class around the heterogenous to provide a homo-geneous solution is perfectly acceptable... Or use the QModel as a core data structure, in which, you would recognize it as a homogeneous only container, and thus would re-write your base datastructure to fit it.
But, forcing a SIGNFICANT change (read binary incompatible, thus 4.3 at a minimum) that would require all QModel/View code bases to be re-written seems unreasonable, simply because you want a homogeneous system to be heterogenous. Also, I would NOT want the model index to store any more then it does today, for fear of major increases in system resources.
Creating a wrapper structure, with creation on demand, and proper lfespan, is not difficult, nore is unreasonable.
And as I have, the majority of my trees, tend to be homogenous to some base object. Why? because I am more concerned with code maintenence and ease of development, then I am about the bytes wasted on extraneous virtual tables...
However, to double the size of a qmodel index, for a QTable could be a HUGE hit to the system. Adding your char for RTTI, seems a bit backwards. Im not a huge fan of RTTI, an prefer properly designed virtual functions. However, I do see the need for them. To then turn around and say, well, i dont want RTTI from C++/QT, I want an enum, seems a bit backwards....
Scott
________________________________
From: Charley Bay [mailto:charleyb123@xxxxxxxxx]
Sent: Mon 12/4/2006 12:49 PM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: QAbstractItemModel with external data source/model
> Charley spaketh:
>> IMHO, the Qt Model/View is very well designed,
>> with a quite serious Achilles' Heel in QModelIndex.
>> It's hurting me, and I believe others, in "common
>> cases". (Not to overstate, it merely means I
>> can't use the model/view infrastructure in cases it
>> was designed to be used -- the costs are too high.)
Benjamin Meyer respondeth:
> By costs, do you mean that for the common tree
> scenario it is often easiest to create an internal
> tree structure or performance issues that you are
> finding? QModelIndex was never designed to carry
> items, but to just be references to internal
objects.
It makes sense that QModelIndex merely *references*
objects (and that's how I'm trying to use it).
However, the current QModelIndex implementation
*assumes* all items referenced within a given model
will be of the same type. (The model must know
how to cast the void* inside QModelIndex, without any
hints.)
I think that assumption fails for a number of "normal"
cases. After all, in a tree, "leaf" and "node" items
aren't the same type. (Some of the previous thread
discussed the merits of demanding that "leaf" and
"node" share the same base class, but I claim that
can't/won't be done in many normal cases.)
If QModelIndex could reference my existing instances,
all would be well. (For example, if QModelIndex had
a "char" that I could treat as "MyEnumType", then I
would know how to cast the "void*" that is stored
inside the QModelIndex.)
All of the previous thread talked about the merits
of this and other work-arounds.
My reference for "the costs are too high" relate to
the only other work-around that seemed reasonable:
Make a "shadow" tree of my custom wrappers, so that
the QModelIndex would reference the wrapper type,
which has type information to point at the "real"
thing. Synchronizing my "wrapper tree" to the "real
model tree" is costly, made even more difficult
because I don't know when the QModelIndex is done
referencing a given wrapper instance.
That lead to another possible QModelIndex design
change: If QModelIndex would *wholly contain* a
wrapper, then I don't mind using wrappers (because
I wouldn't have to manage a monstrous tree of them
synchronized to my real model).
For example (a possible QModelIndex design change):
QModelIndex replaces the internal void* with a
"QModelIndexState*" (or some Qt-name) that allows
QModelIndex to take ownership (and delete) the
referenced thing. It could *always* delete the
non-null referenced thing, or it could call a
virtual "QModelIndexState::isOwnedByQModelIndex()"
to determine if it should be deleted. Users like me
would derive from QModelIndexState to create our own
"wrappers" with whatever model context we needed,
knowing the wrappers will be cleaned up with the
lifecycle of the QModelIndex.
In summary, I see two reasonable options for
QModelIndex design changes:
(1) QModelIndex add a char/short that I can use as
"MyEnum" to know how to cast the void*.
Pro: Really simple to implement.
Con: Increases the size of QModelIndex.
(2) QModelIndex references a QModelIndexState that
it owns or references.
Pro: Very flexible and powerful, doesn't add
to the current size of QModelIndex.
Con: QModelIndex doesn't have a void* anymore
(existing code must change), and users are
forced to implement a wrapper.
What do you think -- does this make sense?
--charley
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com <http://mail.yahoo.com/>
--
[ signature omitted ]
Message 6 in thread
Scott spaketh:
> I still dont understand, why you are willing to have
> the trolls re-write/re-impl the Model/View
> architecture, and all its complexities/nicities...
> Because you dont want to write a wrapper
> struct/class for your heterogenous container
> problem.
A bit of an overstatement -- We're talking about
keeping everything the same, but modifying the
QModelIndex.
Also, I'm only replying to a question as to why
I find the current design expensive to use in
what I'm describing as "common cases". (I do
concede the point that you understand the issue,
and we merely disagree on priorities.)
> I understand that you feel (with no corroborating
> evidence but your own history of development) that
> most if not all custom models will have a
> heterogenous data pointer (if they are using the
> data pointer at all).
If the application has business-logic data structures
that are to be presented in the GUI as a tree (whether
or not they are implemented in some internal
"tree-structure"), the current QModelIndex can't
handle that without a work-around (e.g., create and
manage a mirror-tree of homogeneous wrappers).
I claim this to be a common case.
> However, I feel, (with no corroborating evidence but
> my own history of development), that you can take 2
> approaches to the Model approach. Use it as a GUI
> only system, and thus, should have a layer of
> abstraction between the GUI and core datastructures.
> So, creating a wrapper class around the
> heterogenous to provide a homo-geneous solution is
> perfectly acceptable... Or use the QModel as a core
> data structure, in which, you would recognize it as
> a homogeneous only container, and thus would
> re-write your base datastructure to fit it.
Even if QModel was your core data structure, you
have no idea what type a QModelIndex references.
That's the problem. None of the rest of the
model/view design has this problem, which is why I
referred to it as the, "Achilles' heel".
Wrappers are cheap if I can create-and-destroy
wrappers as needed, and expensive if I must maintain
a mirror data structure for all wrapper instances for
all items in the model.
> But, forcing a SIGNFICANT change (read binary
> incompatible, thus 4.3 at a minimum) that would
> require all QModel/View code bases to be re-written
> seems unreasonable, simply because you want a
> homogeneous system to be heterogenous. Also, I
> would NOT want the model index to store any more
> then it does today, for fear of major increases in
> system resources.
Yes, changes to QModelIndex would be
binary-incompatible. However, it won't require
much of a change to the internal QModel/View classes
(I'll defer to the trolls on that, but QModelIndex
has value semantics, and the current void* is treated
as opaque by the Qt libraries). Yes, it would require
changes to the user's models that create and use the
QModelIndex instances.
I understand the concern about growing the size
of QModelIndex, but instantiating a wrapper tree
for all items would consume more than a char per
item.
> Creating a wrapper structure, with creation on
> demand, and proper lfespan, is not difficult, nore
> is unreasonable.
Perhaps the trolls or someone could post code that
does this?
> And as I have, the majority of my trees, tend to be
> homogenous to some base object. Why? because I am
> more concerned with code maintenence and ease of
> development, then I am about the bytes wasted on
> extraneous virtual tables...
Our data structures are not designed in consideration
of GUI display decisions, and that control often does
not exist for many classes.
> However, to double the size of a qmodel index, for a
> QTable could be a HUGE hit to the system. Adding
> your char for RTTI, seems a bit backwards. Im not a
> huge fan of RTTI, an prefer properly designed
> virtual functions. However, I do see the need for
> them. To then turn around and say, well, i dont
> want RTTI from C++/QT, I want an enum, seems a bit
> backwards....
The proposed option (2) would be good then, right?
No size hit, plenty of context? Yes, the penalty is
an interface change -- it's not a void* anymore.
Does that mean the problem is really that we don't
want the burden of an interface change?
Option (1) seemed like a reasonable work-around that
didn't require an interface change, and which
de-couples the model/view libraries from all
application-specific types (yes, at the expense
of growing QModelIndex).
I'm not trying to beat a dead horse -- I think the
community would benefit from a "state-of-the-art"
example implementation for a (tree-)model of
heterogeneous data types (which I claim to be a common
case). It seems like that should be easy because of
the obvious elegance in all of the model/view design,
but I find myself working much harder than I'd like.
--charley
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
--
[ signature omitted ]
Message 7 in thread
Hi folks,
I must say I would probably **vote** for Charles' suggestions.
Three small points :
POINT 1 ===> it would be nice to have QModelIndexes have references to the
internal data structure of any type and size.
Benjamin Meyer wrote:
> QModelIndex was never designed to carry items, but to
> just be references to internal objects.
Yes, sure, right.
But in the current implementation, QModelIndex needs the references to be
type pointers, or qint64, ie references of size_of less than 64 bits.
There are (many?) cases in which references to an item in the internal data
structure is necessarily of a bigger size.
We've heard of various such cases on qt-interest, and I myself encountered
one of them.
Given the current implementation, I could nothing but but :
- allocate and maintain a mirror-data structure that somehow duplicate the
internal data structure, but can be referenced by a pointer
- let QModelIndex carry a pointer to this duplicated data structure
Painful, in fact...
POINT 2 ===> I also think one would need to let QModelIndex carry a typed
pointer, such as Charle's QModelIndexInternalData *.
POINT 3 ===> In addition, I would have really appreciated a mean to let
QModelIndex delete its internal data, as proposed by Charles. Though, this
is a perhaps a bit more costly and complicated (memory should be
dynamically allocated, the copy constructor then should allocate memory,
etc. which may be a problem given the huge number of calls to QModelIndex's
methods in Qt).
Now, as far as I understand, implementing the modifications proposed by
Charles would not be toooooo hard.
One would need to add a QModelIndexInternalData class, and modify
QModelIndex :
- add a attribute that let QModelIndex know which type of data it carries
- add a method createIndex(.., ..., QModelIndexInternalData, bool
shouldDelete)
I am quite sure these changes would be backward compatible.
Benjamin, correct me if I am wrong ;=)
Best-
Nicolas
--
[ signature omitted ]
Message 8 in thread
If we are voting on a new QModelIndex system, a couple of things need to
be kept in mind..
First, I really would love to make the internal pointer typesafe. Ie get
rid of the void *, however, that FORCES a homogenous solution....
I don't think I quite understand the difference between the
QModelIndexInternalData system and the "wrapper" class that has been
thrown around, except who owns the lifespan of the wrapper...
QModelIndexInternalData is essentially making the QModelIndex void*
pointer to be a homogeneous pointer of type QModelIndexInternalData *,
where you could derive from it, extend it, etc etc. but it knew when to
delete it etc... and it (the QMI) knows when its invalid...
However, you can do this yourself... At best the QModelIndexInternalData
will only be able to invalidate it when the modelindex is no longer
needed. But not when you make it invalid.
What I think would be really nice, is a simple way to get a notification
(non-signal since the moc adds quite a bit to the object size) of when
the modelindex is no longer needed. Then we could delete and internal
pointer necessary. Since only non-QPMI are supposed to be stored, we
should be safe with not having to notify them when we kill out backend.
Scott
> -----Original Message-----
> From: Nicolas Castagne [mailto:castagne@xxxxxxx]
> Sent: Tuesday, December 05, 2006 1:19 AM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: RE: QAbstractItemModel with external data source/model
>
> Hi folks,
>
> I must say I would probably **vote** for Charles' suggestions.
>
> Three small points :
>
> POINT 1 ===> it would be nice to have QModelIndexes have references to
the
> internal data structure of any type and size.
>
> Benjamin Meyer wrote:
> > QModelIndex was never designed to carry items, but to
> > just be references to internal objects.
>
> Yes, sure, right.
> But in the current implementation, QModelIndex needs the references to
be
> type pointers, or qint64, ie references of size_of less than 64 bits.
> There are (many?) cases in which references to an item in the internal
> data
> structure is necessarily of a bigger size.
> We've heard of various such cases on qt-interest, and I myself
encountered
> one of them.
>
> Given the current implementation, I could nothing but but :
> - allocate and maintain a mirror-data structure that somehow duplicate
the
> internal data structure, but can be referenced by a pointer
> - let QModelIndex carry a pointer to this duplicated data structure
>
> Painful, in fact...
>
>
> POINT 2 ===> I also think one would need to let QModelIndex carry a
typed
> pointer, such as Charle's QModelIndexInternalData *.
>
>
> POINT 3 ===> In addition, I would have really appreciated a mean to
let
> QModelIndex delete its internal data, as proposed by Charles. Though,
this
> is a perhaps a bit more costly and complicated (memory should be
> dynamically allocated, the copy constructor then should allocate
memory,
> etc. which may be a problem given the huge number of calls to
> QModelIndex's
> methods in Qt).
>
>
> Now, as far as I understand, implementing the modifications proposed
by
> Charles would not be toooooo hard.
> One would need to add a QModelIndexInternalData class, and modify
> QModelIndex :
> - add a attribute that let QModelIndex know which type of data it
carries
> - add a method createIndex(.., ..., QModelIndexInternalData, bool
> shouldDelete)
>
> I am quite sure these changes would be backward compatible.
> Benjamin, correct me if I am wrong ;=)
>
>
> Best-
> Nicolas
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 9 in thread
I don't want to spam this thread, and makes it unreadable for the Trolls,
but... a short answer.
Scott Aron Bloom wrote:
> If we are voting on a new QModelIndex system, a couple of things need to
> be kept in mind..
Quite sure we are not voting yet :=)
> What I think would be really nice, is a simple way to get a notification
> (non-signal since the moc adds quite a bit to the object size) of when
> the modelindex is no longer needed. Then we could delete and internal
> pointer necessary. Since only non-QPMI are supposed to be stored, we
> should be safe with not having to notify them when we kill out backend.
Mmmhhh... The QModelIndex is "no_longer needed"... precisely when it is
deleted.
Hence, having a method
bool QModelIndexInternalData::isPossessedByTheQModelIndex()
may make it, allowing QMOdelIndex to delete its internal data * in its
destructor, or copy-construct it in its copy constructor.
Even beter perhaps (but is it possible and cheap ?) : using the Qt's
implicit-sharing mechanism, so that a QModelIndexInternalData could be
shared by various QModelIndexes when it is possesed by the QModelIndex,
avoiding the memory duplication of the QModelIndexInternalData when
duplicating a QModelIndex (affectation, etc.).
Best-
Nicolas
BTW, dear trolls & Benjamin, you may have guessed this, but just to make
sure there is no misunderstanding ... :
I post in this thread precisely because I like much the QModel-view
framework, and would enjoy to help improving it if possible...
and not because I dislike it or critisize it !
And I am quite sure it is the same for most of us here ;=)
--
[ signature omitted ]
Message 10 in thread
Nicolas spaketh:
> BTW, dear trolls & Benjamin, you may have guessed
> this, but just to make sure there is no
> misunderstanding ... :
> I post in this thread precisely because I like much
> the QModel-view framework, and would enjoy to help
> improving it if possible... and not because I
> dislike it or critisize it ! And I am quite sure it
> is the same for most of us here ;=)
Ditto! To echo Nicolas, IMHO the model/view
architecture in Qt4 is *very* well designed, and holds
numerous advantages, far beyond other libraries that
have attempted this in the past 20-30 years.
I view these discussions on QModelIndex as minor
design modifications (although they may imply some
level of binary incompatibility with today's
libraries.)
The Qt model/view already the best out there (by far).
If changes are made, its intended "to make the best
better". ;-)
--charley
____________________________________________________________________________________
Have a burning question?
Go to www.Answers.yahoo.com and get answers from real people who know.
--
[ signature omitted ]
Message 11 in thread
> BTW, dear trolls & Benjamin, you may have guessed this, but just to make
> sure there is no misunderstanding ... :
> I post in this thread precisely because I like much the QModel-view
> framework, and would enjoy to help improving it if possible...
> and not because I dislike it or critisize it !
> And I am quite sure it is the same for most of us here ;=)
And we like getting feedback, because without it, it has hard to know what
really needs improving. I don't mean to come off as against any ideas, I
just want to make sure I fully understand how you guys are using it. The one
thing I can say for sure is that any ideas that require source or binary
incompatible changes wont go in until Qt 5. :)
-Benjamin Meyer
--
[ signature omitted ]
