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@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@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@rowledge.org; http://www.rowledge.org/tim Diagnostics are the programs that run when nothing else will.