[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Meeting decisions
From:       Thomas Zander <zander () kde ! org>
Date:       2007-10-28 10:34:26
Message-ID: 200710281134.26877.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 28 October 2007 11:00:27 Thorsten Zachmann wrote:
> Hello,
>
> On Saturday 27 October 2007, Thomas Zander wrote:
> > I think avoiding the mixing of concepts that are in principle very
> > different will actually make sure the end effect is more
> > understandable code.
>
> we don't see any difference in the concepts:
>
> - a connection is an object on screen that can be manipulated
In other words, it paints itself. Agreed.

> - a connection should be able to be dragged to a different position

While the general idea is 'similar' a connection has a lot of constraints.
I can't be rotated, it can't be sheared/scaled.
It is also auto-moved when either of the shapes it may be connected to is 
moved.  (and thus it doesn't really have a position).
Lots of exceptions to the generic code.

> - a connection has to be added to the document

Most connections you actually will not add to the document. Since adding 
it to a shape is enough. Only a connection that is connected to nothing 
has to somehow be stored.
Also big difference is that since a connection is added to one or two 
shapes and you make a connection a shape as well, what stops anyone from 
adding a connection to a connection?
ODF doesn't allow that, for starters. (you are suppost to make one 
multi-node connection for that)
I bet you have to add some exceptions to the generic code there.

> - a connection should be able to be animated in kpresenter

But it will still have the constraints of being connected to a shape, and 
thus you have a lot less freedoms in movement of animation.
I bet that your code to do the animation will work just fine if they 
assume the connections are the same, but then you have to add all those 
exceptions to that same code to actually treat connections different due 
to the constraints they have.

> - a connection needs to be able to be deleted

This is not the same as in a shape;  a connection is severed, meaning you 
have to tell each shape it is connected to. Also, a connection is stored 
in a shape so you don't have to tell the document about it.
Another couple of exceptions.

> - a connection should be shown in the object tree view

And should it be shown in the same manner as a shape? Remember, a 
connection gets bigger if a shape is moved. So your 'preview' and 
updating mechanism is surely different.
Also I think the placing of a connection between shapes in a tree of those 
same shapes will not be a good thing for visualizing it.
How would you visualize that there is a connection between a two nodes 
that are in completely different parts of the hierarchy? Or in different 
layers?

> That all is common to a KOShape.
>
> We all get this for free if a connection is a shape. So this does
> create less code duplication and make the code actually easier to
> understand.

Again, I suggest you actually try to code it and make sure you get all the 
exceptions (differences) in line.  I'm pretty sure that the resulting 
code will not be more easy to understand.
All you need to understand right now is that connections are different and 
have some different code to do things like selection and moving.  In your 
model you need to know *all* the exceptions while hacking on the shared 
code to keep them from having regressions.

> We will try to get a basic connections shape up and running and see if
> it works out.

Great!
Let me know how the code handles all the small differences. Since the fine 
tuning and making all the differences between the two concepts is the 
bugger.  So a simple "proof of concept" that doesn't address those 
differences is not a good indicator for the end result :)

-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]