Cuis 3, some beginner questions

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)

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. :-)

Great! I see what I can come up with.

Kindest Regards
Mirko

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:
Thank you!

Will be integrated in next release (although maybe I tweak it a bit).

Cheers,
Juan Vuletich

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:

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 17:46, Juan Vuletich wrote:
Great! My first contribution. :-D
Hopefully you'll see more to follow.

Thanks!

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 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 23.01.2011 06:12, Casey Ransberger wrote:
Yes, makes perfectly sense. Thanks for the explanation.

Mirko Kapps 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

On 25.01.2011 13:57, Juan Vuletich 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

Mirko Kapps wrote:
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: