I, personally, hate my code being coloured by some irritating know-it-all process that wants to tell me how that precious token there is a green-thing and that one is blue. No, it ain't. It's black, it's in my chosen font and you damn well leave it alone.
Not to mention is wastes precious CPU time; the difference on my Pi is between unusable tools and ok tools.
So here is a tiny changeset to rip out the nonsense. Some nice person might like to add a proper, friendly, Preference doohickey. I don't care - I got rid of the annoyance.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CEQ: Corrupt and Erase Queue
Hi Tim,
see PluggableTextMorphPlus>>useDefaultStyler "This should be changed to a proper registry but as long as there is only shout this will do" Smalltalk at: #SHTextStylerST80 ifPresent:[:stylerClass| self styler: (stylerClass new view: self). ].
So it looks like the right way to go about this is to unload Shout in the Monticello browser.
On Fri, Feb 22, 2013 at 2:32 PM, tim Rowledge tim@rowledge.org wrote:
I, personally, hate my code being coloured by some irritating know-it-all process that wants to tell me how that precious token there is a green-thing and that one is blue. No, it ain't. It's black, it's in my chosen font and you damn well leave it alone.
Not to mention is wastes precious CPU time; the difference on my Pi is between unusable tools and ok tools.
So here is a tiny changeset to rip out the nonsense. Some nice person might like to add a proper, friendly, Preference doohickey. I don't care - I got rid of the annoyance.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CEQ: Corrupt and Erase Queue
On 22-02-2013, at 2:48 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
see PluggableTextMorphPlus>>useDefaultStyler "This should be changed to a proper registry but as long as there is only shout this will do" Smalltalk at: #SHTextStylerST80 ifPresent:[:stylerClass| self styler: (stylerClass new view: self). ].
So it looks like the right way to go about this is to unload Shout in the Monticello browser.
I have to admit that it would never occur to me that MC could even do such a thing. Makes sense I guess but … you get so habituated to what you're used to that you can totally miss something new.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FLR: Flash Lights Randomly
On 22-02-2013, at 3:36 PM, tim Rowledge tim@rowledge.org wrote:
So it looks like the right way to go about this is to unload Shout in the Monticello browser.
I have to admit that it would never occur to me that MC could even do such a thing. Makes sense I guess but … you get so habituated to what you're used to that you can totally miss something new.
Yup, that seems to have worked ok; a couple of debugger complaints from existing browsers that could just be dismissed and the browsers closed. So much politer.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- HASTE CUISINE - Fast French food
That's always the first change I make to a new image as well.
On 2/22/13 5:32 PM, tim Rowledge wrote:
I, personally, hate my code being coloured by some irritating know-it-all process that wants to tell me how that precious token there is a green-thing and that one is blue. No, it ain't. It's black, it's in my chosen font and you damn well leave it alone.
Not to mention is wastes precious CPU time; the difference on my Pi is between unusable tools and ok tools.
So here is a tiny changeset to rip out the nonsense. Some nice person might like to add a proper, friendly, Preference doohickey. I don't care - I got rid of the annoyance.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CEQ: Corrupt and Erase Queue
On 22-02-2013, at 5:26 PM, Bob Arning arning315@comcast.net wrote:
That's always the first change I make to a new image as well.
Glad I'm not the only monochrome curmudgeon around here
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Talks to plants on their own level.
Wow, I'm surprised -- the human eye discerns color contrast much more easily than patterns. While I don't care for the standard Shout colors, by changing them to be more intuitive and constrasting, particularly for longer methods, the colors _really_ enhance the readability. For example, I'm able to instantly see references to instVars with just a glance because they're gold (dark yellow); or references to self and super because they're bolded, which quickly tells me whether this is a "utility" method. Further, by making comments a light-gray, they are just barely visible, so they're not cluttering the code, but still easily readable if I decide to focus on them for a clarification. Kind of like simply changing eye-focus "reveals" different aspects of the code -- what a powerful "gesture"!..
To each, his own. :)
On Sat, Feb 23, 2013 at 12:08 AM, tim Rowledge tim@rowledge.org wrote:
On 22-02-2013, at 5:26 PM, Bob Arning arning315@comcast.net wrote:
That's always the first change I make to a new image as well.
Glad I'm not the only monochrome curmudgeon around here
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Talks to plants on their own level.
Yes I agree also with the opinion of Chris, I personally hate the monochrome code, but is good that each one can configure / use Squeak as prefer!
2013/2/23 Chris Muller asqueaker@gmail.com:
Wow, I'm surprised -- the human eye discerns color contrast much more easily than patterns. While I don't care for the standard Shout colors, by changing them to be more intuitive and constrasting, particularly for longer methods, the colors _really_ enhance the readability. For example, I'm able to instantly see references to instVars with just a glance because they're gold (dark yellow); or references to self and super because they're bolded, which quickly tells me whether this is a "utility" method. Further, by making comments a light-gray, they are just barely visible, so they're not cluttering the code, but still easily readable if I decide to focus on them for a clarification. Kind of like simply changing eye-focus "reveals" different aspects of the code -- what a powerful "gesture"!..
To each, his own. :)
On Sat, Feb 23, 2013 at 12:08 AM, tim Rowledge tim@rowledge.org wrote:
On 22-02-2013, at 5:26 PM, Bob Arning arning315@comcast.net wrote:
That's always the first change I make to a new image as well.
Glad I'm not the only monochrome curmudgeon around here
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Talks to plants on their own level.
Chris, I'd love to see your do-it to change the Shout colors to ones you find satisfying. A big problem is when you are in the middle of modifying a method. As you type, it does not make sense to Shout, and the next 20 lines turn bright red. That is annoying. I feel like saying, "I'm not done yet. Don't get on my case!". Perhaps if there are more than 2 lines in red after the insertion point, just turn the rest of the method black. That would keep things much calmer. The lack of any other colors would signal that something is not complete.
--Ted.
At 5:36 PM -0600 2/23/13, Chris Muller wrote:
Wow, I'm surprised -- the human eye discerns color contrast much more easily than patterns. While I don't care for the standard Shout colors, by changing them to be more intuitive and constrasting, particularly for longer methods, the colors _really_ enhance the readability. For example, I'm able to instantly see references to instVars with just a glance because they're gold (dark yellow); or references to self and super because they're bolded, which quickly tells me whether this is a "utility" method. Further, by making comments a light-gray, they are just barely visible, so they're not cluttering the code, but still easily readable if I decide to focus on them for a clarification. Kind of like simply changing eye-focus "reveals" different aspects of the code -- what a powerful "gesture"!..
Hi Ted,
Yeah that actually annoys me too. Just because I haven't terminated a statement with a period yet doesn't mean the rest of the code is wrong; grey is probably a better choice than red.
I can't remember how this stuff worked before I gutted it in Cuis, but at least looking at the Cuis version of Theme>>shout (IIRC) and going a couple of methods deep while looking at it might shed some light on how to make this stuff behave better.
Hey while I have you on the line, how is DBJr working out? I'm one of those cats who really misses HyperCard.
Casey
On Feb 23, 2013, at 5:04 PM, Ted Kaehler Ted@vpri.org wrote:
Chris, I'd love to see your do-it to change the Shout colors to ones you find satisfying. A big problem is when you are in the middle of modifying a method. As you type, it does not make sense to Shout, and the next 20 lines turn bright red. That is annoying. I feel like saying, "I'm not done yet. Don't get on my case!". Perhaps if there are more than 2 lines in red after the insertion point, just turn the rest of the method black. That would keep things much calmer. The lack of any other colors would signal that something is not complete.
--Ted.
At 5:36 PM -0600 2/23/13, Chris Muller wrote:
Wow, I'm surprised -- the human eye discerns color contrast much more easily than patterns. While I don't care for the standard Shout colors, by changing them to be more intuitive and constrasting, particularly for longer methods, the colors _really_ enhance the readability. For example, I'm able to instantly see references to instVars with just a glance because they're gold (dark yellow); or references to self and super because they're bolded, which quickly tells me whether this is a "utility" method. Further, by making comments a light-gray, they are just barely visible, so they're not cluttering the code, but still easily readable if I decide to focus on them for a clarification. Kind of like simply changing eye-focus "reveals" different aspects of the code -- what a powerful "gesture"!..
-- Ted Kaehler "400 years of scientific enlightenment are being undone by TV shows on crop circles, ancient astronauts, and haunted buildings." http://www.vpri.org/html/team_bios/kaehler.html
On 2/24/13 5:19 AM, "Casey Ransberger" casey.obrien.r@gmail.com wrote:
I'm one of those cats who really misses HyperCard.
Yes, me too. I sure if Squeak have how to do basic HyperCard the users base grow much.
What is the status of HyperCard anyway ? Any chance of Apple change to open source?
Edgar
On 24.02.2013, at 11:54, "Edgar J. De Cleene" edgardec2005@gmail.com wrote:
On 2/24/13 5:19 AM, "Casey Ransberger" casey.obrien.r@gmail.com wrote:
I'm one of those cats who really misses HyperCard.
Yes, me too. I sure if Squeak have how to do basic HyperCard the users base grow much.
What is the status of HyperCard anyway ? Any chance of Apple change to open source?
Edgar
Apple, no. But this might be interesting:
http://www.kickstarter.com/projects/1755283828/open-source-edition-of-liveco...
- Bert -
On 2/24/13 3:39 PM, "Bert Freudenberg" bert@freudenbergs.de wrote:
On 24.02.2013, at 11:54, "Edgar J. De Cleene" edgardec2005@gmail.com wrote:
On 2/24/13 5:19 AM, "Casey Ransberger" casey.obrien.r@gmail.com wrote:
I'm one of those cats who really misses HyperCard.
Yes, me too. I sure if Squeak have how to do basic HyperCard the users base grow much.
What is the status of HyperCard anyway ? Any chance of Apple change to open source?
Edgar
Apple, no. But this might be interesting:
http://www.kickstarter.com/projects/1755283828/open-source-edition-of-liveco...
- Bert -
Thanks Bert, really is interesting
Edgar
Yes, I saw the videos also, very interesting, but very expensive also :)
2013/2/24 Edgar J. De Cleene edgardec2005@gmail.com:
On 2/24/13 3:39 PM, "Bert Freudenberg" bert@freudenbergs.de wrote:
On 24.02.2013, at 11:54, "Edgar J. De Cleene" edgardec2005@gmail.com wrote:
On 2/24/13 5:19 AM, "Casey Ransberger" casey.obrien.r@gmail.com wrote:
I'm one of those cats who really misses HyperCard.
Yes, me too. I sure if Squeak have how to do basic HyperCard the users base grow much.
What is the status of HyperCard anyway ? Any chance of Apple change to open source?
Edgar
Apple, no. But this might be interesting:
http://www.kickstarter.com/projects/1755283828/open-source-edition-of-liveco...
- Bert -
Thanks Bert, really is interesting
Edgar
Actually RunRev has done a nice Hypercard clone and sold for years. Good to see that they now want to re-engineer it and make it open-source.
BTW VPRI did some work on DynaBook Junior in 2009 http://www.vpri.org/pdf/m2009015_DBjr.pdf
They claim that they can do Hypercard like things with very few classes. It would be nice to have the proof of concept running in a recent Squeak (4.3. or 4.4) and available as open-source as well.
--Hannes
On 2/24/13, Germán Arduino garduino@gmail.com wrote:
Yes, I saw the videos also, very interesting, but very expensive also :)
2013/2/24 Edgar J. De Cleene edgardec2005@gmail.com:
On 2/24/13 3:39 PM, "Bert Freudenberg" bert@freudenbergs.de wrote:
On 24.02.2013, at 11:54, "Edgar J. De Cleene" edgardec2005@gmail.com wrote:
On 2/24/13 5:19 AM, "Casey Ransberger" casey.obrien.r@gmail.com wrote:
I'm one of those cats who really misses HyperCard.
Yes, me too. I sure if Squeak have how to do basic HyperCard the users base grow much.
What is the status of HyperCard anyway ? Any chance of Apple change to open source?
Edgar
Apple, no. But this might be interesting:
http://www.kickstarter.com/projects/1755283828/open-source-edition-of-liveco...
- Bert -
Thanks Bert, really is interesting
Edgar
On 2/24/13, Germán Arduino garduino@gmail.com wrote:
Yes, I saw the videos also, very interesting, but very expensive also :)
Yes, but t seems that they'll make it to open source it
http://www.kickstarter.com/projects/1755283828/open-source-edition-of-liveco...
Nice to see that there could be an open-source edition of a Hypercard type of authoring system.
On the other side I'd like to see something like that in Squeak/Cuis/Pharo as well.
--Hannes
On 2013-02-26, at 16:48, "H. Hirzel" hannes.hirzel@gmail.com wrote:
On the other side I'd like to see something like that in Squeak/Cuis/Pharo as well.
Smalltalk: Live-coding for 40 years.
- Bert -
I'm pretty sure Ted and/or Dan (maybe?) did a Hypercard-alike in Squeak a long time ago. It really can't be a terribly hard thing for someone motivated to do in Morphic these days. We have a variety of useful capabilities to interface with OS facilities and can drop files on windows etc. We can even do multiple host windows now. On Mac and I think Windows we can do host menus.
If you like HyperCard, get on and make it. I bet it would even be possible to read in a lot of original stacks.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: KFP: Kindle Fire in Printer
I've thought about it. Supporting existing stacks would be nice, but I'm honestly more interested in this:
http://www.vpri.org/pdf/m2011001_dbjr_spec.pdf
On Tue, Feb 26, 2013 at 12:45 PM, tim Rowledge tim@rowledge.org wrote:
I'm pretty sure Ted and/or Dan (maybe?) did a Hypercard-alike in Squeak a long time ago. It really can't be a terribly hard thing for someone motivated to do in Morphic these days. We have a variety of useful capabilities to interface with OS facilities and can drop files on windows etc. We can even do multiple host windows now. On Mac and I think Windows we can do host menus.
If you like HyperCard, get on and make it. I bet it would even be possible to read in a lot of original stacks.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: KFP: Kindle Fire in Printer
Thank you Casey for citing a (the?) current reference with the analysis how a HyperCard type of application should be constructed. The question now is: Does this need to be built or is the code available somewhere?
-- Hannes
http://www.vpri.org/pdf/m2011001_dbjr_spec.pdf
DynaBook Junior Specification by Ted Kaehler 14 Jan 2009. (Minor corrections 13 Dec 2010) A specification for DynaBook Junior shown in itself. DBJr is a desktop publishing framework and application builder that is modeled after Apple's HyperCard.
Abstract DynaBook Junior is a desktop publishing framework and application builder that is modeled after Apple's HyperCard(tm). The purpose of this specification is as a starting point for the discovery of an extremely simple way to describe and automatically generate DynaBook Junior. The specification describes stacks, pages, backgrounds, objects embedded in pages, the front-to-back ordering of objects, and page-specific objects. This document is itself a DBJr stack that shows examples of the features it describes. Algorithms for showing a new page, adding pages, adding backgrounds, and adding objects to a page are given in pseudocode.
On 2/27/13, Casey Ransberger casey.obrien.r@gmail.com wrote:
I've thought about it. Supporting existing stacks would be nice, but I'm honestly more interested in this:
http://www.vpri.org/pdf/m2011001_dbjr_spec.pdf
On Tue, Feb 26, 2013 at 12:45 PM, tim Rowledge tim@rowledge.org wrote:
I'm pretty sure Ted and/or Dan (maybe?) did a Hypercard-alike in Squeak a long time ago. It really can't be a terribly hard thing for someone motivated to do in Morphic these days. We have a variety of useful capabilities to interface with OS facilities and can drop files on windows etc. We can even do multiple host windows now. On Mac and I think Windows we can do host menus.
If you like HyperCard, get on and make it. I bet it would even be possible to read in a lot of original stacks.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: KFP: Kindle Fire in Printer
-- Casey Ransberger
While the DynaBookJr (I always misread "DBJr" as "DataBase Jr") is indeed a good modern replacement for HyperCard, isn't the normal BookMorph already available in Squeak a reasonable approximation?
-- Jecel
Chris and Folks, I chose a slightly different path for taming Shout. Here is how to change the colors that Shout uses to put syntax-related colors on code in the browser.
There is a preference called "subduedSyntaxHighlights". It defaults to true, and makes your comment text be blue-green or teal. If you have set it to false, comments in code are bright green. You don't need to change preference.
If comments are blue-green or teal, find the color-setting method by executing: (MessageSet openMessageList: {'SHTextStylerST80 class subduedStyleTable'} name: 'Modify Shout Colors')
If comments are bright green, colors are controlled by this other method. (MessageSet openMessageList: {'SHTextStylerST80 class defaultStyleTable'} name: 'Modify Shout Colors')
The method contains a table that specifies the color for each syntactic element. The table begins:
(default black ) (invalid red ) (excessCode red )
Just change lines 2 and 3 to a less jarring color, such as black.
(default black ) (invalid (red lighter) ) (excessCode black )
Accept and then execute:
SHTextStylerST80 initialize.
Then browse code.
(Note a small confusion. The non-default setting of subduedSyntaxHighlights calls the "default" method, defaultStyleTable. The default setting calls subduedStyleTable.)
--Ted.
On 23-02-2013, at 3:36 PM, Chris Muller asqueaker@gmail.com wrote:
Wow, I'm surprised -- the human eye discerns color contrast much more easily than patterns.
It's possible that is a very personal effect. I suspect it is at least partially a matter of how good your eyesight is, and very likely relates to your experience too; I've been doing this stuff for far too long and have grown very used to reading Smalltalk. I simply don't need advice from a bit of code about which tokens are messages, variables, comments or whatever. The extraneous data actually distracts from the wanted information, acting almost like camouflage.
[snip]
Further, by making comments a light-gray, they are just barely visible, so they're not cluttering the code,
Now I'd tend to prefer almost hiding the code, since it distracts from the explanation. "Don't document the program, programme the document" as an old colleague pointed out.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim 999, the number of the Aussie Beast.
I have that same reaction to ornamentation of browsers. I feel that the more pixels there are around the code, the harder it is to see the code. To me it's a low signal-to-noise ratio.
Cheers, Bob
On 2/24/13 1:31 AM, tim Rowledge wrote:
On 23-02-2013, at 3:36 PM, Chris Mullerasqueaker@gmail.com wrote:
Wow, I'm surprised -- the human eye discerns color contrast much more easily than patterns.
It's possible that is a very personal effect. I suspect it is at least partially a matter of how good your eyesight is, and very likely relates to your experience too; I've been doing this stuff for far too long and have grown very used to reading Smalltalk. I simply don't need advice from a bit of code about which tokens are messages, variables, comments or whatever. The extraneous data actually distracts from the wanted information, acting almost like camouflage.
squeak-dev@lists.squeakfoundation.org