Smalltalk › Pharo › Pharo Smalltalk Developers

GTTools bug - why I cannot select the text by simply clicking at the end of it....

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

stepharo

GTTools bug - why I cannot select the text by simply clicking at the end of it....

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

Tudor Girba-2

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

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 <[hidden email]> 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"

Nicolas Cellier

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

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 <[hidden email]>:

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 <[hidden email]> 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"

Tudor Girba-2

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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"

Nicolas Cellier

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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"

Tudor Girba-2

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

Hi,

On Wed, Oct 1, 2014 at 12:47 AM, Nicolas Cellier <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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"

stepharo

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

In reply to this post by Nicolas Cellier

I find click pause click useful.

Me too.

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 <[hidden email]>:

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 <[hidden email]> 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"

stepharo

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

In reply to this post by Tudor Girba-2

I do not get your point. I do not see why this is mode.
If the cursor is already on something or at the end or beginning of something clicking on the same place, select it.
This is just different but it works. and it is not incompatible with also supporting double clicking. So why now we
cannot have the previous behavior which was compatible with what the world is doing but in addition let us
work.
We can also say that double clicking is strange.

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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"

stepharo

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

In reply to this post by Nicolas Cellier

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.

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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"

stepharo

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

In reply to this post by Tudor Girba-2

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.

Seriously I find that attitude really sad.
So why don't add TxText with average syntax higthlitghting and that igor just does something else
on the sake that people will adapt.

For me there is no justification for not having the same behavior with is working perfectly well.
It is not a question of dogma but just pragmatic
    - it works well
    - it is handy
    - it is not incompatible with the double click dogma.

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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"

Uko2

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

If my 2 cents make sense, it will be nice to have things similar to text editors. E.g. triple click for line select.

Uko

On 01 Oct 2014, at 07:51, stepharo <[hidden email]> wrote:

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.

Seriously I find that attitude really sad.
So why don't add TxText with average syntax higthlitghting and that igor just does something else
on the sake that people will adapt.

For me there is no justification for not having the same behavior with is working perfectly well.
It is not a question of dogma but just pragmatic
    - it works well
    - it is handy
    - it is not incompatible with the double click dogma.

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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"

Tudor Girba-2

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

In reply to this post by stepharo

Hi Stef,

Thanks for your comments. In particular, the one about clicking on the current cursor. I never saw it like that because I always used the mouse. So in fact, I was wrong in seeing it as click-pause-click because it should have been as click-on-cursor. I actually like this one.

However, the current behavior from TextMorph is incompatible with double click because if I double click on the cursor, then the selection is set and then deleted because the current implementation treats the double click as two clicks. But, I believe we could change that one and have both the click-on-cursor and the double-click select.

I opened a ticket:

https://pharo.fogbugz.com/f/cases/14132/Rubric-should-support-click-on-cursor

Cheers,

Doru

On Wed, Oct 1, 2014 at 7:51 AM, stepharo <[hidden email]> wrote:

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.

Seriously I find that attitude really sad.
So why don't add TxText with average syntax higthlitghting and that igor just does something else
on the sake that people will adapt.

For me there is no justification for not having the same behavior with is working perfectly well.
It is not a question of dogma but just pragmatic
    - it works well
    - it is handy
    - it is not incompatible with the double click dogma.

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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"

www.tudorgirba.com

"Every thing has its own flow"

kilon.alios

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

In reply to this post by Uko2

Why it has to be black or white just implement both or all of these ideas and let user choose in pharo settings. Problem solved

Στις 1 Οκτ 2014 9:55 π.μ., ο χρήστης "Yuriy Tymchuk" <[hidden email]> έγραψε:

If my 2 cents make sense, it will be nice to have things similar to text editors. E.g. triple click for line select.

Uko

On 01 Oct 2014, at 07:51, stepharo <[hidden email]> wrote:

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.

Seriously I find that attitude really sad.
So why don't add TxText with average syntax higthlitghting and that igor just does something else
on the sake that people will adapt.

