| 1 |
|
|---|
| 2 |
Elements |
|---|
| 3 |
-------- |
|---|
| 4 |
Element on the Gaphor canvas can be easely be inherited from DiaCanvasElement. |
|---|
| 5 |
This gives them the oportunity to connect relationships etc. Elements typically |
|---|
| 6 |
have some sort of text inside. This can be handled by DiaCanvasText. The |
|---|
| 7 |
Gaphor element only has to glue these objects together (which is pretty |
|---|
| 8 |
straight forward now that all is abstracted by iterators). |
|---|
| 9 |
|
|---|
| 10 |
Another point is Undo information. We have to find some way to commit undo |
|---|
| 11 |
indormation and undo it. Typically, GObjects have a get/set_property() |
|---|
| 12 |
function which handles this. We can use this for properties defined in the |
|---|
| 13 |
parent, but not for out own properties. For elements, however, this should |
|---|
| 14 |
not be nessesary. |
|---|
| 15 |
NOTE: properties can be set by a __gproperty__ attribute in the class. |
|---|
| 16 |
|
|---|
| 17 |
Undoing and redoing data has some feetback on the data model. If an element |
|---|
| 18 |
is removed from the diagram, it increments a undo-counter on the data object, |
|---|
| 19 |
knowing that the data object could be unlinked, but should not be removed |
|---|
| 20 |
entirely. I (Arjan) have to investigate if this is a desired solution at all, |
|---|
| 21 |
and if so, if how diagram item subjects (the model elements) should behave |
|---|
| 22 |
onder those circumstances. |
|---|
| 23 |
|
|---|
| 24 |
Connecting and disconnecting is also done by DiaCanvasElement. Gaphor elements |
|---|
| 25 |
should only allow specific types of elements to connect. |
|---|
| 26 |
|
|---|
| 27 |
Relationships |
|---|
| 28 |
------------- |
|---|
| 29 |
Relationships can also have text subtypes. This text, however should be able |
|---|
| 30 |
to move. connecting and disconnect should be pretty easy to convert to Python |
|---|
| 31 |
code since most calls are already Python calls. Constraints should be made |
|---|
| 32 |
to keep the text close to the line. |
|---|
| 33 |
|
|---|
| 34 |
Connection protocol |
|---|
| 35 |
------------------- |
|---|
| 36 |
When a relationship is to be connected to a model element, the relationship |
|---|
| 37 |
should have an option to check if a connection is valid. After a connection |
|---|
| 38 |
is established, the line should be notified so it can update its internal |
|---|
| 39 |
state and the data model. |
|---|
| 40 |
|
|---|
| 41 |
1. The user drags a handle of a relationship to a model element |
|---|
| 42 |
2. If the user releases the handle a connect_handle signal is emited. |
|---|
| 43 |
3. The connect_handle asks the relationship if the connection is allowed by |
|---|
| 44 |
calling allow_connect_handle(). |
|---|
| 45 |
4. If the connection is allowed, the element tries to connect the relationship |
|---|
| 46 |
5. The relationship is notified by calling confirm_connect_handle() |
|---|
| 47 |
|
|---|
| 48 |
For disconnecting lines, an identical procedure is used |
|---|
| 49 |
(allow_disconnect_handle() and confirm_disconnect_handle()) |
|---|
| 50 |
|
|---|
| 51 |
Conclusion |
|---|
| 52 |
---------- |
|---|
| 53 |
This should work ;-)... |
|---|
| 54 |
|
|---|
