Hi, On Wed, Oct 1, 2014 at 12:47 AM, Nicolas Cellier < [email protected]> 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? > At the same time, the comparison is a bit stretched because we are talking about the problem of having one detached input device with one signal at a time. For this reason, it is precisely the invention of a cursor that ameliorates the problem. If the cursor would not be visible, you would indeed have a huge problem. But, the cursor being clearly visible makes the whole situation much less problematic. Modes are not good because I have to remember where I am. If I can avoid them, I do. > 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. > 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? > We did not suppress anything. Alain implemented it from scratch and instead of making it the responsibility of a text editor to manipulate fake-double-clicking, he used double clicking. My perception is that this kind of small changes adds no value. > 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 think its the opposite. People will simply adapt. > 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 :) > :) Doru > > 2014-09-30 22:59 GMT+02:00 Tudor Girba <[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]> 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]>: >>> >>>> 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]> 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 >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"
