Hello

The issue of this thread was continued
in http://forum.world.st/The-Inbox-Tools-LM-827-mcz-tp5083799p5083857.html

So let's discuss this further here...

Yes, a group of Squeak pages outlining the issues would be great!

HH

----------------------------------
by Tim Johnson

Aug 29, 2018; 4:46pm Tim Johnson-2 Tim Johnson-2
Hi,

I have seen all the follow-up on this thread, so I understand that the
preference was found and this commit was retracted.  However, I just
want to register myself as someone who uses Workspaces for more than
just code.  I keep TODOs there, notes, and snippets of external data
formats.

I did dig into making a more plaintext-only or styled-text-only
editing space in Squeak a few months back and posted a long
description of my experiences.  The main takeaway (without specifics,
meaning I will probably mis-state in this email) was that it seems
there has been some … cross-pollination (?) … between general-purpose
text editing classes and code-oriented text editing classes over
Squeak’s lifetime.  To me, it looked like a number of code-oriented
extensions were added to non-code-specific classes at one point, and
this seemed to expose different philosophies and open deep questions
on this mailing list.  :)

Anyway, I fear I may be hijacking this thread a bit.  Maybe I should
dig up that old message I wrote and turn it into a Swiki page.

Thanks,
Tim
-------------------------

On 3/27/18, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> Shout wants to be the only mechanism that governs text attributes in a
> (pluggable) text morph. It does not keep track of its own additions or
> anything that has been there before. You cannot even combine two different
> kinds of "Shout stylers" if you would want to. Thus, any manual changes to
> text attributes will be discarded once Shout decides to re-style the text
> contents again. That is why CMD-7 does not work as expected if a text morph
> has a styler and hence Shout styling enabled.
>
> We decided to put all Shout-styling properties into the UI themes because
> code styling is closely related to all other visual properties in the
> system. For example, the code as to look different in "Solarized" than it
> does in "Monokai" or "Default Squeak":
>
>
> If you want to write a tool or application that DOES NOT comply with UI
> themes, you might encounter several barriers at this moment. However, there
> is #canApplyUserInterfaceTheme implemented in Morph to start thinking about
> this challenge. You can set the property #noUserInterfaceTheme to avoid
> UI-theme application. This suggests a bigger refactoring I should approach.
> All calls to #setDefaultParameters might need to happen through
> #applyUserInterfaceTheme, which me might want to guard for Morphs, for
> example. Let me think about that.
>
> Anyway: Managing side effects and state in an image-based object system
> remains challenging. :-)
>
> Best,
> Marcel
> Am 26.03.2018 20:22:36 schrieb tim Rowledge <tim at rowledge.org>:
>
>
>> On 25-03-2018, at 8:52 PM, Chris Muller wrote:
>>
>>> Maybe even per-editor instance preferences. Inherit the global as a
>>> default but allow changing at need. Need a UI to make it useful. Actually
>>> we really need some big improvements to the
>>> prefs/settings/style/font/colour stuff for editors anyway.
>>
>> UserInterfaceTheme in the image does that. We did it in summer of
>> 2016, the color themes work pretty well ever since.
>
> I was thinking more of the UI for changing text styles/font/colours within
> editors etc. Marcel's answer about having properties within the themes that
> could cover these sounds interesting.
>
> I've just noticed an extra bit of complication when thinking about this wrt
> Shout colouring - just try cmd-7 with some selected text in a code view!
> Even in a comment...
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Diagnostics are the programs that run when nothing else will.
>
>
>
>