For me there is no justification for not having the same behavior with is working perfectly well.
It is not a question of dogma but just pragmatic
    - it works well
    - it is handy
    - it is not incompatible with the double click dogma.

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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"

Tudor Girba-2

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

In reply to this post by Uko2

Hi Uko,

I think you mean that triple clicking on the cursor when it is inside the line should select the line, right?

Cheers,

Doru

On Wed, Oct 1, 2014 at 8:54 AM, Yuriy Tymchuk <[hidden email]> wrote:

If my 2 cents make sense, it will be nice to have things similar to text editors. E.g. triple click for line select.

Uko

On 01 Oct 2014, at 07:51, stepharo <[hidden email]> wrote:

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.

Seriously I find that attitude really sad.
So why don't add TxText with average syntax higthlitghting and that igor just does something else
on the sake that people will adapt.

For me there is no justification for not having the same behavior with is working perfectly well.
It is not a question of dogma but just pragmatic
    - it works well
    - it is handy
    - it is not incompatible with the double click dogma.

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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"

www.tudorgirba.com

"Every thing has its own flow"

Uko2

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

I guess it should be double click on cursor because first click places the cursor. When you open TextEdit with some text and do 3 consecutive clicks. After the second click it selects the word your cursor is on, after 3rd one it selects line that your cursor is on. I don’t know, maybe other people don’t need this, but I’m used to work with test like that, so maybe others are too.

Uko

On 01 Oct 2014, at 09:45, Tudor Girba <[hidden email]> wrote:

Hi Uko,

I think you mean that triple clicking on the cursor when it is inside the line should select the line, right?

Cheers,
Doru

On Wed, Oct 1, 2014 at 8:54 AM, Yuriy Tymchuk <[hidden email]> wrote:
If my 2 cents make sense, it will be nice to have things similar to text editors. E.g. triple click for line select.

Uko

On 01 Oct 2014, at 07:51, stepharo <[hidden email]> wrote:

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.

Seriously I find that attitude really sad.
So why don't add TxText with average syntax higthlitghting and that igor just does something else
on the sake that people will adapt.

For me there is no justification for not having the same behavior with is working perfectly well.
It is not a question of dogma but just pragmatic
    - it works well
    - it is handy
    - it is not incompatible with the double click dogma.

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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"

--
www.tudorgirba.com

"Every thing has its own flow"

Tudor Girba-2

Re: GTTools bug - why I cannot select the text by simply clicking at the end of it....

It is tripple click :).

If you click first to set the cursor, you still have to click three times to select the whole line. The nice thing though is that even if the cursor is not there, you still only require triple click to select the whole line.

It's actually quite nice, but we would need the triple-click event in Pharo for that.

Cheers,

Doru

On Wed, Oct 1, 2014 at 9:55 AM, Yuriy Tymchuk <[hidden email]> wrote:

I guess it should be double click on cursor because first click places the cursor. When you open TextEdit with some text and do 3 consecutive clicks. After the second click it selects the word your cursor is on, after 3rd one it selects line that your cursor is on. I don’t know, maybe other people don’t need this, but I’m used to work with test like that, so maybe others are too.

Uko

On 01 Oct 2014, at 09:45, Tudor Girba <[hidden email]> wrote:

Hi Uko,

I think you mean that triple clicking on the cursor when it is inside the line should select the line, right?

Cheers,
Doru

On Wed, Oct 1, 2014 at 8:54 AM, Yuriy Tymchuk <[hidden email]> wrote:
If my 2 cents make sense, it will be nice to have things similar to text editors. E.g. triple click for line select.

Uko

On 01 Oct 2014, at 07:51, stepharo <[hidden email]> wrote:

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.

Seriously I find that attitude really sad.
So why don't add TxText with average syntax higthlitghting and that igor just does something else
on the sake that people will adapt.

For me there is no justification for not having the same behavior with is working perfectly well.
It is not a question of dogma but just pragmatic
    - it works well
    - it is handy
    - it is not incompatible with the double click dogma.

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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"

--
www.tudorgirba.com

"Every thing has its own flow"

www.tudorgirba.com

"Every thing has its own flow"