The Trunk: Morphic-mt.1514.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Morphic-mt.1514.mcz

commits-2
Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1514.mcz

==================== Summary ====================

Name: Morphic-mt.1514
Author: mt
Time: 5 September 2019, 2:36:47.777837 pm
UUID: 49f63b40-72ce-c447-9fb0-9400ea43fab2
Ancestors: Morphic-mt.1513, Morphic-ct.1501

Merges Morphic-ct.1500. and 1501.

Can't we just filter for #isAlphaNumeric? Do we need parentheses etc.? Would be more readable than  ">= 32". I also do not think that #caseOf: helps much in terms of readability. ;-)

=============== Diff against Morphic-mt.1513 ===============

Item was changed:
  ----- Method: MenuMorph>>handleFiltering: (in category 'keystroke helpers') -----
  handleFiltering: evt
 
  | matchString |
  matchString := self valueOfProperty: #matchString ifAbsentPut: [ String new ].
+ matchString := true
+ caseOf: {
+ [ evt keyCharacter = Character backspace ] ->
+ [ matchString isEmpty
+ ifTrue: [ matchString ]
+ ifFalse: [ matchString allButLast ] ].
+ [ evt keyValue >= 32 ] ->
+ [ matchString , evt keyCharacter ] }
+ otherwise: [ matchString ].
- matchString := evt keyValue = 8 " Character backspace asciiValue "
- ifTrue: [
- matchString isEmpty
- ifTrue: [ matchString ]
- ifFalse: [ matchString allButLast ] ]
- ifFalse: [
- matchString copyWith: evt keyCharacter ].
  self setProperty: #matchString toValue: matchString.
  self displayFiltered: evt!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-mt.1514.mcz

Christoph Thiede

Personally, I sometimes type-to-filter a menu for things like '...' or ' ' (space). Am I the only one who does this? :)


I still would consider something like Character>>#isControlCharacter useful. How about this?


Unicode class>>isControlCode: charCode
^ (self generalCategoryOf: charCode) <= Cs

Character>>isControlCharacter
^ self encodedCharSet isControlCode: self charCode

Versions for other char sets would have to be added.

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
Gesendet: Donnerstag, 5. September 2019 14:36:59
An: [hidden email]; [hidden email]
Betreff: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
 
Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1514.mcz

==================== Summary ====================

Name: Morphic-mt.1514
Author: mt
Time: 5 September 2019, 2:36:47.777837 pm
UUID: 49f63b40-72ce-c447-9fb0-9400ea43fab2
Ancestors: Morphic-mt.1513, Morphic-ct.1501

Merges Morphic-ct.1500. and 1501.

Can't we just filter for #isAlphaNumeric? Do we need parentheses etc.? Would be more readable than  ">= 32". I also do not think that #caseOf: helps much in terms of readability. ;-)

=============== Diff against Morphic-mt.1513 ===============

Item was changed:
  ----- Method: MenuMorph>>handleFiltering: (in category 'keystroke helpers') -----
  handleFiltering: evt
 
         | matchString |
         matchString := self valueOfProperty: #matchString ifAbsentPut: [ String new ].
+        matchString := true
+                caseOf: {
+                        [ evt keyCharacter = Character backspace ] ->
+                                [ matchString isEmpty
+                                        ifTrue: [ matchString ]
+                                        ifFalse: [ matchString allButLast ] ].
+                        [ evt keyValue >= 32 ] ->
+                                [ matchString , evt keyCharacter ] }
+                otherwise: [ matchString ].
-        matchString := evt keyValue = 8 " Character backspace asciiValue "
-                ifTrue: [
-                        matchString isEmpty
-                                ifTrue: [ matchString ]
-                                ifFalse: [ matchString allButLast ] ]
-                ifFalse: [
-                        matchString copyWith: evt keyCharacter ].
         self setProperty: #matchString toValue: matchString.
         self displayFiltered: evt!




Reply | Threaded
Open this post in threaded view
|

#isControlCharacter (was: The Trunk: Morphic-mt.1514.mcz)

Christoph Thiede

Hi,


any opinions about this proposal? :-)


Best,

Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Donnerstag, 5. September 2019 15:06 Uhr
An: [hidden email]; [hidden email]
Betreff: Re: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
 

