<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div>Hi Christoph,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_-6028679388545823556m_2313092252327741383gmail-m_2608721486973676289divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><p><span style="font-size:12pt">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.</span><br></p></div></blockquote><div>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. :)</div><div><br></div><div>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..</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="m_-6028679388545823556m_2313092252327741383gmail-m_2608721486973676289divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>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?</p></div></div></blockquote><div><br></div><div>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 </div><div><br></div><div> evt keyValue = 8 " Character backspace asciiValue "</div><div><br></div><div>to </div><div><br></div><div> evt keyCharacter = Character backspace</div><div><br></div><div>I think you should've stuck with your improved pattern for the >=32 check, e.g., </div><div><br></div><div> evt keyCharacter >= Character space</div><div><br></div><div>and maybe a terse comment for why. I certainly wouldn't make a whole new version of Morphic only for that, though.</div><div><br></div><div>Best,</div><div> Chris</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="m_-6028679388545823556m_2313092252327741383gmail-m_2608721486973676289divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="m_-6028679388545823556m_2313092252327741383gmail-m_2608721486973676289Signature">
<div name="divtagdefaultwrapper">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-6028679388545823556m_2313092252327741383gmail-m_2608721486973676289divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>><br>
<b>Gesendet:</b> Montag, 7. Oktober 2019 20:30:42<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] #isControlCharacter (was: The Trunk: Morphic-mt.1514.mcz)</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">On Mon, Oct 7, 2019 at 1:29 AM Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id="m_-6028679388545823556m_2313092252327741383gmail-m_2608721486973676289gmail-m_-3720111812312326324__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">
Menu filtering is so cool! :-) And convenient.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. :-)</div>
</div>
</blockquote>
<div><br>
</div>
<div>-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.</div>
<div><br>
</div>
<div>Menus should be constrained English, with use of #translated for other languages with special characters.</div>
<div><br>
</div>
<div>Best,</div>
<div> Chris</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id="m_-6028679388545823556m_2313092252327741383gmail-m_2608721486973676289gmail-m_-3720111812312326324__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">
<div><br>
</div>
<div>Best,</div>
<div>Marcel</div>
<div></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">
<p style="color:rgb(170,170,170);margin-top:10px">Am 03.10.2019 02:34:40 schrieb David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">My personal event horizon does not extend beyond seven bits, so
<br>
anything that I say about Unicode should not be taken seriously. <br>
However: <br>
<br>
The concept of "isControlCharacter" dates back to the days of data <br>
terminals connected over seven bit serial lines, and to the use of control <br>
characters for various functions not related to printing characters on <br>
the display screen. I do not really understand the reference to <br>
"type-to-filter a menu for things like '...' or ' ' (space)", but <br>
it does not sound to me like "control character" would be the right <br>
description. <br>
<br>
Wikipedia has <a href="http://en.wikipedia.org/wiki/Control_character" target="_blank">
http://en.wikipedia.org/wiki/Control_character</a> which <br>
gives good background. It includes a paragraph about Unicode that <br>
says this: <br>
<br>
In Unicode, "Control-characters" are U+0000—U+001F <br>
(C0 controls), U+007F (delete), and U+0080—U+009F <br>
(C1 controls). Their General Category is "Cc". Formatting codes <br>
are distinct, in General Category "Cf". The Cc control characters <br>
have no Name in Unicode, but are given labels such as "<u></u>" <br>
instead. <br>
<br>
So it certainly would be possible to define #isControlCharacter <br>
for Unicode characters, but IMHO it seems to drag along some ancient <br>
concepts of serial data communications that are probably not <br>
meaningful inside a Squeak image. <br>
<br>
Another reference is "man 3 isalpha" on Unix/Linux (C89 and Posix). <br>
There are quite a few character testing functions. Most of them <br>
do not exist in Squeak, and I would not be inclined to start adding <br>
any of them without a good reason. <br>
<br>
Dave <br>
<br>
<br>
On Wed, Oct 02, 2019 at 11:05:04PM +0000, Thiede, Christoph wrote: <br>
> Hi, <br>
> <br>
> <br>
> any opinions about this proposal? :-) <br>
> <br>
> <br>
> Best, <br>
> <br>
> Christoph <br>
> <br>
> ________________________________ <br>
> Von: Squeak-dev <u></u>im Auftrag von Thiede, Christoph <br>
> Gesendet: Donnerstag, 5. September 2019 15:06 Uhr <br>
> An: <a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a>;
<a href="mailto:packages@lists.squeakfoundation.org" target="_blank">packages@lists.squeakfoundation.org</a>
<br>
> Betreff: Re: [squeak-dev] The Trunk: Morphic-mt.1514.mcz <br>
> <br>
> <br>
> Personally, I sometimes type-to-filter a menu for things like '...' or ' ' (space). Am I the only one who does this? :)
<br>
> <br>
> <br>
> I still would consider something like Character>>#isControlCharacter useful. How about this?
<br>
> <br>
> <br>
> Unicode class>>isControlCode: charCode <br>
> ^ (self generalCategoryOf: charCode) <= cs=""><br>
> <br>
> Character>>isControlCharacter <br>
> ^ self encodedCharSet isControlCode: self charCode <br>
> <br>
> Versions for other char sets would have to be added. <br>
> <br>
> Best, <br>
> Christoph <br>
> ________________________________ <br>
> Von: Squeak-dev <u></u>im Auftrag von <a href="mailto:commits@source.squeak.org" target="_blank">
commits@source.squeak.org</a> <u></u><br>
> Gesendet: Donnerstag, 5. September 2019 14:36:59 <br>
> An: <a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a>;
<a href="mailto:packages@lists.squeakfoundation.org" target="_blank">packages@lists.squeakfoundation.org</a>
<br>
> Betreff: [squeak-dev] The Trunk: Morphic-mt.1514.mcz <br>
> <br>
> Marcel Taeumel uploaded a new version of Morphic to project The Trunk: <br>
> <a href="http://source.squeak.org/trunk/Morphic-mt.1514.mcz" target="_blank">http://source.squeak.org/trunk/Morphic-mt.1514.mcz</a>
<br>
> <br>
> ==================== Summary ==================== <br>
> <br>
> Name: Morphic-mt.1514 <br>
> Author: mt <br>
> Time: 5 September 2019, 2:36:47.777837 pm <br>
> UUID: 49f63b40-72ce-c447-9fb0-9400ea43fab2 <br>
> Ancestors: Morphic-mt.1513, Morphic-ct.1501 <br>
> <br>
> Merges Morphic-ct.1500. and 1501. <br>
> <br>
> 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. ;-)
<br>
> <br>
> =============== Diff against Morphic-mt.1513 =============== <br>
> <br>
> Item was changed: <br>
> ----- Method: MenuMorph>>handleFiltering: (in category 'keystroke helpers') -----
<br>
> handleFiltering: evt <br>
> <br>
> | matchString | <br>
> matchString := self valueOfProperty: #matchString ifAbsentPut: [ String new ]. <br>
> + matchString := true <br>
> + caseOf: { <br>
> + [ evt keyCharacter = Character backspace ] -> <br>
> + [ matchString isEmpty <br>
> + ifTrue: [ matchString ] <br>
> + ifFalse: [ matchString allButLast ] ]. <br>
> + [ evt keyValue >= 32 ] -> <br>
> + [ matchString , evt keyCharacter ] } <br>
> + otherwise: [ matchString ]. <br>
> - matchString := evt keyValue = 8 " Character backspace asciiValue " <br>
> - ifTrue: [ <br>
> - matchString isEmpty <br>
> - ifTrue: [ matchString ] <br>
> - ifFalse: [ matchString allButLast ] ] <br>
> - ifFalse: [ <br>
> - matchString copyWith: evt keyCharacter ]. <br>
> self setProperty: #matchString toValue: matchString. <br>
> self displayFiltered: evt! <br>
> <br>
> <br>
<br>
> <br>
<br>
<br>
<u></u><u></u><u></u><u></u></div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote></div></div>