On 1/10/14 00:47, Nicolas Cellier wrote:
You're right, a modal UI that would involve a triple, quadruple click
or cycle between even more states would be annoying.
But just switching a selection, how so? Personnally I don't mind. Is
it a matter of taste?
Anyway, the whole text editor is modal, mind you, did you see this
thing named cursor?
If I pause, then start typing again, it writes where I stopped 5
minutes ago instead of where my own focus shifted... That's quite
stupid ;)
Or maybe you suggest the right solution would be a vanishing cursor
materializing the loss of focus of the text widget after an arbitrary
delay, for the sake of relaxing my cognitive load?
From the implementation point of view, handling click-pause-click is
more than simple by reusing the existing selection state and is not
requiring any arbitrary Delay and its additional states.
So I don't see a huge value in suppressing it.
I agree with nicolas.
Is it motivated by cleaning code duplication after adding a specific
double click handling?
Or is reducing the features to a core set a goal per se?
My perception is that this kind of small changes adds no value.
+1
It just removes a small bit of value.
So it's going to frustrate someone for nothing.
Not a big frustration, I concede, but a gratuitous one.
I agree
Finally, the best thing it brings is exposing that some events are
handled incorrectly.
At least I hope it will give us a chance to correct them :)
2014-09-30 22:59 GMT+02:00 Tudor Girba <[email protected]
<mailto:[email protected]>>:
Hi,
I can see how people get use with this behavior, but I am quite
certain that the solution from PluggableTextMorph was a workaround
solution due to a missing double click event. Now we have that
event and we can use it where it is appropriate.
It's not that we copy things for the sake of copying, but I simply
think double clicking is a better choice here. click-pause-click
introduces, from a cognitive perspective, a hidden modal mode.
That is, you have no chance of knowing in which state you are. I
was several times annoyed by inadvertently selecting pieces of
code (often during demos). At the same time, I believe it is
reasonable to assume that programmers know how to double click.
So, yes, I did think of it quite explicitly :)
Doub
Cheers,
Doru
On Tue, Sep 30, 2014 at 10:46 PM, Nicolas Cellier
<[email protected]
<mailto:[email protected]>> wrote:
I find click pause click useful.
No stress nor necessary adjustment of double-click delay.
What could be the intention of a user clicking repeatedly on
the same area?
Did you think of it?
If copying what everyone else does is the sole value, then
let's not do Pharo.
2014-09-30 21:34 GMT+02:00 Tudor Girba <[email protected]
<mailto:[email protected]>>:
Hi,
I explained before but it went unnoticed. The selection
happens on double click like in any other editor.
The regular PluggableTextMorph also tries to do it on a
kind of a double click, only it is implemented as
click-pause-click. So, if you click once, wait 5 minutes,
and click again, it will select. This is not particularly
useful.
So, Rubric selects on double click.
Now, as I mentioned before, there happens to be a random
double click issue. I cannot reproduce it, but sometimes
it happens. Also, when I save the image and load it back,
the problem is gone. Please note that this issue is not
related to Rubric, but to the double click event
throughout the entire image. For example, if you see that
double click does not work in Rubric, try to double click
on the window title to maximize a window and you will see
that it does not work.
Cheers,
Doru
On Tue, Sep 30, 2014 at 8:42 PM, stepharo
<[email protected] <mailto:[email protected]>> wrote:
With the previous tools I can select a piece of text
by clicking after its last element and now I cannot
or I can but sometimes.
So what is the fix?
Stef
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
