[Uml-devel] Question on AssociationWidget::loadFromXMI() - why unset old-first position of linepath

[Achim Spangler]

Am Dienstag, 27. April 2004 22:47 schrieben Sie:
> On Tuesday, April 27, 2004 4:53 PM, Jonathan Riddell wrote:
> I agree.
> A major overhaul of FloatingText has been on the back of my mind
> for a long while... still haven't got around to it.
>
> > If you supply a patch and show an example of it makeing a difference
> > then we'll commit it, probably once Oliver's looked at it since he's
> > been working on that code more recently.
>
> Certainly. A patch would be great - any other help appreciated as well.
I created a patch, which block the call of the following functions as long as 
the XMI file is loaded:
+ AssociationWidget::moveEvent()
+ AssociationWidget::widgetMoved()
+ UMLWidget::adjustAssocs()

IMHO these functions are only applicable for the normal editing state. But as 
not all elements and their positions are known during load of XMI, an 
automatic calculating of new positions can lead to wrong results - especially 
if the old position from XMI file are probably the really wanted result by 
the user.

The adjustAssocs function is called from several SET functions, which are 
called during load for initial creation and positioning. So we could either 
inhibit the call of this function at all places or simply block the execution 
of this function as presented in my patch.

The other two event handling functions are triggered by events, which I don't 
know. All I can derive is the fact, that their execution is at best useless 
during load of a XMI file, where the original positioning should be simply 
reproduced.

I'm not shure if I found all sources for unwanted move of widgets during load. 
But at least I detected and fixed some sources of them.

Bye,
Achim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BlockMoveDuringLoad.diff.gz
Type: application/x-gzip
Size: 1013 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/umbrello-devel/attachments/20040430/54952e1e/attachment.gz>