[squeak-dev] Re: A better looking text caret (IMO)

[squeak-dev] A better looking text caret (IMO)

***
>Igor Stasenko siguctua at gmail.com
>Sun Feb 24 02:49:19 UTC 2008
>
>
>On 24/02/2008, Matthew Fulmer <tapplek at gmail.com>
wrote:
>> On Sun, Feb 24, 2008 at 04:38:32AM +0200, Igor
Stasenko wrote:
>>  > Sometimes it's hard to notice a caret position
in text, because it's
>>  > thin and my display is soo big :)
>>  > This patch draws caret as 5 pixel width vertical
bar. It's much easier
>>  > for my eyes to track it's position in text.
>>  >
>>  > I'm also wanted to make it blinking.. but hmm..
i think it will
>>  > require adding too much for achieving that,
because caret is not
>>  > considered as some kind of visual object in text
morph, and drawn only
>>  > when selection is empty and only during text
update :(
>>
>>
>> You should submit this as a bug report, not an
email
>>
>
>It's not a bug :)
>It's just another way to draw cursor caret , to
anyone who might like
>it more than current one.

An enhancement is a perfectly good topic for a mantis
issue. I would usually tag it with [ENH].

Mantis tracks issues. So putting a report on mantis is
a perfectly good way to begin to change squeak. The
attention to mail is ephemeral. Here today gone
tommorrow. Mail is a good way to draw attention to an
issue. Mantis is a good way to see an issue followed
up.

A good sequence is Mantis report any clearly
describable complaint. Follow with mail pointing to
the report. Add analysis and useful code to mantis (if
no one else beats you to it.) Then call attention to
mantis issues ready for harvest when a good* release
team is in place.


Yours in service and curiosity, --Jerome Peace

* A good release team is one that respects you. And
trusts your work iff you have earned their trust.



      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

http://bugs.squeak.org/view.php?id=6948


--
Best regards,
Igor Stasenko AKA sig.

Very useful to me, specially on the laptop when I use it on the backyard of my house in warm summer afternoons.

"Igor Stasenko" <[hidden email]> wrote in message
news:[hidden email]...
> http://bugs.squeak.org/view.php?id=6948

I've added an implementation for a blinking caret to this mantis entry.
Cheers,
Andy
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

On Feb 25, 2008, at 12:08 , Andrew Tween wrote:

>
> "Igor Stasenko" <[hidden email]> wrote in message news:
> [hidden email]...
>> http://bugs.squeak.org/view.php?id=6948
>
> I've added an implementation for a blinking caret to this mantis  
> entry.
> Cheers,
> Andy

Eeek! ;)

- Bert -

On 25/02/2008, Andrew Tween <[hidden email]> wrote:
>
>  "Igor Stasenko" <[hidden email]> wrote in message
>  news:[hidden email]...
>
> > http://bugs.squeak.org/view.php?id=6948
>
>
> I've added an implementation for a blinking caret to this mantis entry.

Cool! I didn't took a look on it yet. You noticed that blinking
requires redrawing text morph, which is suboptimal of course.
I perfect, there should be a single global caret morph. And text
morphs should talk to it in cases:
- focus changed (to relocate caret)
- selection changed (to hide caret when text range is selected, or
relocate to other point).

Then, we can use any custom shape to represent caret, and put choosing
different shapes in preferences.

A caret morph should not report any portion of screen as dirty (so
morphic will not try to redraw everything under it), instead, it
should take steps for preserving underlying pixels, and make sure to
hide itself when text morph is about to redraw, and show again when
draw cycle is idle.
A simple dead option could be to use bitXor operation when drawing
caret shape. So if you draw it twice, underlying pixels are unchanged.

>  Cheers,
>  Andy



--
Best regards,
Igor Stasenko AKA sig.

Today I've had "fun" trying to fix a problem with our software (that uses
many processes running at various priorities). Due to the use of a
WeakIdentitykeyDictionary I was running into problems witht the dictionary
having multiple identical keys... not pleasant, especially when it gets to
around 27000 entries (should be 20).

I have traced the problem to the fact that finalisation is not thread-safe
with respect to access of said dictionary. As a fix I have implemented a
#critical: method on the WeakArray class that evaluates the given block with
a #critical: call on the FinalizationLock of WeakArray.

