Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Right click behavior (bug #19825) and proposal


My only comment on this is that, I believe adding preferences is usually an engineering solution to a design-level problem (sometimes it really is better to just do one, simple, well-thought out thing, and thus be predictable). They also make the code larger, harder to read, and (typically) slower.

McQ.



Ron Baldwin <ron.baldwin@xxxxxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx

02/03/03 05:47 AM
Please respond to platform-swt-dev

       
        To:        "'platform-text-dev@xxxxxxxxxxx'" <platform-text-dev@xxxxxxxxxxx>, "'platform-swt-dev@xxxxxxxxxxx'" <platform-swt-dev@xxxxxxxxxxx>
        cc:        
        Subject:        [platform-swt-dev] Right click behavior (bug #19825) and proposal



Note: this is mostly a text issue, but there has been a bit of
back-and-forth between text-dev and swt-dev, so I'm posting to swt-dev as
well.

from http://bugs.eclipse.org/bugs/show_bug.cgi?id=19825 - Right clicking in
an editor window should operate where clicked:

There have been a number of concerns about changing the behavior when there
is a selection.  Please note that changing this behavior is *not* my primary
objective.  In fact, I could live with exactly the way it works now.  My
primary issue is what happens when there is *no selection*.  I maintain that
it is clumsy and non-intuitive (see McQ's comment #8 about trees) to not
move the caret when there is no selection.  To my knowledge, no one has
raised any objections to this particular aspect.

Having said that, I do prefer that a right click that is not on a selection
move the caret.  But why should it only work one way?  Why should everyone
be forced to do it McQ's preferred way, or my preferred way?  There is no
reason why Eclipse's text editor shouldn't be the most powerful,
configurable text editor available.  When differences of opinion arise on an
issue such as this, I propose that it become a matter of policy that instead
of deciding that it should or should not be supported, it should be
supported and a preference added to control it (this is, of course, assuming
the behavior is reasonable).  This allows each developer to configure
Eclipse's editor the way *they* want it to work, and everyone wins.

Ron

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev


Back to the top