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