Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Voting: Accidental Layout of Views

My vote is -1 (for the solution to the first problem, the rest I would vote
+1 to)

See my SA> Comments below

Simon :-)

                    Sent by:                       To:     platform-ui-dev@xxxxxxxxxxx                      
                    platform-ui-dev-admin@e        cc:                                                      
                               Subject:     [platform-ui-dev] Voting: Accidental Layout 
                                                   of Views                                                 
                    12/11/2001 03:27 PM                                                                     
                    Please respond to                                                                       

Accidental Layout of Views

The Loss of Context Proposal has been split up so we can move forward on
individual issues.  This section concerns the Accidental Layout issues
(Problem #8).  We would like to vote on the direction of this proposal.  If
agreement can be reached, we will progress with the implementation and
address PR's as they come up.

In Eclipse, the size and position of a view may be changed by grabbing the
view title with the mouse, and dragging.  This feature  has led to a number
of problems.

# If you click on the title bar of a view, and then move your mouse to
access the main toolbar or menubar, sometimes you don't release the mouse
button fast enough.  In this situation a d&d is started and a detached
window is created.  The detached window looks a lot like a view within a
folder, so you may not notice it until much later, after you do some other
actions, and the floating window manifests itself.
# If you click on a view and then drag it, there is no obvious way to
cancel the drag just by putting the view back where it came from.  This
creates a floating window, which you have to redrag to regain the original
layout.  This also occurs with view folders.
#If you click on the side of a view, to resize it, it may be interpreted as
a drag instead, because there is some overlap in the drag area.

We can resolve the first issue by changing the sensitivity of the drag, so
that there is a greater time period (num of pixels) before dragging begins.
To resolve the second, it should be possible to drop the view back in the
original position.  To resolve issue 3, we have removed the ability to drag
a view using the thin left and right borders of a view, where there may be
conflict with the resize bars.  A user may also use the Reset Perspective

SA> I guess the more I think about this, the less I'm convinced that
changing the sensitivity of the drag will solve problem 1. It will reduce
the number of times it happens, but does not solve it. Also, it will cause
other problems for people to start a d&d operation. For example, on the
Windows platform, there is a setting for number of pixel to move the mouse
before d&d starts (to move windows around). If we ignore that setting and
use one that is too big, then starting d&d becomes sluggish causing another
problem (user clicks and moves mouse but d&d does not start as expected and
lets go of the button, but just as the d&d started, now there is a detach

SA> Suggestion: what we need to do is allow a view to become
detached/floating if and only if it is drag outside the main window
(whether we say it is just the cursor outside or the entire view outside
can be determined by usuability tests...). D&D over the window's title bar,
toolbar, menubar, status bar, and scroll bar is not allowed. That way you
do not interfere with normal d&d sensitivity setting, and you've solved the
problem of click and move quickly without letting go of the button fast

It is not appropriate to implement an Undo Layout action, or a Lock /
Unlock command.


     +1 = You are in favour of this proposal & agree with further
exploration to determine API/contribution changes.
     0 = Abstain
     -1 = You are opposed to this proposal. When voting -1 you must also
provide a detailed explanation of your

Voting ends 1 week from date proposal is submitted to the mailing list.

platform-ui-dev mailing list

Back to the top