[haiku-commits] Re: haiku: hrev47567 - src/kits/interface
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 25 Jul 2014 09:57:28 +0200
Am 25.07.2014 01:53, schrieb John Scipione:
On Thu, Jul 24, 2014 at 6:07 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
At least nice that you fixed another regression, even though you seem to
have borked it, too. The BeOS solution definitely makes sense. Please
implement that one instead.
I actually implemented the BeOS solution as well but I was and am
reluctant to use it. There are pro's and con's on both sides and I am
not convinced that the BeOS solution is superior.
If I am reading the commit message correctly, I agree with John. What I
would like the keys to control is the selection caret, just like the
cursor keys conrol the selection caret. Let's try to make it clear by
example:
-------------S###########
#########################
##################E------
This is the selection, with S being the selection anchor (where it
started) and E being the end (i.e. the current caret position). When I
Shift-press the arrow keys left or right, I can modify the selection
like this:
-------------S###########
#########################
##############E---------- (Left)
-------------S###########
#########################
######################E-- (Right)
So what I would expect Shift-Home and End to do is this:
-------------S###########
#########################
E------------------------ (Home)
-------------S###########
#########################
########################E (End)
Analogous for when the selection anchor is at the end of the selection
and I modify the beginning.
IIUC, what the BeOS behavior was is this:
S########################
#########################
##################E------ (Home)
-------------S###########
#########################
########################E (End)
It does not make sense to me, since what I want to be controlled is
consistently the caret and never the anchor. Just like it's the regular
text caret, only that it is invisible and can be on either side of the
selection, depending on where the selection started and in which
direction it extended.
Is it possible to forbid you to do any changes that change more than two
characters? This is really more than just a little annoying.
I'm sorry that you are annoyed, all I can do is apologize and to try
and fix any issues that come up as soon as possible. Also, changing
the array size only involved changing 1 character and I managed to
still screw that up so I don't think that would completely solve the
problem.
John, I admire your reaction! You are also quick to clean up after
yourself if errors are pointed out, so please know that this is
recognized and appreciated.
However, I understand how Axel is feeling. I think the problem is we
"old timers" have so little time left for Haiku and then we are anxiuos
that the code quality may degrade little by little. Especially with
large cleanup commits that get not reviewed closely enough and then
there are logic reversals or worse mistakes. When these get discovered
by accident, it leaves a really bad feeling if there might be more which
is /not/ discovered.
Then apparently Axel took time to talk with you in IRC and guide you.
And I think what he is angry about is when you get it wrong still,
regardless of whether you corrected it later. I know this feeling,
because lately I talked with Adrien about app_server stuff a lot. In one
instance I could point out a commit which outlined exactly all the
places where code needed changing and he still managed to overlook some.
It generates the feeling that stuff is not done right unless one does it
oneself. Now, (especially Adrien when he reads this), I know that I
shouldn't feel like this! I know that Adrien's work brings Haiku forward
and he also tackles stuff that I have no clue about (what with stack
corruptions and mis-alignments and so on).
I am just trying to explain where some of that anger may come from. It
is hard to not get anxious about losing influence and to stay objective
and especially not to consider the code quality /only/. Because in a
community project like ours, its not only about the code quality.
Best regards,
-Stephan
Other related posts:
