<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hi Marcel, hi all,</p>
<p><br>
</p>
<p>I keeping considering this type check as something bad and unexpected. :-)</p>
<p><br>
</p>
<p>First, as I have mentioned earlier, subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example. Second, even a string can be non-trivial, for instance, "<span>String value: 1234", where I only will see a question mark
unless I inspect the result. <span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">
Yes, in the second example, I could also trouble the Compiler again for a new inspect-it, but I just don't see why we should </span><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">restrict</span><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px"> these
useful links for certain types of </span><span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">results. </span>Also, in all situations
where you do some experiments concerning identity, an inspector would be very helpful to track individual instances. Re-evaluating the expression would not be a solution here.</span></p>
<p><span><br>
</span></p>
<p><span>To summarize, I just would not say that any object in Squeak can have a boring structure. It's just the other way around, these clickable results are a great way to make the inspector more visible in the system.</span></p>
<p><span><br>
</span></p>
<p><span>PS: We should also consider making the new links available for print-its in the search bar.</span></p>
<p><span><br>
</span></p>
<p><span>Best,</span></p>
<p><span>Christoph</span></p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von K K Subbu <kksubbu.ml@gmail.com><br>
<b>Gesendet:</b> Montag, 19. April 2021 18:23:22<br>
<b>An:</b> squeak-dev@lists.squeakfoundation.org<br>
<b>Betreff:</b> Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">All,<br>
<br>
How about:<br>
<br>
Object>>isInspectable ^true<br>
ByteString>>isInspectable ^false<br>
Number>>isInspectable ^false<br>
...<br>
<br>
so inspectors can skip unitary objects?<br>
<br>
Just a thought .. Subbu<br>
<br>
On 19/04/21 8:36 pm, Marcel Taeumel wrote:<br>
> Hi Christoph, hi all.<br>
> <br>
> I think that we should not highlight the following kinds of Objects to <br>
> reserve this feature for really interesting structures that are worth <br>
> inspecting without an extra evaluate. The kinds to ignore are:<br>
> <br>
> ByteString<br>
> ByteSymbol<br>
> Number<br>
> Boolean<br>
> UndefinedObject<br>
> <br>
> So, we can use both (1) visuals and (2) interactivity to let the more <br>
> complex objects say: "Hey, I have interesting structure! Did you mix up <br>
> print-it with inspect-it? No worries, just click on me."<br>
> <br>
> This effect will not be if any stoopid literal gets this treatment. :-)<br>
> <br>
> Best,<br>
> Marcel<br>
>><br>
>> Am 19.04.2021 13:21:53 schrieb Thiede, Christoph <br>
>> <christoph.thiede@student.hpi.uni-potsdam.de>:<br>
>><br>
>> Hi Marcel,<br>
>><br>
>><br>
>> I still stumble upon this edge case for some print-it results that do <br>
>> not support click-to-inspect. Why do we need this exception? :-)<br>
>><br>
>><br>
>> > > Also consider this snippet where the print-link does not exist for <br>
>> an MCVersionName<br>
>> ><br>
>> > Looks fine.<br>
>><br>
>> I don't think it looks fine, why do you think so? :-)<br>
>><br>
>> Best,<br>
>> Christoph<br>
>> ------------------------------------------------------------------------<br>
>> *Von:* Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im <br>
>> Auftrag von Taeumel, Marcel<br>
>> *Gesendet:* Freitag, 16. April 2021 19:52:16<br>
>> *An:* squeak-dev<br>
>> *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz<br>
>> Hi Christoph,<br>
>><br>
>> I think that this clickable link is a compromise between printString <br>
>> and storeString. For mouse navigation, you can always choose "inspect <br>
>> it" from the context menu on that text selection. ;-) I also found the <br>
>> link color annyoing for simple literals.<br>
>><br>
>> > Also consider this snippet where the print-link does not exist for <br>
>> an MCVersionName<br>
>><br>
>> Looks fine. ^__^ I am certain that we will collect more feedback on <br>
>> this feature during the next weeks and months. Let's refine it then.<br>
>><br>
>> Best,<br>
>> Marcel<br>
>>><br>
>>> Am 16.04.2021 18:39:10 schrieb Thiede, Christoph <br>
>>> <christoph.thiede@student.hpi.uni-potsdam.de>:<br>
>>><br>
>>> Hi Marcel, it's great that you have found a solution to this idea! :-)<br>
>>><br>
>>><br>
>>> > + ^ (self class interactivePrintIt and: [(anObject isString <br>
>>> or: [anObject isNumber]) not])<br>
>>><br>
>>><br>
>>> Is this necessary? I know that an inspector for a literal object like <br>
>>> these does not make great sense, but this just feels like an <br>
>>> unnecessary heuristic and limitation for me and adds complexity. I <br>
>>> would like to be able to open an inspector always. Also consider this <br>
>>> snippet where the print-link does not exist for an MCVersionName: :-)<br>
>>><br>
>>> MCRepository inbox allFileNames first<br>
>>><br>
>>><br>
>>> > CI scripts will default to "true".<br>
>>><br>
>>><br>
>>> Unfortunately, no, mine just timed out while preparing the image. <br>
>>> Also, my server images for @SqueakSmalltalkBot were interrupted. I'd <br>
>>> opt for keeping preamble/postscript content in the update stream <br>
>>> strictly non-interactive. :-)<br>
>>><br>
>>><br>
>>> Best,<br>
>>><br>
>>> Christoph<br>
>>><br>
>>><br>
>>> ------------------------------------------------------------------------<br>
>>> *Von:* Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im <br>
>>> Auftrag von Taeumel, Marcel<br>
>>> *Gesendet:* Freitag, 16. April 2021 17:27:54<br>
>>> *An:* squeak-dev<br>
>>> *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz<br>
>>> Hi all!<br>
>>><br>
>>> It is now in Trunk. You can opt-out via the preference browser. <br>
>>> Still, you will be asked the first time when you update your image. <br>
>>> CI scripts will default to "true".<br>
>>><br>
>>> Best,<br>
>>> Marcel<br>
>>>><br>
>>>> Am 17.11.2019 17:36:11 schrieb Jakob Reschke <forums.jakob@resfarm.de>:<br>
>>>><br>
>>>> Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de <br>
>>>> <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">mailto:Christoph.Thiede@student.hpi.uni-potsdam.de</a>>> schrieb am
<br>
>>>> Fr., 15. Nov. 2019, 09:38:<br>
>>>><br>
>>>><br>
>>>> Just another idea (I seem to have too many of them :D): Some<br>
>>>> kind of UnderlyingObjectAttribute (with a better name, of<br>
>>>> course) an editor can check the selection before compiling it<br>
>>>> when inspectIt/exploreIt is pressed?<br>
>>>><br>
>>>><br>
>>>> Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor<br>
>>>> checks for UnderylingObjectAttribute -> none found, so the<br>
>>>> string is compilaed as usual.<br>
>>>><br>
>>>> Example 2: (Text string: '2 + 3' attributes:<br>
>>>> (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -><br>
>>>> Editor finds an UnderylingObjectAttribute -> instead of<br>
>>>> compiling the selection, the cached result is reused for<br>
>>>> the inspector.<br>
>>>><br>
>>>> We would not even need to display this Attribute visually if it<br>
>>>> works reliably.<br>
>>>><br>
>>>><br>
>>>> Make sure it is transient in some way because it would be quite <br>
>>>> annoying if the hidden object were out of date with regards to the text.<br>
> <br>
> <br>
<br>
<br>
</div>
</span></font>
</body>
</html>