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

Luciano Notarfrancesco luchiano at gmail.com
Thu Jun 15 04:53:10 PDT 2023 

Cool, thank you. Just setting the color to ‘Theme current text’ also worked
fine, tho… I did that in the Arrows image I uploaded yesterday before your
fix. Now with this new attribute shout will ignore the printIts and we
don’t need the double quotes anymore?

I’m still having troubles with := and _ not being shown as arrows, leaving
empty lines between fragments of code doesn’t seem to help.

On Thu, 15 Jun 2023 at 01:18 Juan Vuletich <juan at cuis.st> wrote:

> Oh, yes. Well, the solution was to create a new TextAttribute class, named
> ShoutDisable. It seems to work OK and is now at GitHub.
>
> Cheers,
>
>
> On 6/14/2023 1:04 PM, Luciano Notarfrancesco via Cuis-dev wrote:
>
> Juan, actually setting normal emphasis on printIt breaks it, because the
> text looses any subscripts and superscripts that it might have :/ What do
> you think we should do?
>
> On Tue, 6 Jun 2023 at 21:35 Luciano Notarfrancesco <luchiano at gmail.com>
> wrote:
>
>> 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
>>>
>>>
>
> --
> 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/20230615/39225b6a/attachment-0001.htm>

More information about the Cuis-dev mailing list