[Cuis-dev] Fix for VectorCanvas>>#image:at:

Tue Jun 6 12:35:15 PDT 2023

Nice, that’s simpler and more general than setting the color, thanks.

On Tue, 6 Jun 2023 at 21:21 Juan Vuletich <juan at cuis.st> wrote:

> Hi Luciano,
>
> I did a few tweaks. Instead of TextColor dominating any Shout Attribute, I
> made TextStyle normal do that. Additionally, the final $. is added without
> any attribute, so whatever follows it is back to normal. Just pushed it to
> github.
>
> Thanks,
>
>
>
> On 6/6/2023 1:47 PM, Luciano Notarfrancesco via Cuis-dev wrote:
>
> Hi Juan,
> Here are the changes. I've been using it like this for a few days. It's
> very nice that the syntax highlighter doesn't get confused with printIts...
> I like it, and I think I'll continue using it like this, unless we come up
> with other better ideas.
> Still I've been experiencing some problems, sometimes underscores are not
> converted to arrows, and sometimes the syntax highlighter seems to stop
> working. I suspect the color attribute I put might be spreading to the text
> I type into the workspace, but I'm not sure, my workspaces tend to get very
> messy so there might be other reasons.
> (It seems the clock is wrong in my computer, I just noticed the wrong date
> in the change set name, sorry)
>
> On Tue, Jun 6, 2023 at 11:04 PM Juan Vuletich <juan at cuis.st> wrote:
>
>> Did this work well? Would you post your code?
>>
>> Thanks,
>>
>> On 6/2/2023 12:28 PM, Luciano Notarfrancesco via Cuis-dev wrote:
>>
>> Ah, great, I’m trying a mix of both approaches: I enclose it in double
>> quotes and add a dot at the end, and also set the color to the default text
>> color so shout doesn’t color it as a comment. I’ll use it like this for a
>> while and see how it feels, and see if there are still any problems with
>> coloring or underscores.
>>
>> Thanks!
>> Luciano
>>
>> On Fri, 2 Jun 2023 at 16:31 Juan Vuletich <juan at cuis.st> wrote:
>>
>>> My previous answer is completely wrong, because I conflated two issues
>>> you raised.
>>>
>>> Your solution works well to avoid styling the result of a printIt as if
>>> it was Smalltalk code. But it doesn't address the other issue you raised,
>>> that is, after that point, the styling of the rest of the workspace is
>>> messed up.
>>>
>>> My suggestion (modifying #printIt to enclose the result in double
>>> quotes) actually addresses both issues: comments are not styled, and
>>> smalltalk code after them is styled correctly. Maybe we'd push this
>>> instead? Perhaps we'd also tweak the style so it doesn't look like
>>> comments, but the main point is that parsing will be correct afterward. We
>>> could also add a dot after the comment, maybe that makes Shout happier in
>>> case you forgot to type it.
>>>
>>> The real fix would be to shout from scratch after 2 empty lines. That
>>> was the intended behavior some time ago, and it works for coloring but not
>>> for assignment arrows. Fixing this is a bit more complicated. so I'd sugges
>>> opening an issue on GitHub so we don't forget.
>>>
>>> Thanks,
>>>
>>>
>>> On 6/2/2023 11:36 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>>>
>>> Last week I did the change to enclose printIt output in double quotes,
>>> and I used it like that for a couple of days. I didn’t really like it, but
>>> perhaps I’m just not used to it. It colored the printIt output with the
>>> gray color that I use for comments, and for some reason it didn’t feel
>>> right to me.
>>>
>>> Another thing that seems to cause problems with highlighting is my habit
>>> of neglecting to type the last dot in the last sentence, because it’s
>>> optional in Smalltalk and I never type it… but then it confuses the syntax
>>> highlighter, even if I leave several empty lines between fragments of code,
>>> it seems.
>>>
>>> It’s weird that my change doesn’t work for you. I just tried it in the
>>> latest image and it doesn’t seem to work, but it works in my project image
>>> and I can’t figure out why it fails in the stock image. See the attached
>>> change set. I guess it would be more correct to change
>>> TextColor>>dominates: adding "or: [other isForShout and: [self isForShout
>>> not]]", or something like that... but still, why doesn't it work? If some
>>> part of the text has attributes that dominate over shout attributes it
>>> shouldn't change them, right? Is this a bug?
>>>
>>> BTW, I'm not pushing to adopt my change, I don't know yet what's the
>>> best solution.
>>>
>>>
>>> On Fri, 2 Jun 2023 at 15:23 Juan Vuletich <juan at cuis.st> wrote:
>>>
>>>> Please see inline.
>>>>
>>>> On 6/2/2023 10:09 AM, Juan Vuletich via Cuis-dev wrote:
>>>>
>>>> I couldn't get that idea to work. Would you attach a changeset?
>>>>
>>>> In any case, another simple but maybe less comfortable solution is to
>>>> enclose the result in double quotes, making it comment.
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> Of course the above is completely wrong, because I conflated two issues
>>>> you raised.
>>>>
>>>> Your solution works well to avoid styling the result of a printIt as if
>>>> it was Smalltalk code. But it doesn't address the other issue you raised,
>>>> that is, after that point, the styling of the rest of the workspace is
>>>> messed up.
>>>>
>>>> My suggestion (modifying #printIt to enclose the result in double
>>>> quotes) actually addresses both issues: comments are not styled, and
>>>> smalltalk code after them is styled correctly. Maybe we'd push this instead?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> On 6/2/2023 7:23 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>>>>
>>>> Oh, just after sending this email I gave it another try and found a
>>>> simple solution. In SmalltalkEditor>>#printIt I set the color of the output
>>>> text to Theme current text, and I changed TextColor>>dominates: adding “or:
>>>> [other isForShout]”. That’s all :)
>>>>
>>>> On Fri, 2 Jun 2023 at 11:59 Luciano Notarfrancesco <luchiano at gmail.com>
>>>> wrote:
>>>>
>>>>> I’ve been thinking how to prevent the printIt output to be syntax
>>>>> highlighted. I think it’s best to do that because the output is not
>>>>> Smalltalk code, so the syntax highlighter gets it almost always wrong. It
>>>>> could be a preference, or it could be specified in the printOn: methods
>>>>> that know that the output is not Smalltalk code. What do you think? How
>>>>> would you implement it? A new text attribute makes sense to you or do you
>>>>> have any other idea?
>>>>>
>>>>> On Thu, 1 Jun 2023 at 20:53 Luciano Notarfrancesco <luchiano at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Oh, that’s great, using subpixel antialiasing just solved the
>>>>>> problem! Thanks!
>>>>>>
>>>>>> I’ll try NeoEuler. It would be nice to have fallback fonts too… some
>>>>>> math glyphs are missing in DejaVu… but it’s not a big deal. Another minor
>>>>>> aesthetic problem is that the syntax highlighter sometimes gets confused
>>>>>> with the output of printIt, perhaps would be better to not apply syntax
>>>>>> highlighting to the output, or to have the option to “lock” the output text
>>>>>> in some printOn: methods so that the syntax highlighter doesn’t change it
>>>>>> (perhaps a new attribute? not sure if this makes sense). Also sometimes the
>>>>>> underscores are not converted to arrows in a workspace, perhaps this is
>>>>>> related to the syntax highlighter getting confused.
>>>>>>
>>>>>> Thanks!
>>>>>> Luciano
>>>>>>
>>>>>> On Thu, 1 Jun 2023 at 17:42 Juan Vuletich <juan at cuis.st> wrote:
>>>>>>
>>>>>>> Hi Luciano,
>>>>>>>
>>>>>>> On 5/30/2023 9:06 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>>>>>>>
>>>>>>> BTW, in case anyone is curious, here is how matrices look when
>>>>>>> printing them on a workspace with cmd-p. I draw matrices over the binary
>>>>>>> field in a special way (first screenshot), and I scale them down if they
>>>>>>> are too big.
>>>>>>> I did this because it was hard to make matrices look good when
>>>>>>> printing them as text, so instead I draw them on a form and embed the form
>>>>>>> when printing them. I only do this with matrices, they are especially
>>>>>>> problematic when printing because they print with more than one line, they
>>>>>>> are the only objects in my system that need more than one line for
>>>>>>> printing. When I printed them as text with more than one line, printing a
>>>>>>> list of matrices (for example an array of matrices, as in the example where
>>>>>>> I print a basis of a vector space in the screenshots) they would look
>>>>>>> horrible. Now a list of matrices is printed in a single line as expected,
>>>>>>> and the point size of the enclosing parentheses is adjusted automatically
>>>>>>> (I have messages Stream>>#withParentheses:, #withBrackets:,
>>>>>>> #withAngleBrackets:, etc, that do this automatically).
>>>>>>>
>>>>>>>
>>>>>>> It looks beautiful!
>>>>>>>
>>>>>>> I still have two little problems that I might want to tweak:
>>>>>>> 1) the parentheses are too thick, setting the point size is not the
>>>>>>> right thing to do, maybe we need a new text attribute for scaling text
>>>>>>> without changing the point size?;
>>>>>>>
>>>>>>>
>>>>>>> The easiest solution is to use a different font, just for the
>>>>>>> parentheses. For example, NeoEuler parentheses are much lighter at large
>>>>>>> point sizes.
>>>>>>>
>>>>>>> 2) matrices inside matrices loose the transparent background, the
>>>>>>> background becomes black, as you see in the example in the second
>>>>>>> screenshot.
>>>>>>>
>>>>>>>
>>>>>>> I guess this should be fixable. If you can prepare an image with
>>>>>>> such example for me to play with, I'll give it a try. For example (not sure
>>>>>>> if related) VectorEngine can do blending over translucent backgrounds, but
>>>>>>> only if subpixel sampling is used. I know, there is no relation between
>>>>>>> these two features... But I wanted to keep options to a small number, and
>>>>>>> usually we only use cheaper whole pixel AA and cheaper alpha blending that
>>>>>>> can't blend over translucent backgrounds. So, maybe just using the SubPixel
>>>>>>> engine solves this problem, or I'll be happy to take a look.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 30, 2023 at 7:27 PM Luciano Notarfrancesco <
>>>>>>> luchiano at gmail.com> wrote:
>>>>>>>
>>>>>>>> This change set fixes a little bug in VectorCanvas that cames up
>>>>>>>> when using the canvas to draw text with images on a form (outside morphic).
>>>>>>>> I do this to draw matrices, and when drawing a matrix whose coefficients
>>>>>>>> are also matrices this came up. The fix is simply checking that the world
>>>>>>>> is not nil.
>>>>>>>>
>>>>>>>
>>>>>>> Integrated and at GitHub. Thanks!
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> --
>>>>>>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>>>>>>
>>>>>>>
>>>>
>>>> --
>>>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>>>
>>>>
>>>>
>>>> --
>>>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>>>
>>>>
>>>
>>> --
>>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>>
>>>
>>
>> --
>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>
>>
>
> --
> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230606/fdf12ab8/attachment-0001.htm>