[Ktechlab-devel] Some UML-like diagrams

[P Zoltan]

On Sun, 27 Dec 2009 23:52:09 +0100, Axel Jäger <axel.jaeger at basyskom.de>  
wrote:

>> We could inherit ForLoopItem from QWidget (or more specifically from  
>> some frame), then embed it into the scene with the addWidget method (
>> http://doc.trolltech.com/4.5/qgraphicsscene.html#addWidget
>> ), and insert in the frame a new graphics scene. The details of this  
>> should be worked out.
>>
> No, please do not embed QWidgets in a QGraphicsScene. This is just a  
> migration thing to be able to mix old widget based code with new  
> QGraphicsItem-based code. For new things that should live in a  
> QGraphicsScene, subclass either QGraphicsItem or QGraphicsWidget if you  
> want something like a widget.
>
> Embedding classic QWidgets in a GraphicsScene suffers from performance  
> problems and funny effects because there is now 2 trees: The object and  
> the item tree and they fight against each other.
>

  I didn't know that. Sill, there is a warning on QGraphicsProxyWidget's  
documentation page. Time for a new approach...

  Basically we need 2 types of widgets on the graphic scene: buttons and  
scroll bars. So I guess we should implement those manually, or wait for  
the official QT version of them
( reference: http://labs.trolltech.com/blogs/2009/12/10/we-have-liftoff/ ).

> Feel free to ask me any questions about that topic.

  Whay kind of implementation would you recommend for loops in flowcode  
document? These contain more flow-items inside.

  In the 0.3 version of ktechlab, the loops are simple items on the canvas  
(?), with a "hole" in their middle; they just surround the items they  
contain. This can lead to strange behavior when some items are only  
partially inside the the loop.
  For the new version I want to make them real containers; this should make  
the code more simple, reliable and user-proof. Embedding one graphic scene  
into another looks a very elegant solution to me. The big question is how  
to do it.


>
> Axel
>
>
>
>
>> Another issue to be discussed is how should we split the source code;  
>> what kind of plugins do we want to create. Should there be a dependency  
>> between plugins?
>>
>>
>>
>> bye then
>> julian
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and  
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Ktechlab-devel mailing list
>> Ktechlab-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and  
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev  
>> _______________________________________________
>> Ktechlab-devel mailing list
>> Ktechlab-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>