Diagram widgets show inconsistent z ordering (tested with class widgets): 1. A newly added class widget is on top of all previously added widgets 2. if a class widget is overlapped or overlaps any other class widgets, selecting place it on top of the overlapping widgets 3. if a class widget is not overlapped or do not overlap any other class widgets, selecting place it sometimes below all other widgets, sometimes somewhere in the middle and sometimes on top. Reproducible: Always Steps to Reproduce: 1. open umbrello 2. add four classes to the default diagram without overlapping 3. move widgets around 4. select the first added widget and move it over other widgets (it will be shown in the background) 5. move the first added widget overlapping with others and deselect/select again Actual Results: z order of the related widget has been changed Expected Results: z order should not be changed The question is, what kind of z ordering would be useful to implement ?
(In reply to Ralf Habacker from comment #0) > Diagram widgets show inconsistent z ordering (tested with class widgets): > 1. A newly added class widget is on top of all previously added widgets > 2. if a class widget is overlapped or overlaps any other class widgets, > selecting place it on top of the overlapping widgets > 3. if a class widget is not overlapped or do not overlap any other class > widgets, selecting place it sometimes below all other widgets, sometimes > somewhere in the middle and sometimes on top. > > Reproducible: Always > > Steps to Reproduce: > 1. open umbrello > 2. add four classes to the default diagram without overlapping > 3. move widgets around > 4. select the first added widget and move it over other widgets (it will be > shown in the background) > 5. move the first added widget overlapping with others and deselect/select > again > > Actual Results: > z order of the related widget has been changed > > Expected Results: > z order should not be changed > > The question is, what kind of z ordering would be useful to implement ? I'd like to discuss that. Do we consider adding a parent child relation too (that you told me to be missing in bug 53369)?
I also noticed this. What if you solve this by adding a right click menu item for each class "bring to front"? This will bring the class on top for all classes that surround it. So the user decides how they are drawn.
I can confirm the inconsistent z ordering of widgets also for use case diagrams in version 2.39.2