[Qt-interest] showEvent in QGraphicsView - question about when to draw

[Mihail Naydenov]

Yes solution 2 is reasonable. The only problem is it is too general - it will 
affect the entire scene and all items.

I will suggest making all doors, windows, etc items children of an empty parent 
item. All transformations applied to the parent will be propagated to the 
children,
but you will still be able to use the same coordinates to draw items themselfs, 
these will not be changed, they are relative to the parent, not the scene or the 
view.
In your init func, you draw aways on the same spot relative to the .jpg, then 
let the parent handle scaling and translating all items as a whole, relative to 
the scene or view.
If you need to know when to modify this parent item based on scene/view 
variables you can monitor itemChange, ItemSceneChanged. When received the item 
is on stage and the view and scene are with the actual values.

MihailNaydenov


>
>From: Brian McKinnon <bpmckinnon.qt at gmail.com>
>To: qt-interest <qt-interest at trolltech.com>
>Sent: Fri, December 10, 2010 3:57:41 PM
>Subject: Re: [Qt-interest] showEvent in QGraphicsView - question about when to 
>draw
>
>Method number 2 is definitely the right way to do it.  It terms of the drawing 
>position as it rescales there shouldn't be a problem as long as you enable 
>antialiasing on the graphicsview you should be fine.  The text may become an 
>issue, so you may want to store a list of text objects in your scene and scale 
>the text sizes as your view changes.  Although there may be a more efficient way 
>of doing that... like storing a text sting in your graphicsitems and have the 
>views paintevent scan through the items in the scene and draw the requested text 
>on the view during the paintevent.  I think that may end up making your text 
>much less scale dependent.  But I'm just spitballing here.
>
>
>2010/12/10 franki <franki at franki.eu.org>
>
>Thursday 09 of December 2010 19:54:37 Mihail Naydenov napisał(a):
>>
>>> It is hard for me to track you thoughts. What exactly are you trying to do.
>>> "During initialization of my class", what class?
>>> Why not draw on paint()? All will be initialized then.
>>
>>Hello,
>>
>>Maybe I start with explaining something about my app.
>>Application is based on QStackedWidget, and almost every page has
>>QGrapvicsView stretched onto pages. Views are displaying plan of some
>>building, each floor and so on. Plan itself is a jpg image with walls, doors,
>>etc. Onto this plan I draw items like: windows, doors, radiators (for central
>>heating) and so one. Some of this items are animated, eg. when You open the
>>window, signal is sent to app through rs232 and window is opening itself.
>>Anyway, it's crucial for me to draw these items exacly at specific points.
>>The problem is: I run this application on 18" widescreen panel or on laptop,
>>with different sizes and resolutions, so I can't set size of QGraphicsView to
>>be constant (eg. in Qt Designer). The plan (I mean jpg image) is also scaled
>>to fitt in the view. QGraphicsScene must be as big as QGraphicsView, without
>>scrollbars. Because of this, sometimes I need to draw let's say window item
>>at point 200px,250px and sometime at 300px,350px depending on the size of the
>>screen.
>>So I can think of two solutions of this problem.
>>1. I start drawing all items after I get signal from sublcassed QGraphicsView
>>on showEvent, then I know size, I set scene to be almost size of
>>QGraphicsView, and start drawing. However, now when I think about this it's
>>still mess, because I would need to calculate where to paint items.
>>2. Second idea is to set scene before showEvent, little bigger than jpg with
>>floor plan (without scaling it), place the jpg in the center of the scene,
>>then draw items in their positions (which would be constant and always known
>>because I know size of this jpg) and then on showEvent I should call
>>fittInView with QRect set at the size of the previously created scene. I
>>assume that every item, and background jpg, will be rescaled to fitt in view
>>without scrollbars, but again I may be wrong, because this is really my first
>>app, so I simply don't know, until I try. Moreover I was affraid that
>>rescaling will make some of items little bit off their positions or for
>>example fonts will not look nice after that.
>>
>>You said: "Why not draw on paint()" - You meant paint... what? paintEvent or
>>something else? I honestly don't know what you meant by that.
>>Please someone advise me.
>>
>>best regards
>>Marek
>>
>>
>>>
>>>
>>> ----- Original Message ----
>>>
>>> > From: franki <franki at franki.eu.org>
>>> > To: qt-interest <qt-interest at trolltech.com>
>>> > Sent: Thu, December 9, 2010 6:08:45 PM
>>> > Subject: [Qt-interest] showEvent in QGraphicsView - question about when
>>> > to
>>>
>>> draw
>>>
>>> > Hello,
>>> >
>>> > I had a problem determinig size of QGraphicsScene, and from what I  had
>>> > read so
>>> >
>>> > far, size of QGraphicsView should be determined in showEvent  because
>>> > before this event happend geometry has some bogus data.
>>> > So I did  it that way, but show event is comming late, far after class
>>> > itself had been  initialized. During initialization of my class, I used
>>> > to draw an items  inside scene, but now when showEvent is comming late
>>> > what should I do? eg.  Send a signal from inside subclassed
>>> > QGraphicsView, which triger some function in base class to start drawing
>>> > items?
>>> > Is that a right way, or  are there some other options?
>>> >
>>> > best  regards
>>> > Marek
>>> > _______________________________________________
>>> > Qt-interest  mailing list
>>> > Qt-interest at trolltech.com
>>> > http://lists.trolltech.com/mailman/listinfo/qt-interest
>>
>>
>>
>>_______________________________________________
>>Qt-interest mailing list
>>Qt-interest at trolltech.com
>>http://lists.trolltech.com/mailman/listinfo/qt-interest
>>
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20101211/98a58572/attachment.html