Access to the weak dictionary is now wrapped with a WeakArray critical:
[...] and the problems have, thankfully, disappeared.

I can post a Mantis entry for this if you all think it is appropriate. Just
wondering how many other places in existing Squeak code might trip up on
this.

Regards, Gary.

On 25/02/2008, Gary Chambers <[hidden email]> wrote:
Is this means, that if i'm having multiple instances of WeakArray, i
can access only to one of them at given point of time?
If so, then it's bad :)

>
>  I can post a Mantis entry for this if you all think it is appropriate. Just
>  wondering how many other places in existing Squeak code might trip up on
>  this.
>
>  Regards, Gary.
>
>
>


--
Best regards,
Igor Stasenko AKA sig.

If you can think of a better way of blocking if finalization is in progress... only WeakRegistry has its own protection semaphore at present. (uses WeakKeyDictionary, rather than Identity, oddly).

I'm glad to hear about improvements in Squeak's ergonomy

        thanks !

Sebastian Sastre


 

On Feb 25, 2008, at 3:11 AM, Bert Freudenberg wrote:

FWIW I find that the feel of Andy's "blinking caret" combined with the  
look of Takashi's i-beam caret (used in the olpc/etoys image) to be  
rather agreeable.

Cheers

-- Scott

Works ok with UI Enhancements too :-)

Scott Wallace wrote: When we are at it we should fix the issue that happen when you delete
all chars from a text and the caret get a smaller size and change the
font !!! Very annoying !

Karl

Indeed!

> >
> When we are at it we should fix the issue that happen when you delete
> all chars from a text and the caret get a smaller size and change the
> font !!! Very annoying !
>
> Karl
>

On 25/02/2008, karl <[hidden email]> wrote:
Yes, it's because the height of caret should depend on a character
which its standing upon.
I can't find an easy way to determine character properties at current
caret position (or any position in text), so i given up with changing
shape.
These paragraph/textmorph are complex beasts :)


>
>  Karl
>
>


--
Best regards,
Igor Stasenko AKA sig.

2008/2/25, Gary Chambers <[hidden email]>:
In general weak array finalization will kill you sooner or later
anyway. One of the big performance improvements in Seaside is removing
WeakIdentitykeyDictionarys. We could simply not live with the fact
that at one point the image will block for 20 minutes and hog the CPU.
We now use more memory because we reclaim space later but do not block
the image for minutes anymore.

Cheers
Philippe

Andrew,

i propose to change TextMorph>>#step method to following:

step
        (paragraph notNil and:[paragraph focused])
                ifTrue:[
                        paragraph toggleCaretBlinkShow.
                        self invalidRect: self caretRect
 ]


and new method #caretRect should return a bounds which currently
occupied by caret.
Then, hopefully, textmorph will redraw only single line each step, not
everything visible on it.

The problem is with determining this rect..
An easy way can be to add an ivar (caretRect) and update it during
selection change or during textmorph redraw.
Or.. if there are way to determine these bounds with short
calculation, then we don't need adding ivar.

Have any ideas, how #caretRect should look like?

--
Best regards,
Igor Stasenko AKA sig.

Seems more down to a wandering default font index on the font and its disassociation from the lineGrid baseline and leading on TextStyle to me...
It is very annoying though.

Aye. The fix I jusggested keeps them from getting out of hand. I have modified our synchronization framework to allow per-instance maps too (rather than weak), rather like I've modified Morph to have per-instance (via properites) action maps for events.

Hi,
"Igor Stasenko" <[hidden email]> wrote in message
news:[hidden email]...
I'd do the easy way.
Where were you planning on adding the ivar? In NewParagraph ?

> Or.. if there are way to determine these bounds with short
> calculation, then we don't need adding ivar.
>
> Have any ideas, how #caretRect should look like?

Just gets the caretRect ivar value from paragraph?
With caretRect set by the paragraph whenever it draws the caret.
I don't know if the co-ordinate system of TextMorph and NewParagraph will
always be the same.
I think there is a Canvas in the middle. And what about margins, rotation
etc.?
Try it and see.

Cheers,
Andy

>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>