Issue 123412 - GluePoint EscapeDirections get lost at save/reload
Summary: GluePoint EscapeDirections get lost at save/reload
Status: CLOSED DUPLICATE of issue 114567
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: 4.0.1
Hardware: All All
: P3 Normal (vote)
Target Milestone: ---
Assignee: Armin Le Grand
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-02 14:37 UTC by Armin Le Grand
Modified: 2017-05-20 10:06 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Armin Le Grand 2013-10-02 14:37:46 UTC
ALG: GluePoints have EscapeDirections; these are editable in the UI and are or-ed together from left/right/top/bottom to define all allowed escape directions for a connector using the gluepoint. This gets lost when:

- new draw
- add rectangle
- activate gluepoint mode (ckick on the 'tube' icon in the drawing toolbar, the gluepoint toolbar appears)
- add new gluepoint
- select 'exit direction left' and 'exit direction top'
- save
- reload
- select object
- activate gluepoint mode
- select GluePoint
-> exit direction left' and 'exit direction top' are lost

This happens because there is a basic msiunderstanding error in the UNO API for this; the com::sun::star::drawing::EscapeDirection only supports single directions, not a combination of those, except 'HORIZONTAL' and 'VERTICAL'. As a result this is also handled wrong in ODF im/export.

This means:
- the com::sun::star::drawing::EscapeDirection definition has to be changed
- its usage in com::sun::star::drawing::GluePoint2 has to be adapted
- the UNO API implementation has to be adapted
- the ODF im/export has to be adapted

Since the 1st two points mean an incompatible UNO API change, probably EscapeDirection2 and GluePoint3 definitions would be needed. Since the exchange of these data is using a type-free container::XIndexContainer and container::XIdentifierContainer API it is not clear how this can be done compatible at all.

If someone knows, please add advice to this task.
Comment 1 Armin Le Grand 2013-10-02 14:38:09 UTC
ALG: Grepping to keep an eye on it.
Comment 2 Regina Henschel 2013-10-02 16:38:29 UTC
Hi Armin, I think, that the error is in the UI. The escape directions cannot be combined in ODF1.2. There exist: auto, up, right, down, left, horizontal, vertical. 'horizontal' has the meaning of 'left or right', and 'vertical' has the meaning of 'up or down'.
Therefore a combination 'up or left' cannot be written to ODF1.2. Indeed in such cases no draw:escape-direction is written at all.

That was already the same way in .sxd format.

So the API is correct. But the UI has to be changed, so that it only allows settings, which can be stored. For example handle it the same as alignment. One icon for "auto" ("smart" in API). If it is set, then the others are disabled. And six buttons for the others, where only exact one can be set.

The ODF attribute has strings as values. Allowing to combine them would result in a very long list of valid strings or a change of the value type to a string list or to a bit field. That would require a suggestion to the TC.

Exist user requests for such combining of escape directions?

Is this feature needed for import of Microsoft formats?

[SVG connector does not yet exist, but is still an early draft.]
Comment 3 Armin Le Grand 2013-10-08 16:15:40 UTC
ALG: Hi Regina, unfortunately it's not an error in the UI. The core and UI exist much longer than the API and ODF, thus I guess the person doing the API and ODF for it just did not know what the core can do here.
Of course you are right that it is also possible to fix the UI, but why should we limit us to hor/ver and four directions? There are useful cases, e.g. a user-defined gluepoint near the upper left corner of a shape, there you want connectors to go left or up, nothing else.
A fix is not urgent, there is no real request (noone complained so far). I just stumbled over it and wanted to have a reminder, hence the task.
If you want a suggestion to the TC should look like other values where or-ed values make sense. Interestingly this is the case in Gluepoint but not in Gluepoint2 in the UNO API. This may be a hint that someone did this even by purpose because MS formats do only use these limited values? I have no idea yet, I tried to find in various PPT versions a possibbility to edit gluepoints at all, but could not find it anywhere. If you know better, please feel free to add infos here.
Thus: No panic, just a reminder...
Comment 4 Regina Henschel 2013-10-13 21:25:12 UTC
Please look at bug 114567. That is the issue about changing ODF. Adding a dependence?
Comment 5 Armin Le Grand 2013-10-14 08:34:04 UTC
ALG: Aha, exists. Setting to duplicate.

*** This issue has been marked as a duplicate of issue 114567 ***