[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-swt-dev] Right click behavior (bug #19825) and prop osal
|
Absolutely. Doing one simple, well thought out
thing is almost always the way to go. However, I believe that a text
editor is one of those special cases where user preference becomes important
enough to warrant more customizable behavior (as Nick said).
Note
that when I say "more customizable behavior" I don't mean "support for any crazy
thing you can dream up." They should be things that one can reasonably
expect to be beneficial to a large enough subset of the Eclipse user
base. I would say that many behaviors/preferences found in the most
popular text editors fall into this category (by virtue of the fact that they
*are* the most popular editors).
Ron
I concur wholeheartedly. Having preferences for
everything including the kitchen sink is usually indicative of a design
failure, rather than a real benefit.
I'm very happy that my car does not have a preference for whether I
want my brake pedal on the left or right of the gas pedal.
Preferences also make it hard to test,
document, diagnose user problems etc.
(Note that we recently included a dump of the non-default preference
settings in the Help / About / Configuration Details for this reason.)
Sometimes though, you really do want to
enable different ways of working. I think a lot of the text editor prefs
fit in this category.
Nick
| Mike
Wilson/Ottawa/IBM@IBMCA Sent
by: platform-swt-dev-admin@xxxxxxxxxxx
02/03/03 11:58 AM Please respond to platform-swt-dev
| To:
platform-swt-dev@xxxxxxxxxxx,
platform-text-dev@xxxxxxxxxxx cc:
Subject: 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