Open GoogleCodeExporter opened 9 years ago
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
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
tks!
Original comment by stephen0...@gmail.com
on 23 Dec 2010 at 9:49
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
Any update on this?
Original comment by jeremy.cowles
on 18 Dec 2011 at 4:31
Original issue reported on code.google.com by
lu.shan...@gmail.com
on 15 Feb 2010 at 7:47