Personally, I sometimes type-to-filter a menu for things like '...' or ' ' (space). Am I the only one who does this? :)


I still would consider something like Character>>#isControlCharacter useful. How about this?


Unicode class>>isControlCode: charCode
^ (self generalCategoryOf: charCode) <= Cs

Character>>isControlCharacter
^ self encodedCharSet isControlCode: self charCode

Versions for other char sets would have to be added.

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
Gesendet: Donnerstag, 5. September 2019 14:36:59
An: [hidden email]; [hidden email]
Betreff: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
 
Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-mt.1514.mcz

==================== Summary ====================

Name: Morphic-mt.1514
Author: mt
Time: 5 September 2019, 2:36:47.777837 pm
UUID: 49f63b40-72ce-c447-9fb0-9400ea43fab2
Ancestors: Morphic-mt.1513, Morphic-ct.1501

Merges Morphic-ct.1500. and 1501.

Can't we just filter for #isAlphaNumeric? Do we need parentheses etc.? Would be more readable than  ">= 32". I also do not think that #caseOf: helps much in terms of readability. ;-)

=============== Diff against Morphic-mt.1513 ===============

Item was changed:
  ----- Method: MenuMorph>>handleFiltering: (in category 'keystroke helpers') -----
  handleFiltering: evt
 
         | matchString |
         matchString := self valueOfProperty: #matchString ifAbsentPut: [ String new ].
+        matchString := true
+                caseOf: {
+                        [ evt keyCharacter = Character backspace ] ->
+                                [ matchString isEmpty
+                                        ifTrue: [ matchString ]
+                                        ifFalse: [ matchString allButLast ] ].
+                        [ evt keyValue >= 32 ] ->
+                                [ matchString , evt keyCharacter ] }
+                otherwise: [ matchString ].
-        matchString := evt keyValue = 8 " Character backspace asciiValue "
-                ifTrue: [
-                        matchString isEmpty
-                                ifTrue: [ matchString ]
-                                ifFalse: [ matchString allButLast ] ]
-                ifFalse: [
-                        matchString copyWith: evt keyCharacter ].
         self setProperty: #matchString toValue: matchString.
         self displayFiltered: evt!




Reply | Threaded
Open this post in threaded view
|

Re: #isControlCharacter (was: The Trunk: Morphic-mt.1514.mcz)

David T. Lewis

Reply | Threaded
Open this post in threaded view
|

Re: #isControlCharacter (was: The Trunk: Morphic-mt.1514.mcz)

marcel.taeumel
Menu filtering is so cool! :-) And convenient.

This proposal about #isControlCharacter aims at preventing malformed user input. For example, the user might wonder if a filter does strange things only because the system cannot render certain (wrongly) typed characters.

An easier solution would be to render "?" or something similar for such characters. Then, the user can recognize the bad input and hit the [backspace] key. This way, we do not constrain ourselves to a specific range of menu labels at all. :-)

Best,
Marcel

Am 03.10.2019 02:34:40 schrieb David T. Lewis <[hidden email]>:

My personal event horizon does not extend beyond seven bits, so
anything that I say about Unicode should not be taken seriously.
However:

The concept of "isControlCharacter" dates back to the days of data
terminals connected over seven bit serial lines, and to the use of control
characters for various functions not related to printing characters on
the display screen. I do not really understand the reference to
"type-to-filter a menu for things like '...' or ' ' (space)", but
it does not sound to me like "control character" would be the right
description.

Wikipedia has http://en.wikipedia.org/wiki/Control_character which
gives good background. It includes a paragraph about Unicode that
says this:

In Unicode, "Control-characters" are U+0000—U+001F
(C0 controls), U+007F (delete), and U+0080—U+009F
(C1 controls). Their General Category is "Cc". Formatting codes
are distinct, in General Category "Cf". The Cc control characters
have no Name in Unicode, but are given labels such as ""
instead.

So it certainly would be possible to define #isControlCharacter
for Unicode characters, but IMHO it seems to drag along some ancient
concepts of serial data communications that are probably not
meaningful inside a Squeak image.

Another reference is "man 3 isalpha" on Unix/Linux (C89 and Posix).
There are quite a few character testing functions. Most of them
do not exist in Squeak, and I would not be inclined to start adding
any of them without a good reason.

