moving more than 2 floating topics cause them to pile in a stack (loss spatial coodination)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. move more than 2 floating topics casue them to pile up in the new location
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by lu.shan...@gmail.com on 15 Feb 2010 at 7:47

[GoogleCodeExporter]

i also have this problem:

Version: 3.1.1
OS:      Windows 7 Home Premium (64 bit)

// repro
-- in the xmind application --
1. <create> 'New' workbook (Ctrl+Shift+N)
2. <create> a 'Floating Topic' (double click work area)
3. <create> 2nd 'Floating Topic' [next to first topic] (double click work area)
4. <select> both 'Floating Topics' (drag selection rect over both topics)
5. <move> 'Floating Topics' to another location in the work area (drag & drop)
-- take care to not place the topic nodes close enough to the 'Central Topic' 
that they become 'Subtopics' of it --

expected: (how it worked in verson: 3.0.2)
the 'Floating Topics' maintain their positions relative to each other [still 
next to each other]

actual: (output in version: 3.1.1)
-- if 'Allow Overlaps' [in 'Modify' menu] is active --
the 'Floating Topics' are now overlapped [sharing the same x:y position] 

-- if 'Allow Overlaps' is not active --
the 'Floating Topics' are now stacked vertically [aligned to each other]

let me know if you require further information

Original comment by peabu...@gmail.com on 16 Jul 2010 at 2:25

[GoogleCodeExporter]

update for xmind portable 3.2.0 on 64 bit Windows 7

to reproduce:
<same as above - direct quote>
-- in the xmind application --
1. <create> 'New' workbook (Ctrl+Shift+N)
2. <create> a 'Floating Topic' (double click work area)
3. <create> 2nd 'Floating Topic' [next to first topic] (double click work area)
4. <select> both 'Floating Topics' (drag selection rect over both topics)
5. <move> 'Floating Topics' to another location in the work area (drag & drop)
-- take care to not place the topic nodes close enough to the 'Central Topic' 
that they become 'Subtopics' of it --

expected: (how it worked in verson: 3.0.2)
the 'Floating Topics' maintain their positions relative to each other [still 
next to each other]

actual: (output in version: 3.1.1)
-- if 'Allow Overlaps' [in 'Modify' menu] is active --
the 'Floating Topics' are now overlapped [sharing the same x:y position] 

-- if 'Allow Overlaps' is not active --
the 'Floating Topics' are now stacked vertically [aligned to each other]
<end direct quote>

i have some fairly large maps and sometimes need to move in excess of a hundred 
topics at a time (where the precision of relative position is essential) .. 
what took a few minutes in older versions (and most of that was selecting all 
of the nodes) now can take up to an hour (sometimes more)

due to this .. i am compelled to stay on an older version of xmind which has 
memory leaks and instabilities .. which i am to understand have been fixed in 
more recent versions of the software

Original comment by xay...@gmail.com on 7 Oct 2010 at 6:06

[GoogleCodeExporter]

tks!

Original comment by stephen0...@gmail.com on 23 Dec 2010 at 9:49

• Changed state: Accepted

[GoogleCodeExporter]

further information:
<preface> please note: i am not a java developer nor am i familiar with the 
inner workings of the XMind codebase .. the information in this report is a 
mixture of forensic debugging, educated guesses and personal opinion:

1. if you are a user of XMind, don't assume the comments below indicate that an 
easy fix exists

2. if you are a developer of the XMind software, i understand how difficult 
software development can be .. i am offering this information with the hopes of 
being helpful .. i apologize if any of it is counter productive to your 
development cycle </preface>

what appears to be happening:
when a node is moved, the code determines if that node is a child node .. if it 
is the code attempts to move the node based on the distance and direction the 
mouse has traveled (relative positioning) .. if the node has no parent (is not 
a child node) it moves the node directly to the location of mouse (absolute 
positioning).

this results in behavior that is inconsistent from earlier versions of the 
software:
1. any floating node (when dropped) automatically centers on the mouse's 
location
2. any group of floating nodes (when dropped) lose relative spatial positioning

this makes it difficult to create maps where specific relative positioning of 
nodes is a required element of presentation.

. . .
some example scenarios: 

-- a single node moved by relative positioning --
1. the mouse is positioned over a topic node
2. the primary mouse button is <pressed>
3. the mouse is <moved> 30 pixels to the right
4. the primary mouse button is <released>

result: the node is moved 30 pixels to the right

-- a single node is moved by absolute positioning --
1. the mouse is positioned over a topic node
2. the primary mouse button is <pressed>
3. the mouse is <moved> to the coordinates (x=70, y=22)
4. the primary mouse button is <released>

result: the node is centered on the coordinates (x=70, y=22)

-- multiple nodes are moved by relative positioning --
1. multiple nodes are selected (via ctrl clicking or the selection rectangle)
2. the mouse is positioned over any of the selected nodes
3. the primary mouse button is <pressed>
4. the mouse is <moved> 30 pixels to the right
5. the primary mouse button is <released>

result: all selected nodes are moved 30 pixels to the right

-- multiple nodes are moved by absolute positioning --
1. multiple nodes are selected (via ctrl clicking or the selection rectangle)
2. the mouse is positioned over any of the selected nodes
3. the primary mouse button is <pressed>
4. the mouse is <moved> to the coordinates (x=70, y=22)
5. the primary mouse button is <released>

result: all selected nodes are centered on the coordinates (x=70, y=22)
-- if 'Allow Overlaps' is not active --
the nodes are then arranged to not be overlapping

//--- --- - - -

some relevant code:
[in the package: org.xmind.ui.internal.tools]
[in the file: TopicMoveTool.java]
[in the method: createRequest()]
...
boolean relative = isRelative();
Point position = relative ? getRelativePosition(): getAbsolutePosition();
...
request.setParameter(GEF.PARAM_POSITION_RELATIVE, Boolean.valueOf(relative));
...

//---

in older versions of the code, all node movement requests created by this 
method used relative position .. somewhere around 3.1.0 this new code was added 
.. it appears that the added code was a workaround for a bug also introduced in 
3.1.0 where 'Main Topic' nodes would lose positional information when they were 
detached from the 'Central Topic' (by moving them a sufficient distance from 
the 'Central Topic' or by holding down the shift key)

i'm going to guess that more systems are involved, but i am not familiar enough 
with the code to know

//--- --- - - -
some thoughts:
a lot of the problem might be addressed by having the move request track the 
positional offset between the node(s) being moved and the mouse's location .. 
that way if nodes are placed by absolute coordinates .. their resulting 
position can be 'corrected' by having the same relative position to the mouse 
as they did when they were 'picked up'

but the more pragmatic part of my brain thinks that the solution outlined above 
(while valid) would simply be covering for a more systemic edge condition .. 
however, i do not know the codebase well enough to speculate as to what that 
might be

Original comment by xay...@gmail.com on 24 Sep 2011 at 10:44

[GoogleCodeExporter]

Any update on this?

Original comment by jeremy.cowles on 18 Dec 2011 at 4:31