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. 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. 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. 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]>: > 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" >