Dave


On Wed, Oct 02, 2019 at 11:05:04PM +0000, Thiede, Christoph wrote:

> Hi,
>
>
> any opinions about this proposal? :-)
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev im Auftrag von Thiede, Christoph
> Gesendet: Donnerstag, 5. September 2019 15:06 Uhr
> An: [hidden email]; [hidden email]
> Betreff: Re: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
>
>
> Personally, I sometimes type-to-filter a menu for things like '...' or ' ' (space). Am I the only one who does this? :)
>
>
> I still would consider something like Character>>#isControlCharacter useful. How about this?
>
>
> Unicode class>>isControlCode: charCode
> ^ (self generalCategoryOf: charCode) <= cs="">
>
> Character>>isControlCharacter
> ^ self encodedCharSet isControlCode: self charCode
>
> Versions for other char sets would have to be added.
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev im Auftrag von [hidden email]
> Gesendet: Donnerstag, 5. September 2019 14:36:59
> An: [hidden email]; [hidden email]
> Betreff: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
>
> Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
> http://source.squeak.org/trunk/Morphic-mt.1514.mcz
>
> ==================== Summary ====================
>
> Name: Morphic-mt.1514
> Author: mt
> Time: 5 September 2019, 2:36:47.777837 pm
> UUID: 49f63b40-72ce-c447-9fb0-9400ea43fab2
> Ancestors: Morphic-mt.1513, Morphic-ct.1501
>
> Merges Morphic-ct.1500. and 1501.
>
> Can't we just filter for #isAlphaNumeric? Do we need parentheses etc.? Would be more readable than ">= 32". I also do not think that #caseOf: helps much in terms of readability. ;-)
>
> =============== Diff against Morphic-mt.1513 ===============
>
> Item was changed:
> ----- Method: MenuMorph>>handleFiltering: (in category 'keystroke helpers') -----
> handleFiltering: evt
>
> | matchString |
> matchString := self valueOfProperty: #matchString ifAbsentPut: [ String new ].
> + matchString := true
> + caseOf: {
> + [ evt keyCharacter = Character backspace ] ->
> + [ matchString isEmpty
> + ifTrue: [ matchString ]
> + ifFalse: [ matchString allButLast ] ].
> + [ evt keyValue >= 32 ] ->
> + [ matchString , evt keyCharacter ] }
> + otherwise: [ matchString ].
> - matchString := evt keyValue = 8 " Character backspace asciiValue "
> - ifTrue: [
> - matchString isEmpty
> - ifTrue: [ matchString ]
> - ifFalse: [ matchString allButLast ] ]
> - ifFalse: [
> - matchString copyWith: evt keyCharacter ].
> self setProperty: #matchString toValue: matchString.
> self displayFiltered: evt!
>
>

>




Reply | Threaded
Open this post in threaded view
|

Re: #isControlCharacter (was: The Trunk: Morphic-mt.1514.mcz)

Chris Muller-3
On Mon, Oct 7, 2019 at 1:29 AM Marcel Taeumel <[hidden email]> wrote:
Menu filtering is so cool! :-) And convenient.

This proposal about #isControlCharacter aims at preventing malformed user input. For example, the user might wonder if a filter does strange things only because the system cannot render certain (wrongly) typed characters.

An easier solution would be to render "?" or something similar for such characters. Then, the user can recognize the bad input and hit the [backspace] key. This way, we do not constrain ourselves to a specific range of menu labels at all. :-)

-1.  We should let the machine do the recognition and backspacing -- e.g., any character which causes all selections of a menu to be grayed out should cause that character to be rejected.  Perhaps with a beep or flash of the menu.  Note this would provide a more consistent UI with the list-filtering, which behaves that way.

Menus should be constrained English, with use of #translated for other languages with special characters.

Best,
  Chris

 

Best,
Marcel

Am 03.10.2019 02:34:40 schrieb David T. Lewis <[hidden email]>:

My personal event horizon does not extend beyond seven bits, so
anything that I say about Unicode should not be taken seriously.
However:

The concept of "isControlCharacter" dates back to the days of data
terminals connected over seven bit serial lines, and to the use of control
characters for various functions not related to printing characters on
the display screen. I do not really understand the reference to
"type-to-filter a menu for things like '...' or ' ' (space)", but
it does not sound to me like "control character" would be the right
description.

