Bug 57884 - Click on an object, selects object beneath it, and brings it to top
Summary: Click on an object, selects object beneath it, and brings it to top
Status: RESOLVED INTENTIONAL
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: 1.1.1
Platform: unspecified Linux
: LO normal
Target Milestone: ---
Assignee: Umbrello Development Group
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-30 09:42 UTC by Stevan White
Modified: 2004-07-14 01:11 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stevan White 2003-04-30 09:42:56 UTC
Version:           1.1.1 (using KDE KDE 3.1.1)
Compiler:          Sun Java2 SDK 1.4.1 
OS:          Linux

Make 2 classes

Drag one so it partly covers the other.

Click on the region where the two objects overlap.

The object on bottom will pop to the top.

This is upside down from most GUI's.  Normally, you get the item that is top in the visual heirarchy.
Comment 1 Sebastian Stein 2003-10-04 23:09:04 UTC
*** Bug 57878 has been marked as a duplicate of this bug. ***
Comment 2 Stevan White 2004-06-13 14:19:51 UTC
Still exists in 1.2.1
Comment 3 Jonathan Riddell 2004-06-15 01:46:12 UTC
I can't confirm this, the behaviour of overlapping object works for me, the top one is always the selected object.
Comment 4 Stevan White 2004-06-18 20:26:38 UTC
It depends on which class is on top of which.

Create a class, name it 'A'.
Create another class, name it 'B'.
Drag the object for 'A' so that it overlaps the one for 'B'.
Now click on the region of 'A' where it overlaps 'B'.

'B' will incorrectly be selected.

If you drag object 'B' over object 'A' and do the analogous thing, you will not see this behaviour.
Comment 5 Jonathan Riddell 2004-07-05 16:22:14 UTC
So it does.  Confirmed.
Comment 6 Sebastian Stein 2004-07-12 12:41:01 UTC
Stevan White <stevan_white@hotmail.com> [040618 22:11]:
> It depends on which class is on top of which.
> 
> Create a class, name it 'A'.
> Create another class, name it 'B'.
> Drag the object for 'A' so that it overlaps the one for 'B'.
> Now click on the region of 'A' where it overlaps 'B'.
> 
> 'B' will incorrectly be selected.
> 
> If you drag object 'B' over object 'A' and do the analogous thing, you
> will not see this behaviour.

It depends which class was added last. This class will be selected. Umbrello
doesn't store any Z-axis information at all. During painting it doesn't look
at overlapping. It just paints a class and it may be that the next class
draws over this class.

I don't see any way to fix this bug. Of course we can add Z-axis information
to the widgets, but that would mean a major effort. And I think the gain is
really minor.

So I like to ask to close this bug with resolution "Won't fix".

Sebastian

Comment 7 Sebastian Stein 2004-07-13 08:56:00 UTC
I resend this message, because it doesn't arrived at uml-devel...


Stevan White <stevan_white@hotmail.com> [040618 22:11]:
> It depends on which class is on top of which.
> 
> Create a class, name it 'A'.
> Create another class, name it 'B'.
> Drag the object for 'A' so that it overlaps the one for 'B'.
> Now click on the region of 'A' where it overlaps 'B'.
> 
> 'B' will incorrectly be selected.
> 
> If you drag object 'B' over object 'A' and do the analogous thing, you
> will not see this behaviour.

It depends which class was added last. This class will be selected. Umbrello
doesn't store any Z-axis information at all. During painting it doesn't look
at overlapping. It just paints a class and it may be that the next class
draws over this class.

I don't see any way to fix this bug. Of course we can add Z-axis information
to the widgets, but that would mean a major effort. And I think the gain is
really minor.

So I like to ask to close this bug with resolution "Won't fix".

Sebastian

Comment 8 Jonathan Riddell 2004-07-14 01:11:42 UTC
> So I like to ask to close this bug with resolution "Won't fix". 

Agreed, I think that's the first time we've used "won't fix" but I think it's the correct thing to do in this case.

Thanks for your feedback Stevan.