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 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
-----Original Message-----
From: Nick_Edgar@xxxxxxxxxx [mailto:Nick_Edgar@xxxxxxxxxx]
Sent: Monday, February 03, 2003 12:59 PM
To: platform-swt-dev@xxxxxxxxxxx; platform-text-dev@xxxxxxxxxxx
Subject: Re: [platform-swt-dev] Right click behavior (bug #19825) and proposal


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




Back to the top