Wikipedia has http://en.wikipedia.org/wiki/Control_character which
gives good background. It includes a paragraph about Unicode that
says this:

In Unicode, "Control-characters" are U+0000—U+001F
(C0 controls), U+007F (delete), and U+0080—U+009F
(C1 controls). Their General Category is "Cc". Formatting codes
are distinct, in General Category "Cf". The Cc control characters
have no Name in Unicode, but are given labels such as ""
instead.

So it certainly would be possible to define #isControlCharacter
for Unicode characters, but IMHO it seems to drag along some ancient
concepts of serial data communications that are probably not
meaningful inside a Squeak image.

Another reference is "man 3 isalpha" on Unix/Linux (C89 and Posix).
There are quite a few character testing functions. Most of them
do not exist in Squeak, and I would not be inclined to start adding
any of them without a good reason.

Dave


On Wed, Oct 02, 2019 at 11:05:04PM +0000, Thiede, Christoph wrote:

> Hi,
>
>
> any opinions about this proposal? :-)
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev im Auftrag von Thiede, Christoph
> Gesendet: Donnerstag, 5. September 2019 15:06 Uhr
> An: [hidden email]; [hidden email]
> Betreff: Re: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
>
>
> Personally, I sometimes type-to-filter a menu for things like '...' or ' ' (space). Am I the only one who does this? :)
>
>
> I still would consider something like Character>>#isControlCharacter useful. How about this?
>
>
> Unicode class>>isControlCode: charCode
> ^ (self generalCategoryOf: charCode) <= cs="">
>
> Character>>isControlCharacter
> ^ self encodedCharSet isControlCode: self charCode
>
> Versions for other char sets would have to be added.
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev im Auftrag von [hidden email]
> Gesendet: Donnerstag, 5. September 2019 14:36:59
> An: [hidden email]; [hidden email]
> Betreff: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
>
> Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
> http://source.squeak.org/trunk/Morphic-mt.1514.mcz
>
> ==================== Summary ====================
>
> Name: Morphic-mt.1514
> Author: mt
> Time: 5 September 2019, 2:36:47.777837 pm
> UUID: 49f63b40-72ce-c447-9fb0-9400ea43fab2
> Ancestors: Morphic-mt.1513, Morphic-ct.1501
>
> Merges Morphic-ct.1500. and 1501.
>
> Can't we just filter for #isAlphaNumeric? Do we need parentheses etc.? Would be more readable than ">= 32". I also do not think that #caseOf: helps much in terms of readability. ;-)
>
> =============== Diff against Morphic-mt.1513 ===============
>
> Item was changed:
> ----- Method: MenuMorph>>handleFiltering: (in category 'keystroke helpers') -----
> handleFiltering: evt
>
> | matchString |
> matchString := self valueOfProperty: #matchString ifAbsentPut: [ String new ].
> + matchString := true
> + caseOf: {
> + [ evt keyCharacter = Character backspace ] ->
> + [ matchString isEmpty
> + ifTrue: [ matchString ]
> + ifFalse: [ matchString allButLast ] ].
> + [ evt keyValue >= 32 ] ->
> + [ matchString , evt keyCharacter ] }
> + otherwise: [ matchString ].
> - matchString := evt keyValue = 8 " Character backspace asciiValue "
> - ifTrue: [
> - matchString isEmpty
> - ifTrue: [ matchString ]
> - ifFalse: [ matchString allButLast ] ]
> - ifFalse: [
> - matchString copyWith: evt keyCharacter ].
> self setProperty: #matchString toValue: matchString.
> self displayFiltered: evt!
>
>

>





Reply | Threaded
Open this post in threaded view
|

Re: #isControlCharacter (was: The Trunk: Morphic-mt.1514.mcz)

Christoph Thiede

Chris,


I did not forget this thread :)


