Hi Juan and all others.
I'm a hobby programmer (mostly Python and Bash) and play around with Squeak from time to time. Since a few days I play around with Cuis 3. I hope that a smaller system will help me to understand Squeak/Smalltalk better and so far I really like it. Great work! :-) I have a few questions/issues/suggestions: 1. I'm neither accustomed to the underscore assignment nor to the arrow, but somehow I like the arrow. However, it is shown for the underscore everywhere. I usually use underscore delimited file names (like "Cuis3.0_Mirko_1.image") and the arrow is shown for the file name too which is a little irritating. Is that intentional and how hard would it be to show the arrow only for assignment in code? 2. The automatic creation of variables in the Workspace doesn't work even though the menu entry for it is there: " gives an 'Unknown variable ...' menu " m := Morph new " gives an annoying 'm appears to be unused ...' menu, which results in another menu whether you say yes or no" [ m ] m := Morph new I often want to instantiate some object to further play with and this is really annoying in my opinion. I found Juan's comment in Workspace>>bindingOf: that says: "I want to have workspace that force the user to declare variables. Still subclasses may want to do something else" I personally don't understand why anybody wants that, but I think if the menu option is there, it should be supported. Is this intentionally, not yet implemented or a bug? And how hard would it be to make it work? If it isn't too hard, I would like to do it myself, so some pointers would be nice (how to submit changes if I really get it working?) 3. The Theme system is cute! But changing the theme resets the background. I think, a theme should only change the background if it explicitly provides one, so Theme>>background shouldn't do anything. Instead, Theme>>beCurrent should do something like "DefaultTheme beCurrent". This would prevent a Theme with no background to change it. What do you say? Thanks for your time and keep up the great work. :-) |
Hi Mirko,
Welcome! Mirko kapps wrote: > Hi Juan and all others. > > > I'm a hobby programmer (mostly Python and Bash) and play around with > Squeak from time to time. Since a few days I play around with Cuis 3. > I hope that a smaller system will help me to understand > Squeak/Smalltalk better and so far I really like it. > > Great work! :-) Thanks. That's one of the main objectives of Cuis. > I have a few questions/issues/suggestions: > > 1. > I'm neither accustomed to the underscore assignment nor to the arrow, > but somehow I like the arrow. However, it is shown for the underscore > everywhere. I usually use underscore delimited file names (like > "Cuis3.0_Mirko_1.image") and the arrow is shown for the file name too > which is a little irritating. Is that intentional and how hard would > it be to show the arrow only for assignment in code? Well, the underscore and the arrow share the same character code. So, Cuis can use just one of them. One way to do what you say would be to use some other character code for the left arrow. But it needs to be one that's easy to type (you'll be typing it a lot). So, if we need to loose some common character, underscore is not a bad choice... What I do is to use $- instead of $_ in file names... What you can do easily in Cuis (and Squeak) is: - Display as underscores (and not arrows) - Make shout display assignments as ':=' even if the source code says underscore - Allow underscores in identifiers (selectors and variable names) > 2. > The automatic creation of variables in the Workspace doesn't work even > though the menu entry for it is there: > > " gives an 'Unknown variable ...' menu " > m := Morph new > > " gives an annoying 'm appears to be unused ...' menu, which results > in another menu whether you say yes or no" > [ m ] > m := Morph new Right. This is a bug. > I often want to instantiate some object to further play with and this > is really annoying in my opinion. I found Juan's comment in > Workspace>>bindingOf: that says: > > "I want to have workspace that force the user to declare > variables. Still subclasses may want to do something else" This is also a bug. It documents obsolete behavior (before the menu entry existed). > I personally don't understand why anybody wants that, but I think if > the menu option is there, it should be supported. Is this > intentionally, not yet implemented or a bug? And how hard would it be > to make it work? If it isn't too hard, I would like to do it myself, > so some pointers would be nice (how to submit changes if I really get > it working?) You can see implementors of #bindingOf: . The bug is that some object is inheriting the version from Object instead of defining its own. You can investigate yourself, it is always fun. In any case, I have already updated the release with the fix. If you want to submit code for Cuis, just email them to me. Sending them to this list is also ok (but please do cc me). The moment we have so much contributors that this is not practical anymore, we'll setup some infrastructure. > 3. > The Theme system is cute! But changing the theme resets the > background. I think, a theme should only change the background if it > explicitly provides one, so Theme>>background shouldn't do anything. > Instead, Theme>>beCurrent should do something like "DefaultTheme > beCurrent". This would prevent a Theme with no background to change > it. What do you say? Yes. Right now, themes don't specify a background but a background color... That's what's set. But you're right. The theme should specify a color, a background, or leave whatever was there. That would be a nice contribution, if you're in the mood for some coding. > Thanks for your time and keep up the great work. :-) Thank you too. Cheers, Juan Vuletich |
On 18.01.2011 14:42, Juan Vuletich wrote:
Thank you very much for the tips and the quick fix! :-) > > What you can do easily in Cuis (and Squeak) is: > - Display as underscores (and not arrows) > - Make shout display assignments as ':=' even if the source code > says underscore > - Allow underscores in identifiers (selectors and variable names) I think what I would really like is to show ":=" as arrow and the underscore unchanged. However, it's just a minor visual irritation and I'm sure I will get used to it quickly. :-) >> The Theme system is cute! But changing the theme resets the >> background. I think, a theme should only change the background if >> it explicitly provides one, so Theme>>background shouldn't do >> anything. Instead, Theme>>beCurrent should do something like >> "DefaultTheme beCurrent". This would prevent a Theme with no >> background to change it. What do you say? > > Yes. Right now, themes don't specify a background but a background > color... That's what's set. But you're right. The theme should > specify a color, a background, or leave whatever was there. That > would be a nice contribution, if you're in the mood for some coding. Great! I see what I can come up with. Kindest Regards Mirko |
In reply to this post by Juan Vuletich-4
Hi Juan.
My original idea of moving all really appearance related things into a DefaultTheme proved to be a little to complex and difficult for me. So, I decided to not mess around with this and just try to fix the background thing. What I came up with is a test whether a Theme defines #background and only then set the background using a new Theme class method #setBackground: . It's more of a hack than a real fix, I think, and it breaks subclassing somewhat. A theme *has* to define #background if it wants to set one, even if just the one from the super class. I personally rather like the behaviour, but decide you if it's OK. The added #setBackground: method has also the nice advantage that it is now really easy to set a background manually. It's just: Theme setBackground: Color blue Theme setBackground: '/home/mirko/Bilder/jungle_maze.jpg' Hope it's of some use. :-) ChangeSet attached. Kindest Regards Mirko |
Mirko Kapps wrote:
> Hi Juan. > > My original idea of moving all really appearance related things into a > DefaultTheme proved to be a little to complex and difficult for me. > So, I decided to not mess around with this and just try to fix the > background thing. What I came up with is a test whether a Theme > defines #background and only then set the background using a new Theme > class method #setBackground: . It's more of a hack than a real fix, I > think, and it breaks subclassing somewhat. A theme *has* to define > #background if it wants to set one, even if just the one from the > super class. I personally rather like the behaviour, but decide you if > it's OK. > > The added #setBackground: method has also the nice advantage that it > is now really easy to set a background manually. It's just: > > Theme setBackground: Color blue > Theme setBackground: '/home/mirko/Bilder/jungle_maze.jpg' > > Hope it's of some use. :-) > > ChangeSet attached. > > Kindest Regards > Mirko Thank you! Will be integrated in next release (although maybe I tweak it a bit). Cheers, Juan Vuletich |
In reply to this post by Mirko kapps
Cool:)
The reason I didn't put background on the default theme: I didn't know how big your display was. I think the default themes should supply a nice set of subtle gradients for the background, personally. This also keeps the image small. That said, backgrounds add a lot of "friendly" and I could be completely wrong here; I'm grateful that Juan added background capabilities to the theme engine. What do other people think? On Jan 22, 2011, at 7:23 AM, Mirko Kapps <[hidden email]> wrote: > Hi Juan. > > My original idea of moving all really appearance related things into a DefaultTheme proved to be a little to complex and difficult for me. So, I decided to not mess around with this and just try to fix the background thing. What I came up with is a test whether a Theme defines #background and only then set the background using a new Theme class method #setBackground: . It's more of a hack than a real fix, I think, and it breaks subclassing somewhat. A theme *has* to define #background if it wants to set one, even if just the one from the super class. I personally rather like the behaviour, but decide you if it's OK. > > The added #setBackground: method has also the nice advantage that it is now really easy to set a background manually. It's just: > > Theme setBackground: Color blue > Theme setBackground: '/home/mirko/Bilder/jungle_maze.jpg' > > Hope it's of some use. :-) > > ChangeSet attached. > > Kindest Regards > Mirko > > <Theme-Background.cs> > |
On 22.01.2011 19:30, Casey Ransberger wrote:
> Cool:) > > The reason I didn't put background on the default theme: I didn't know how big your display was. I think the default themes should supply a nice set of subtle gradients for the background, personally. This also keeps the image small. > > That said, backgrounds add a lot of "friendly" and I could be completely wrong here; I'm grateful that Juan added background capabilities to the theme engine. > > What do other people think? Hi Casey. Thanks for the theming. That's something that a newbie like me can easily start to play with! :-) I too think that the default theme shouldn't have a background image (or at least a small seamless one that can be tilled). I just don't know yet how to do that or how to make a gradient (I currently learn about the Form class) I'm also so brand new to Cuis that I don't know where to stop and not to exaggerate in adding feature (otherwise I had made #setbackground: to accept also an Array, so one can provide a Color or gradient as a fall-back in case the file is missing) |
In reply to this post by Juan Vuletich-4
On 22.01.2011 17:46, Juan Vuletich wrote:
> Mirko Kapps wrote: >> Hi Juan. >> >> My original idea of moving all really appearance related things >> into a DefaultTheme proved to be a little to complex and difficult >> for me. So, I decided to not mess around with this and just try to >> fix the background thing. What I came up with is a test whether a >> Theme defines #background and only then set the background using a >> new Theme class method #setBackground: . It's more of a hack than >> a real fix, I think, and it breaks subclassing somewhat. A theme >> *has* to define #background if it wants to set one, even if just >> the one from the super class. I personally rather like the >> behaviour, but decide you if it's OK. >> >> The added #setBackground: method has also the nice advantage that >> it is now really easy to set a background manually. It's just: >> >> Theme setBackground: Color blue >> Theme setBackground: '/home/mirko/Bilder/jungle_maze.jpg' >> >> Hope it's of some use. :-) >> >> ChangeSet attached. >> >> Kindest Regards >> Mirko > > Thank you! > > Will be integrated in next release (although maybe I tweak it a bit). > > Cheers, > Juan Vuletich > Great! My first contribution. :-D Hopefully you'll see more to follow. Thanks! |
In reply to this post by Mirko kapps
If it was me, I'd probably try to load the image, and handle the error that came back if it's missing with my fallback code.
I always wind up going to google when I need an exception handler in Squeak. I don't need them often enough to remember the idiom, which is odd, coming from other languages. I think it falls out of the uniform object/message protocol, I suppose. If mostly the only error is "I didn't understand that message" and polymorphism is used pervasively, I guess exceptions only happen once in awhile. Is it weird that I'm surprised when exceptions only occur in exceptional circumstances? Anyway if you think an exception handler will give you what you want, I found an example for you here: http://lists.squeakfoundation.org/pipermail/beginners/2008-September/005041.html On Jan 22, 2011, at 10:53 AM, Mirko Kapps <[hidden email]> wrote: > On 22.01.2011 19:30, Casey Ransberger wrote: >> Cool:) >> >> The reason I didn't put background on the default theme: I didn't know how big your display was. I think the default themes should supply a nice set of subtle gradients for the background, personally. This also keeps the image small. >> >> That said, backgrounds add a lot of "friendly" and I could be completely wrong here; I'm grateful that Juan added background capabilities to the theme engine. >> >> What do other people think? > > Hi Casey. > > Thanks for the theming. That's something that a newbie like me can easily start to play with! :-) > > I too think that the default theme shouldn't have a background image (or at least a small seamless one that can be tilled). I just don't know yet how to do that or how to make a gradient (I currently learn about the Form class) > > I'm also so brand new to Cuis that I don't know where to stop and not to exaggerate in adding feature (otherwise I had made #setbackground: to accept also an Array, so one can provide a Color or gradient as a fall-back in case the file is missing) > |
On 22.01.2011 22:09, Casey Ransberger wrote:
> If it was me, I'd probably try to load the image, and handle the error that came back if it's missing with my fallback code. > > I always wind up going to google when I need an exception handler in Squeak. I don't need them often enough to remember the idiom, which is odd, coming from other languages. I think it falls out of the uniform object/message protocol, I suppose. If mostly the only error is "I didn't understand that message" and polymorphism is used pervasively, I guess exceptions only happen once in awhile. > > Is it weird that I'm surprised when exceptions only occur in exceptional circumstances? > > Anyway if you think an exception handler will give you what you want, I found an example for you here: > > http://lists.squeakfoundation.org/pipermail/beginners/2008-September/005041.html Thanks for the link. So if I understand you correctly, working with exception is rather "un-squeaky"? It's quite common in Python, so I have to adjust a little. FWIW, I've played around and now #setBackground: also accepts an Array and even a Form for gradients, though that doesn't work correctly yet, I haven't found out how to create a gradient which resizes if the Cuis window is resized. It now also sets Theme>>background as the fall-back if the file is missing and no alternative is given. Feel free to include/tweak/reject any or all of it. ;-) One question: When the file is not found, I display a note on the Transcript, when I now file out the change, I get a message: Methods in this fileOut have halts or references to the Transcript or other 'slips' in them. Would you like to browse them? - Ignore - Browse slips Why is that? Is displaying such warnings/info on the Transcript a bad thing to do? If yes, what to do instead? Kindest Regards and good night Mirko |
No, exceptions happen all the time, it just seems that I need to deal with them less often than I do in certain other languages.
Far as the Transcript warning goes, that's just to remind you that Transcript show: 'Argh WTF are you nil?' , object. ...doesn't really belong in Etoys:) People use the Transcript a lot to do the equivalent of printf() debugging, and the system likes to remind you that you've left messages to the transcript in your methods. Like any form of logging or console output, the goal is to communicate effectively with the user without being spammy. Make sense? On Jan 22, 2011, at 5:17 PM, Mirko Kapps <[hidden email]> wrote: > On 22.01.2011 22:09, Casey Ransberger wrote: >> If it was me, I'd probably try to load the image, and handle the error that came back if it's missing with my fallback code. >> >> I always wind up going to google when I need an exception handler in Squeak. I don't need them often enough to remember the idiom, which is odd, coming from other languages. I think it falls out of the uniform object/message protocol, I suppose. If mostly the only error is "I didn't understand that message" and polymorphism is used pervasively, I guess exceptions only happen once in awhile. >> >> Is it weird that I'm surprised when exceptions only occur in exceptional circumstances? >> >> Anyway if you think an exception handler will give you what you want, I found an example for you here: >> >> http://lists.squeakfoundation.org/pipermail/beginners/2008-September/005041.html > > Thanks for the link. > > So if I understand you correctly, working with exception is rather "un-squeaky"? It's quite common in Python, so I have to adjust a little. > > FWIW, I've played around and now #setBackground: also accepts an Array and even a Form for gradients, though that doesn't work correctly yet, I haven't found out how to create a gradient which resizes if the Cuis window is resized. > > It now also sets Theme>>background as the fall-back if the file is missing and no alternative is given. > > Feel free to include/tweak/reject any or all of it. ;-) > > > One question: > > When the file is not found, I display a note on the Transcript, when I now file out the change, I get a message: > > Methods in this fileOut have halts or references to the Transcript or other 'slips' in them. Would you like to browse them? > - Ignore > - Browse slips > > Why is that? Is displaying such warnings/info on the Transcript a bad thing to do? If yes, what to do instead? > > > Kindest Regards and good night > Mirko > <setBackground.1.cs> > |
On 23.01.2011 06:12, Casey Ransberger wrote:
> No, exceptions happen all the time, it just seems that I need to deal with them less often than I do in certain other languages. > > Far as the Transcript warning goes, that's just to remind you that > > Transcript show: 'Argh WTF are you nil?' , object. > > ...doesn't really belong in Etoys:) > > People use the Transcript a lot to do the equivalent of printf() debugging, and the system likes to remind you that you've left messages to the transcript in your methods. > > Like any form of logging or console output, the goal is to communicate effectively with the user without being spammy. Make sense? > Yes, makes perfectly sense. Thanks for the explanation. |
In reply to this post by Mirko kapps
Mirko Kapps wrote:
> On 22.01.2011 22:09, Casey Ransberger wrote: >> If it was me, I'd probably try to load the image, and handle the >> error that came back if it's missing with my fallback code. >> >> I always wind up going to google when I need an exception handler in >> Squeak. I don't need them often enough to remember the idiom, which >> is odd, coming from other languages. I think it falls out of the >> uniform object/message protocol, I suppose. If mostly the only error >> is "I didn't understand that message" and polymorphism is used >> pervasively, I guess exceptions only happen once in awhile. >> >> Is it weird that I'm surprised when exceptions only occur in >> exceptional circumstances? >> >> Anyway if you think an exception handler will give you what you want, >> I found an example for you here: >> >> http://lists.squeakfoundation.org/pipermail/beginners/2008-September/005041.html >> > > Thanks for the link. > > So if I understand you correctly, working with exception is rather > "un-squeaky"? It's quite common in Python, so I have to adjust a little. > > FWIW, I've played around and now #setBackground: also accepts an Array > and even a Form for gradients, though that doesn't work correctly yet, > I haven't found out how to create a gradient which resizes if the Cuis > window is resized. > > It now also sets Theme>>background as the fall-back if the file is > missing and no alternative is given. > > Feel free to include/tweak/reject any or all of it. ;-) > > > One question: > > When the file is not found, I display a note on the Transcript, when I > now file out the change, I get a message: > > Methods in this fileOut have halts or references to the Transcript or > other 'slips' in them. Would you like to browse them? > - Ignore > - Browse slips > > Why is that? Is displaying such warnings/info on the Transcript a bad > thing to do? If yes, what to do instead? > > > Kindest Regards and good night > Mirko Hi Folks, I apologize for the delay in answering... I think that Themes specifying a background image is a good thing. What I don't like is dependency on external files. It is better if the Theme can provide the image itself (i.e. the Form) and not a file name. There are many examples in the image on how to do this, as this is how icons and fonts are created. Depending on the kind of image, it might be better to encode it using either jpg or png. Cheers, Juan Vuletich |
On 25.01.2011 13:57, Juan Vuletich wrote:
> > Hi Folks, > > I apologize for the delay in answering... > > I think that Themes specifying a background image is a good thing. > What I don't like is dependency on external files. It is better if > the Theme can provide the image itself (i.e. the Form) and not a > file name. There are many examples in the image on how to do this, > as this is how icons and fonts are created. Depending on the kind of > image, it might be better to encode it using either jpg or png. > > Cheers, > Juan Vuletich Well, the dependency (and possible loading error) was one of the reasons behind my "Color or gradient as fall-back" idea. I /think/ I understand why depending on external files isn't good with an image based system, but OTOH, I also understand Casey's point of keeping the image small. Since my latest version of Theme>>setBackground: actually supports all of this, you could just include Themes which have at most a small image included in the image, but people can still set external files as the background (at least I like to have that). (am I the only one who gets confused with picture image vs. Smalltalk image? ;-) ) If my last #setBackground: version has any chance of inclusion, just tell me what you don't like about it or how it could be advanced/made better and I see if I can do it. :-) Kindest Regards Mirko |
Mirko Kapps wrote:
> > Well, the dependency (and possible loading error) was one of the > reasons behind my "Color or gradient as fall-back" idea. I /think/ I > understand why depending on external files isn't good with an image > based system, but OTOH, I also understand Casey's point of keeping the > image small. > > Since my latest version of Theme>>setBackground: actually supports all > of this, you could just include Themes which have at most a small > image included in the image, but people can still set external files > as the background (at least I like to have that). (am I the only one > who gets confused with picture image vs. Smalltalk image? ;-) ) > > If my last #setBackground: version has any chance of inclusion, just > tell me what you don't like about it or how it could be advanced/made > better and I see if I can do it. :-) > > Kindest Regards > Mirko I suggest moving the method to PasteUpMorph, and exiting with '^self ' instead of '^nil', as it is usual in Smalltalk. Mhhh... There's something else. If you give a Form it is tiled, but if you give a file name, it is stretched... Maybe someone wants to stretch a Form, or tile a file name... Cheers, Juan Vuletich |
Perhaps there are really two methods here?
On Jan 27, 2011, at 5:09 AM, Juan Vuletich <[hidden email]> wrote: > Mirko Kapps wrote: >> >> Well, the dependency (and possible loading error) was one of the reasons behind my "Color or gradient as fall-back" idea. I /think/ I understand why depending on external files isn't good with an image based system, but OTOH, I also understand Casey's point of keeping the image small. >> >> Since my latest version of Theme>>setBackground: actually supports all of this, you could just include Themes which have at most a small image included in the image, but people can still set external files as the background (at least I like to have that). (am I the only one who gets confused with picture image vs. Smalltalk image? ;-) ) >> >> If my last #setBackground: version has any chance of inclusion, just tell me what you don't like about it or how it could be advanced/made better and I see if I can do it. :-) >> >> Kindest Regards >> Mirko > > I suggest moving the method to PasteUpMorph, and exiting with '^self ' instead of '^nil', as it is usual in Smalltalk. > > Mhhh... There's something else. If you give a Form it is tiled, but if you give a file name, it is stretched... Maybe someone wants to stretch a Form, or tile a file name... > > Cheers, > Juan Vuletich > |
Free forum by Nabble | Edit this page |