[Qt-interest] sketcher program

phil prentice philp.cheer at talktalk.net
Mon May 9 08:53:35 CEST 2011


Thanks Mihail
  Data duplication.  I'm afraid that I find some of this stuff difficult to 
fully comprehend.
In the Qt book "C++ Gui programming with QT4" it says the following under 
item-view classes:-
"
In many situations we need to present only relatively small numbers of items 
to the user. In these common cases, we can use QT's convienance item view 
classes(QListWidget etc) and populate them with items directly.  These 
classes behave in a silimlar way to the item view classes provided by earlier 
versions of Qt.  They store thrir data in "items" (e.g. QTableWidget contains 
QTableWidgetItems). Internally the convienance classes use custom models that 
make the items visible to the views,

For larger sets duplicating the data is often not an option. In these cases, 
we can use Qt's views (QLIstView etc) in conjunction with a data model, which 
can be a custom model or one of QT's pre-defined models.
"

 Now I can see how this can work with SQL databases.  How do you make this 
work with general large chunks of data.  For example  could you setup the 
Qt::UserRole to be a pointer that points into your large database and so then 
your delegate would have access to the one and only one chunk of data???
Is this the sort of thing that we are saying here?  Or am I completely off 
track??

Elsewhere in the book it says:-

Item Based Rendering with Graphics View
===============================
"
Drawing using QPainter is ideal for custom widgets and for drawing one or just 
a few items. For graphics in which we need to handle anything from a handful 
up tp tens of thousands of items, and we want the user to be able to click, 
drag and select items Qt's graphics view classes provide the solution we 
need.
"

Now I assume that the graphics view classes are again convienace classes and 
so basically represent data duplication. I havent looked into this yet, so I 
dont know if data duplication can be avoided (i.e. if you have a main 
database of information and you want to display it can you associate that 
data with QGraphicsLineItems etc).  Probably not.

So does this mean that if you want the power of the Qt's graphics view classes 
(draw etc) then we need to duplicate the data, otherwise we need to use 
QPainter to perform the drawing of the items etc and also implement the 
dragging etc using signals and slots etc ourselves.

So basically its a design decision to whether you duplicate data or do your 
own drawing. And probably in most cases because of the power of PC's these 
days, one would go for the data duplication.  If you are short of memory then 
you might draw the items yourself and not use the convienance classes.

Thanks for reading this, and I hope that what I am saying here makes some 
sense.

Thanks again.


On Saturday 07 May 2011 09:41, Mihail Naydenov wrote:
> Define "data  duplication"?  You can aways "bake" information - draw an
> item yourself, instead of using lots and lots of items (in which GS is
> actually very good at).
>
>
>
> 
> Mihaiaydenov 
>
>
> ----- Original Message ----
>
> > From: phil prentice <philp.cheer at talktalk.net>
> > To: qt-interest at qt.nokia.com
> > Sent: Sat, May 7, 2011 10:13:48 AM
> > Subject: Re: [Qt-interest] sketcher program
> >
> > Having now had a bit more of a read, I now realise that  I should use the
> > QGraphicsView class. I think that I got side-tracked by the Model-View
> > architecture. because I wanted to understand it a lot more.  However it 
> > looks
> >
> > like the QGraphicsView class will do most of what I need.  I  still have
> > one question.  It looks like that I will need to create a  scene with
> > loads of QT graphics items in it.  Suppose I have a database  (e.g. a
> > garden design) which
> >
> > has loads of other information in it (plant  types, soil types etc) would
> > this
> >
> > mean that you would end up with data  duplication i.e. each item would
> > hold duplicate data of element positioning  as your main database.  Is
> > that just something that you would except as  part of the design?  I
> > think the answer is
> >
> > probably yes, because as a  result you get the extra functionality of the
> > graphics items?  As a  result though if your database is massive then
> > there would be a lot of data  duplication.  Anyway I will start writing
> > the app using the  QGraphicsView class.
> >
> > Thanks again
> >
> > On Friday 06 May 2011 20:03,  phil prentice wrote:
> > > Hi
> > >   Recently I have been looking at  an MFC example of a program that
> > > lets you draw lines, circles, polylines  etc in an MDI.  As a little
> > > exercise for myself I have decided to  try to perform the same
> > > functionality using Qt. (I know its probably  already been done, but I
> > > would like to go through the exercise myself to  try and learn!!)
> > > I have some very basic questions about the model view  architecture.
> > > And I need to read a lot more.
> > > I would eventually  like to create a Model view (QStandardItem model or
> > > a custom model), but  to start with I thought that I might try and use
> > > the item view  conveniance classes.
> > >
> > > I was thinking of using  QListWidget.
> > > I was thinking of deriving an element base class from  QListWidgetItem
> > > and then deriving line, circle etc from the element  base(using a
> > > virtual draw function for each element)
> > >
> > > I  would then use setItemDelegate for editing/displaying the  elements.
> > >
> > > Is this a stupid idea?
> > > Would this be very  inefficient?
> > >
> > > I know that QListWidget is normally used to store  text and icons, so
> > > if I extend it like this its probably not the way to  do things?
> > >
> > > Thanks
> > >
> > >  _______________________________________________
> > > Qt-interest mailing  list
> > > Qt-interest at qt.nokia.com
> > >  http://lists.qt.nokia.com/mailman/listinfo/qt-interest
> >
> > _______________________________________________
> > Qt-interest  mailing list
> > Qt-interest at qt.nokia.com
> > http://lists.qt.nokia.com/mailman/listinfo/qt-interest



More information about the Qt-interest-old mailing list