My personal opinion is that the menu-filtering is actually more convenient (at least to me). If you type a non-matching filter term into a list morph (for example, "hello world" into the System Browser's class list), the filtering "breaks" half the way and a partial match is selected. If you are doing the same in a menu morph, however, each character is recorded so you can correct typing errors, and you do not need to check your results before pressing Enter. It happens so often that I type something wrong and get irritated as the whole list "stops working", not accepting any further character. I think menus are just convenient as they are, rather I would change the list implementation to show nothing (but maybe a "no-hit message"?) if nothing matches your filter term.


However, we were talking about refactoring. Do you actually think that "keyValue >= 32" in a morph class should be preferred to a string utility that gives the thing we want to do a clear name?


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
Gesendet: Montag, 7. Oktober 2019 20:30:42
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] #isControlCharacter (was: The Trunk: Morphic-mt.1514.mcz)
 
On Mon, Oct 7, 2019 at 1:29 AM Marcel Taeumel <[hidden email]> wrote:
Menu filtering is so cool! :-) And convenient.

This proposal about #isControlCharacter aims at preventing malformed user input. For example, the user might wonder if a filter does strange things only because the system cannot render certain (wrongly) typed characters.

An easier solution would be to render "?" or something similar for such characters. Then, the user can recognize the bad input and hit the [backspace] key. This way, we do not constrain ourselves to a specific range of menu labels at all. :-)

-1.  We should let the machine do the recognition and backspacing -- e.g., any character which causes all selections of a menu to be grayed out should cause that character to be rejected.  Perhaps with a beep or flash of the menu.  Note this would provide a more consistent UI with the list-filtering, which behaves that way.

Menus should be constrained English, with use of #translated for other languages with special characters.

Best,
  Chris

 

Best,
Marcel

Am 03.10.2019 02:34:40 schrieb David T. Lewis <[hidden email]>:

My personal event horizon does not extend beyond seven bits, so
anything that I say about Unicode should not be taken seriously.
However:

The concept of "isControlCharacter" dates back to the days of data
terminals connected over seven bit serial lines, and to the use of control
characters for various functions not related to printing characters on
the display screen. I do not really understand the reference to
"type-to-filter a menu for things like '...' or ' ' (space)", but
it does not sound to me like "control character" would be the right
description.

Wikipedia has http://en.wikipedia.org/wiki/Control_character which
gives good background. It includes a paragraph about Unicode that
says this:

In Unicode, "Control-characters" are U+0000—U+001F
(C0 controls), U+007F (delete), and U+0080—U+009F
(C1 controls). Their General Category is "Cc". Formatting codes
are distinct, in General Category "Cf". The Cc control characters
have no Name in Unicode, but are given labels such as ""
instead.

So it certainly would be possible to define #isControlCharacter
for Unicode characters, but IMHO it seems to drag along some ancient
concepts of serial data communications that are probably not
meaningful inside a Squeak image.

Another reference is "man 3 isalpha" on Unix/Linux (C89 and Posix).
There are quite a few character testing functions. Most of them
do not exist in Squeak, and I would not be inclined to start adding
any of them without a good reason.

Dave


On Wed, Oct 02, 2019 at 11:05:04PM +0000, Thiede, Christoph wrote:
> Hi,
>
>
> any opinions about this proposal? :-)
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev im Auftrag von Thiede, Christoph
> Gesendet: Donnerstag, 5. September 2019 15:06 Uhr
> An: [hidden email]; [hidden email]
> Betreff: Re: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
>
>
> Personally, I sometimes type-to-filter a menu for things like '...' or ' ' (space). Am I the only one who does this? :)
>
>
> I still would consider something like Character>>#isControlCharacter useful. How about this?
>
>
> Unicode class>>isControlCode: charCode
> ^ (self generalCategoryOf: charCode) <= cs="">
>
> Character>>isControlCharacter
> ^ self encodedCharSet isControlCode: self charCode
>
> Versions for other char sets would have to be added.
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev im Auftrag von [hidden email]
> Gesendet: Donnerstag, 5. September 2019 14:36:59
> An: [hidden email]; [hidden email]
> Betreff: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
>
> Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
> http://source.squeak.org/trunk/Morphic-mt.1514.mcz
>
> ==================== Summary ====================
>
> Name: Morphic-mt.1514
> Author: mt
> Time: 5 September 2019, 2:36:47.777837 pm
> UUID: 49f63b40-72ce-c447-9fb0-9400ea43fab2
> Ancestors: Morphic-mt.1513, Morphic-ct.1501
>
> Merges Morphic-ct.1500. and 1501.
>
> Can't we just filter for #isAlphaNumeric? Do we need parentheses etc.? Would be more readable than ">= 32". I also do not think that #caseOf: helps much in terms of readability. ;-)
>
> =============== Diff against Morphic-mt.1513 ===============
>
> Item was changed:
> ----- Method: MenuMorph>>handleFiltering: (in category 'keystroke helpers') -----
> handleFiltering: evt
>
> | matchString |
> matchString := self valueOfProperty: #matchString ifAbsentPut: [ String new ].
> + matchString := true
> + caseOf: {
> + [ evt keyCharacter = Character backspace ] ->
> + [ matchString isEmpty
> + ifTrue: [ matchString ]
> + ifFalse: [ matchString allButLast ] ].
> + [ evt keyValue >= 32 ] ->
> + [ matchString , evt keyCharacter ] }
> + otherwise: [ matchString ].
> - matchString := evt keyValue = 8 " Character backspace asciiValue "
> - ifTrue: [
> - matchString isEmpty
> - ifTrue: [ matchString ]
> - ifFalse: [ matchString allButLast ] ]
> - ifFalse: [
> - matchString copyWith: evt keyCharacter ].
> self setProperty: #matchString toValue: matchString.
> self displayFiltered: evt!
>
>

