Bug 124453 - Multiple levels of plot groups are destroyed shortly after creation
Summary: Multiple levels of plot groups are destroyed shortly after creation
Status: RESOLVED FIXED
Alias: None
Product: kst
Classification: Applications
Component: general (show other bugs)
Version: 1.x
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-28 23:01 UTC by Andrew Walker
Modified: 2006-04-06 06:18 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Walker 2006-03-28 23:01:53 UTC
Version:           HEAD (using KDE KDE 3.5.0)
Installed from:    Compiled From Sources
OS:                Linux

PROBLEM:
If the user tries to create plot groups made of other plot groups then the lower level plot groups are automatically destroyed

STEPS TO REPRODUCE:
Start Kst
In the default window create 3 rectangle objects
Enter layout mode
Select 2 of the rectangle objects
Group them
Select the newly created group and the third rectangle
Group them
Try to the newly created group

RESULTS:
The newly created plot group is destroyed

EXPECTED RESULTS:
The newly created plot group continues to exist
Comment 1 Andrew Walker 2006-03-28 23:18:40 UTC
This problem seems to be caused by the following lines of code in KstToplevelView::releasePressLayoutModeMove(...)

if (container != _pressTarget && !container->children().contains(_pressTarget)) {
  _pressTarget->detach();
  container->appendChild(_pressTarget);
}

which implicitly moves objects from a deeper group up to a higher level. This appears related to the automated parenting of objects following a move, but in this case no move was made.

One solution would be to disable a move operation for objects within a plot group. Only the group could be moved as a whole. However, we might still want to be able to edit an object within a plot group.
Comment 2 George Staikos 2006-03-31 02:45:02 UTC
  I don't think that's the case.  I think we're getting the wrong target to 
begin with.  It's because of a change I made to plotgroups to fix some other 
problems.  I didn't notice the impact here.  I'm testing a patch now.
Comment 3 George Staikos 2006-04-06 06:18:43 UTC
SVN commit 526966 by staikos:

don't break plot groups apart.  There are still many problems lurking though.
BUG: 124453


 M  +6 -4      ksttoplevelview.cpp  


--- trunk/extragear/graphics/kst/src/libkstapp/ksttoplevelview.cpp #526965:526966
@@ -330,11 +330,13 @@
   _pressTarget = findDeepestChild(pos, false);
   if (_pressTarget) {
     KstViewObjectPtr p = _pressTarget;
-    while (p->_parent && p->_parent->_container) {
+    while (p->_parent && (p->_parent->_container || kst_cast<KstPlotGroup>((KstViewObjectPtr)p->_parent)) && !kst_cast<KstTopLevelView>((KstViewObjectPtr)p->_parent)) {
       p = p->_parent;
     }
-    if (p->_parent && !p->_parent->_container) {
+    if (p->_parent && !p->_parent->_container && !kst_cast<KstTopLevelView>((KstViewObjectPtr)p->_parent)) {
       _pressTarget = p->_parent;
+    } else if (p && !p->_container) {
+      _pressTarget = p;
     }
   }
 
@@ -957,10 +959,10 @@
       obj = obj.unite((*i)->geometry());
     } 
   }
-  const QPoint objOffset(_pressTarget->geometry().topLeft() - obj.topLeft());
+  const QPoint objOffset(old.topLeft() - obj.topLeft());
 
   // do the move
-  obj.moveTopLeft(pos - _moveOffset - _moveOffsetSticky - _pressTarget->geometry().topLeft() + obj.topLeft());
+  obj.moveTopLeft(pos - _moveOffset - _moveOffsetSticky - old.topLeft() + obj.topLeft());
   if (!_geom.contains(obj, true)) {
     slideInto(_geom, obj);
   }