>





Reply | Threaded
Open this post in threaded view
|

Re: #isControlCharacter (was: The Trunk: Morphic-mt.1514.mcz)

Chris Muller-4
Hi Christoph,
 

My personal opinion is that the menu-filtering is actually more convenient (at least to me). If you type a non-matching filter term into a list morph (for example, "hello world" into the System Browser's class list), the filtering "breaks" half the way and a partial match is selected. If you are doing the same in a menu morph, however, each character is recorded so you can correct typing errors, and you do not need to check your results before pressing Enter. It happens so often that I type something wrong and get irritated as the whole list "stops working", not accepting any further character. I think menus are just convenient as they are, rather I would change the list implementation to show nothing (but maybe a "no-hit message"?) if nothing matches your filter term.

You're right.  And, you've even reminded me of one of my own UI principles that, in general, a unidirectional interaction -- where the user can direct the software without needing visual feedback -- is better wherever possible.  In this case, you can input via keyboard without having to read the screen, and even if you make a typing mistake, you can still direct it to your selection unidirectionally.  [End] key probably not hit while filtering, but when [Backspace]ing, so I think your tweak is fine.  :)

Lists aren't as predictable as menus, so two-way interaction is probably unavoidable, and if we displayed an empty list there'd be no place to display the current filter string..

However, we were talking about refactoring. Do you actually think that "keyValue >= 32" in a morph class should be preferred to a string utility that gives the thing we want to do a clear name?


No, I think clarity is better.  But not a new extension method.  More like how you improved the line higher up in the method from 

     evt keyValue = 8 " Character backspace asciiValue "

to 

     evt keyCharacter = Character backspace

I think you should've stuck with your improved pattern for the >=32 check, e.g., 

    evt keyCharacter >= Character space

and maybe a terse comment for why.  I certainly wouldn't make a whole new version of Morphic only for that, though.

Best,
  Chris



 


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
Gesendet: Montag, 7. Oktober 2019 20:30:42
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] #isControlCharacter (was: The Trunk: Morphic-mt.1514.mcz)
 
On Mon, Oct 7, 2019 at 1:29 AM Marcel Taeumel <[hidden email]> wrote:
Menu filtering is so cool! :-) And convenient.

This proposal about #isControlCharacter aims at preventing malformed user input. For example, the user might wonder if a filter does strange things only because the system cannot render certain (wrongly) typed characters.

An easier solution would be to render "?" or something similar for such characters. Then, the user can recognize the bad input and hit the [backspace] key. This way, we do not constrain ourselves to a specific range of menu labels at all. :-)

-1.  We should let the machine do the recognition and backspacing -- e.g., any character which causes all selections of a menu to be grayed out should cause that character to be rejected.  Perhaps with a beep or flash of the menu.  Note this would provide a more consistent UI with the list-filtering, which behaves that way.

Menus should be constrained English, with use of #translated for other languages with special characters.

Best,
  Chris

 

Best,
Marcel

Am 03.10.2019 02:34:40 schrieb David T. Lewis <[hidden email]>:

My personal event horizon does not extend beyond seven bits, so
anything that I say about Unicode should not be taken seriously.
However:

The concept of "isControlCharacter" dates back to the days of data
terminals connected over seven bit serial lines, and to the use of control
characters for various functions not related to printing characters on
the display screen. I do not really understand the reference to
"type-to-filter a menu for things like '...' or ' ' (space)", but
it does not sound to me like "control character" would be the right
description.

Wikipedia has http://en.wikipedia.org/wiki/Control_character which
gives good background. It includes a paragraph about Unicode that
says this:

In Unicode, "Control-characters" are U+0000—U+001F
(C0 controls), U+007F (delete), and U+0080—U+009F
(C1 controls). Their General Category is "Cc". Formatting codes
are distinct, in General Category "Cf". The Cc control characters
have no Name in Unicode, but are given labels such as ""
instead.

So it certainly would be possible to define #isControlCharacter
for Unicode characters, but IMHO it seems to drag along some ancient
concepts of serial data communications that are probably not
meaningful inside a Squeak image.

Another reference is "man 3 isalpha" on Unix/Linux (C89 and Posix).
There are quite a few character testing functions. Most of them
do not exist in Squeak, and I would not be inclined to start adding
any of them without a good reason.

Dave


On Wed, Oct 02, 2019 at 11:05:04PM +0000, Thiede, Christoph wrote:
> Hi,
>
>
> any opinions about this proposal? :-)
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev im Auftrag von Thiede, Christoph
> Gesendet: Donnerstag, 5. September 2019 15:06 Uhr
> An: [hidden email]; [hidden email]
> Betreff: Re: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
>
>
> Personally, I sometimes type-to-filter a menu for things like '...' or ' ' (space). Am I the only one who does this? :)
>
>
> I still would consider something like Character>>#isControlCharacter useful. How about this?
>
>
> Unicode class>>isControlCode: charCode
> ^ (self generalCategoryOf: charCode) <= cs="">
>
> Character>>isControlCharacter
> ^ self encodedCharSet isControlCode: self charCode
>
> Versions for other char sets would have to be added.
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev im Auftrag von [hidden email]
> Gesendet: Donnerstag, 5. September 2019 14:36:59
> An: [hidden email]; [hidden email]
> Betreff: [squeak-dev] The Trunk: Morphic-mt.1514.mcz
>
> Marcel Taeumel uploaded a new version of Morphic to project The Trunk:
> http://source.squeak.org/trunk/Morphic-mt.1514.mcz
>
> ==================== Summary ====================
>
> Name: Morphic-mt.1514
> Author: mt
> Time: 5 September 2019, 2:36:47.777837 pm
> UUID: 49f63b40-72ce-c447-9fb0-9400ea43fab2
> Ancestors: Morphic-mt.1513, Morphic-ct.1501
>
> Merges Morphic-ct.1500. and 1501.
>
> Can't we just filter for #isAlphaNumeric? Do we need parentheses etc.? Would be more readable than ">= 32". I also do not think that #caseOf: helps much in terms of readability. ;-)
>
> =============== Diff against Morphic-mt.1513 ===============
>
> Item was changed:
> ----- Method: MenuMorph>>handleFiltering: (in category 'keystroke helpers') -----
> handleFiltering: evt
>
> | matchString |
> matchString := self valueOfProperty: #matchString ifAbsentPut: [ String new ].
> + matchString := true
> + caseOf: {
> + [ evt keyCharacter = Character backspace ] ->
> + [ matchString isEmpty
> + ifTrue: [ matchString ]
> + ifFalse: [ matchString allButLast ] ].
> + [ evt keyValue >= 32 ] ->
> + [ matchString , evt keyCharacter ] }
> + otherwise: [ matchString ].
> - matchString := evt keyValue = 8 " Character backspace asciiValue "
> - ifTrue: [
> - matchString isEmpty
> - ifTrue: [ matchString ]
> - ifFalse: [ matchString allButLast ] ]
> - ifFalse: [
> - matchString copyWith: evt keyCharacter ].
> self setProperty: #matchString toValue: matchString.
> self displayFiltered: evt!
>
>

>