Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Title bar bug on trunk

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

40 messages Options

Ian Trudel-2

[squeak-dev] Title bar bug on trunk

Hello all,

I have attached a screenshot on Squeak 3.11.3 (beta) VM with 3.10.2
trunk image and latest updates as of today. The font in the title bar
is too big causing the window to overflow and having the resize border
controls inside the title bar (see red arrows pointing the problem).
While it should probably be fixed, I would also like to suggest font
size in the title bar being one pt size less than what's actually
available.

A supplementary note in the "About this image" window in regard to MIT
license would be a good idea. Better to repeat this as often as
necessary, as long as we have not agreed on something specific to make
sure contributions are under this license.

Regards,
Ian.
--
http://mecenia.blogspot.com/

TitleBar.png (97K) Download Attachment

Andreas.Raab

[squeak-dev] Re: Title bar bug on trunk

Ian Trudel wrote:
> I have attached a screenshot on Squeak 3.11.3 (beta) VM with 3.10.2
> trunk image and latest updates as of today. The font in the title bar
> is too big causing the window to overflow and having the resize border
> controls inside the title bar (see red arrows pointing the problem).

Yeah, I've seen that too. I don't know what's causing it - dare to dig
into it and try to find out more?

> While it should probably be fixed, I would also like to suggest font
> size in the title bar being one pt size less than what's actually
> available.

This is mostly a memory issue. The new fonts are memory intensive so we
need to be careful about how many of those we include.

> A supplementary note in the "About this image" window in regard to MIT
> license would be a good idea. Better to repeat this as often as
> necessary, as long as we have not agreed on something specific to make
> sure contributions are under this license.

Good idea. Why don't you change it, and push the proposed verbage into
the inbox?

Cheers,
- Andreas

Ian Trudel-2

Re: [squeak-dev] Re: Title bar bug on trunk

2009/8/15 Andreas Raab <[hidden email]>:
> Yeah, I've seen that too. I don't know what's causing it - dare to dig into
> it and try to find out more?

Maybe. =)

Another issue but with the trunk. I have tried to update code from the
trunk into my image but there's a proxy error with source.squeak.org
right at this minute, which causes Squeak to freeze for a minute or
two trying to reach the server.

> This is mostly a memory issue. The new fonts are memory intensive so we need
> to be careful about how many of those we include.

Concretely, does it mean we are limited in the font sizes for any
given font loaded into Squeak?

> Good idea. Why don't you change it, and push the proposed verbage into the
> inbox?

I would like to suggest the text from the community process manifesto,
which reads as follow:

In accordance with our goal of joining the Free Software Conservancy,
all code submitted to the repositories must be licensed under the MIT
license.

Editing the workspace doesn't produce a change set nor monticello
recognize the change. I am not exactly sure how to push this change in
a monticello way. If you give me quick instructions, I will be glad to
do it.

> Cheers,
> - Andreas

Regards,
Ian.
--
http://mecenia.blogspot.com/

Andreas.Raab

[squeak-dev] Re: Title bar bug on trunk

Ian Trudel wrote:
> Another issue but with the trunk. I have tried to update code from the
> trunk into my image but there's a proxy error with source.squeak.org
> right at this minute, which causes Squeak to freeze for a minute or
> two trying to reach the server.

It seems to be fine now. Probably just a temporary issue.

>> This is mostly a memory issue. The new fonts are memory intensive so we need
>> to be careful about how many of those we include.
>
> Concretely, does it mean we are limited in the font sizes for any
> given font loaded into Squeak?

It just means we should limit ourselves. We can include more fonts but
each takes a good chunk of memory (depending on point size) so we should
pick them carefully. You might want to ask Juan if he can post a "full"
set of point sizes somewhere that people can load and then we pick the
three most relevant sizes ("small", "regular" and "title" font). The
current set was picked by Juan and it works well for me.

> Editing the workspace doesn't produce a change set nor monticello
> recognize the change. I am not exactly sure how to push this change in
> a monticello way. If you give me quick instructions, I will be glad to
> do it.

One of the weaknesses of Monticello. I'd recommend adding a menu entry
in the help menu (or reusing the "about this system..." entry) to put up
a workspace with the proper text. Then you can construct the text via:

text := 'Here goes the red bold text.!
]style[(14 3 1 4 6)f1,f1cred;,f1,f1b,f1!' readStream nextChunkText.
(Workspace new contents: text) openLabel: 'About this image'.

To create the formatting for the text, simply inspect a workspace and
execute:

String streamContents: [:s| s nextChunkPutWithStyle: model contents].

This should do the trick.

Cheers,
- Andreas

Bert Freudenberg

[squeak-dev] Zero bytes in Multilingual package

On 16.08.2009, at 05:15, Andreas Raab wrote:

> Ian Trudel wrote:
>> Another issue but with the trunk. I have tried to update code from
>> the
>> trunk into my image but there's a proxy error with source.squeak.org
>> right at this minute, which causes Squeak to freeze for a minute or
>> two trying to reach the server.
>
> It seems to be fine now. Probably just a temporary issue.

There were three debuggers open in the squeaksource image when I
looked today. The problem comes from the source server trying to parse
Multilingual-ar.38 and Multilingual-sn.38. It contains sections of
code where each character is stored as a long instead of a byte (that
is, three null bytes and the char code). I've copied the relevant
portion out of the .mcz's source.st, see attachment. If you try to
open a changelist browser on that file, you get the same parse error.

I have no idea how these widened characters made it into the mzc's
source.st file. In particular since this starts in the middle of a
method (and of a class comment). It extends over a few chunks, then
reverts back to a regular encoding. Strange.

JapaneseEnvironment class>>isBreakableAt:in: looks suspicious though
I'm not sure if it is actually broken or not.

I then looked into the trunk's changes file. It has this problem too,
though apparently only in the class comment of LanguageEnvironment.

"LanguageEnvironment comment string asByteArray" contains this:

116 104 114 101 101 32 99 97 110 32 104 97 118 101 32 40 97 110 100 32
100 111 101 115 32 104 97 118 101 41 32 100 105 102 102 101 114 101
110 116 32 101 110 99 111 100 105 110 103 115 46 32 32 83 0 0 0 111 0
0 0 32 0 0 0 119 0 0 0 101 0 0 0 32 0 0 0 110 0 0 0 101 0 0 0 101 0 0
0 100 0 0 0 32 0 0 0 116 0 0 0 111 0 0 0 32 0 0 0 109 0 0 0 97 0 0 0
110 0 0 0 97 0 0 0 103 0 0 0 101 0 0 0 32 0 0 0 116 0 0 0 104 0 0 0
101 0 0 0 109 0 0 0 32 0 0 0 115 0 0 0 101 0 0 0 112 0 0 0 97 0 0 0
114 0 0 0 97 0 0 0 116 0 0 0 101 0 0 0 108 0 0 0 121 0 0 0 46 0 0 0 32
0 0 0 32 0 0 0 78 0 0 0 111 0 0 0 116 0 0 0 101 0 0 0 32 0 0 0 116 0 0
0 104 0 0 0 97 0 0 0 116 0 0 0 32 0 0 0 116 0 0 0 104 0 0 0 101 0 0 0
32 0 0 0 101 0 0 0 110 0 0 0 99 0 0 0 111 0 0 0 100 0 0 0 105 0 0 0
110 0 0 0 103 0 0 0 32 0 0 0 105 0 0 0 110 0 0 0 32 0 0 0 97 0 0 0 32
0 0 0 102 0 0 0 105 0 0 0 108 0 0 0 101 0 0 0 32 0 0 0 99 0 0 0 97 0 0
0 110 0 0 0 32 0 0 0 98 0 0 0

Increasingly strange. So I removed the null bytes from the class
comment and published as Multilingual-bf.39. After updating they are
indeed gone from the comment. But looking at the source.st in that mcz
shows the encoding problem again. Bummer.

Something very strange is going on. I'm out of ideas (short of
debugging into the MCZ save process).

- Bert -

BuggyMultilingual-ar.38.st.zip (5K) Download Attachment

Ian Trudel-2

Re: [squeak-dev] Re: Title bar bug on trunk

In reply to this post by Andreas.Raab

2009/8/15 Andreas Raab <[hidden email]>:
> Ian Trudel wrote:
>>
>> Another issue but with the trunk. I have tried to update code from the
>> trunk into my image but there's a proxy error with source.squeak.org
>> right at this minute, which causes Squeak to freeze for a minute or
>> two trying to reach the server.
>
> It seems to be fine now. Probably just a temporary issue.

However, I don't think such issue should entirely freeze Squeak. An
unresponsive UI isn't really the way to go.

>> Concretely, does it mean we are limited in the font sizes for any
>> given font loaded into Squeak?
>
> It just means we should limit ourselves. We can include more fonts but each
> takes a good chunk of memory (depending on point size) so we should pick
> them carefully. You might want to ask Juan if he can post a "full" set of
> point sizes somewhere that people can load and then we pick the three most
> relevant sizes ("small", "regular" and "title" font). The current set was
> picked by Juan and it works well for me.

The current set isn't bad at all, I must admit. The title is just a
point too big in my opinion. The fonts included are listed in World
Menu > Appearance > System fonts > List fonts ? Juan, is it
customizable?

>> Editing the workspace doesn't produce a change set nor monticello
>> recognize the change. I am not exactly sure how to push this change in
>> a monticello way. If you give me quick instructions, I will be glad to
>> do it.
>
> One of the weaknesses of Monticello. I'd recommend adding a menu entry in
> the help menu (or reusing the "about this system..." entry) to put up a
> workspace with the proper text. Then you can construct the text via:
>
> text := 'Here goes the red bold text.!
> ]style[(14 3 1 4 6)f1,f1cred;,f1,f1b,f1!' readStream nextChunkText.
> (Workspace new contents: text) openLabel: 'About this image'.
>
> To create the formatting for the text, simply inspect a workspace and
> execute:
>
> String streamContents: [:s| s nextChunkPutWithStyle: model contents].
>
> This should do the trick.

Now everything seems clear. My first thought was to save an image,
which isn't gonna cut it with Monticello. What you propose is to add a
button to open a new window, rather than providing a trunk image with
the license notice already present. It doesn't feel quite right.
Wouldn't it be possible to save a project and upload it to a
repository? Or, perhaps, we should have a container class to prepare
the trunk image, where a project could be stored.

> Cheers,
> - Andreas

Regards,
Ian.
--
http://mecenia.blogspot.com/

Bert Freudenberg

[squeak-dev] Customizing out-of-box appearance (was Re: Title bar bug on trunk)

On 16.08.2009, at 22:35, Ian Trudel wrote:

> 2009/8/15 Andreas Raab <[hidden email]>:
>> Ian Trudel wrote:
>>>
>>> Editing the workspace doesn't produce a change set nor monticello
>>> recognize the change. I am not exactly sure how to push this
>>> change in
>>> a monticello way. If you give me quick instructions, I will be
>>> glad to
>>> do it.
>>
>> One of the weaknesses of Monticello. I'd recommend adding a menu
>> entry in
>> the help menu (or reusing the "about this system..." entry) to put
>> up a
>> workspace with the proper text. Then you can construct the text via:
>>
>> text := 'Here goes the red bold text.!
>> ]style[(14 3 1 4 6)f1,f1cred;,f1,f1b,f1!' readStream nextChunkText.
>> (Workspace new contents: text) openLabel: 'About this image'.
>>
>> To create the formatting for the text, simply inspect a workspace and
>> execute:
>>
>> String streamContents: [:s| s nextChunkPutWithStyle: model contents].
>>
>> This should do the trick.
>
> Now everything seems clear. My first thought was to save an image,
> which isn't gonna cut it with Monticello. What you propose is to add a
> button to open a new window, rather than providing a trunk image with
> the license notice already present. It doesn't feel quite right.
> Wouldn't it be possible to save a project and upload it to a
> repository? Or, perhaps, we should have a container class to prepare
> the trunk image, where a project could be stored.

Add it to a subclass of ReleaseBuilder. This is run to produce a
release image from a developer image. For example, for the Etoys
release we pre-load a couple of projects, including the project first
visible when starting up an image.

- Bert -

Ian Trudel-2

Re: [squeak-dev] Customizing out-of-box appearance (was Re: Title bar bug on trunk)

2009/8/16 Bert Freudenberg <[hidden email]>:

> On 16.08.2009, at 22:35, Ian Trudel wrote:
>>
>> Now everything seems clear. My first thought was to save an image,
>> which isn't gonna cut it with Monticello. What you propose is to add a
>> button to open a new window, rather than providing a trunk image with
>> the license notice already present. It doesn't feel quite right.
>> Wouldn't it be possible to save a project and upload it to a
>> repository? Or, perhaps, we should have a container class to prepare
>> the trunk image, where a project could be stored.
>
>
> Add it to a subclass of ReleaseBuilder. This is run to produce a release
> image from a developer image. For example, for the Etoys release we pre-load
> a couple of projects, including the project first visible when starting up
> an image.
>
> - Bert -

Bert,

I like the idea. Is it currently used to produce the trunk image? To
use it, it's necessary to execute ReleaseBuilder new
prepareReleaseImage and that's it?

Ian.

--
http://mecenia.blogspot.com/

Bert Freudenberg

Re: [squeak-dev] Customizing out-of-box appearance (was Re: Title bar bug on trunk)

On 17.08.2009, at 07:57, Ian Trudel wrote:

> 2009/8/16 Bert Freudenberg <[hidden email]>:
>> On 16.08.2009, at 22:35, Ian Trudel wrote:
>>>
>>> Now everything seems clear. My first thought was to save an image,
>>> which isn't gonna cut it with Monticello. What you propose is to
>>> add a
>>> button to open a new window, rather than providing a trunk image
>>> with
>>> the license notice already present. It doesn't feel quite right.
>>> Wouldn't it be possible to save a project and upload it to a
>>> repository? Or, perhaps, we should have a container class to prepare
>>> the trunk image, where a project could be stored.
>>
>>
>> Add it to a subclass of ReleaseBuilder. This is run to produce a
>> release
>> image from a developer image. For example, for the Etoys release we
>> pre-load
>> a couple of projects, including the project first visible when
>> starting up
>> an image.
>>
>> - Bert -
>
> Bert,
>
> I like the idea. Is it currently used to produce the trunk image?

I don't think so, but IMHO we should.

> To use it, it's necessary to execute ReleaseBuilder new
> prepareReleaseImage and that's it?

In principle, yes. In practice you would create a
ReleaseBuilderFor3dot11 subclass (I guess) to put stuff specific to
3.11 there, but common edits would go into the superclass. For the
trunk we might add a ReleaseBuilderTrunk subclass, or re-use the
ReleaseBuilderDeveloper class (this is left-over from the 3.8 /
Squeakland '05 release I think), or indeed use the ReleaseBuilder
class itself ... I'm not sure.

Anyway, to build the OLPC Etoys releases I used these scripts:
http://etoys.laptop.org/src/Content/mkRelease.sh
http://etoys.laptop.org/src/Content/mkRelease.st
That's a very poor man's Bob ;)

- Bert -

Juan Vuletich-4

Re: [squeak-dev] Re: Title bar bug on trunk

In reply to this post by Ian Trudel-2

Ian Trudel wrote:

>> It just means we should limit ourselves. We can include more fonts but each
>> takes a good chunk of memory (depending on point size) so we should pick
>> them carefully. You might want to ask Juan if he can post a "full" set of
>> point sizes somewhere that people can load and then we pick the three most
>> relevant sizes ("small", "regular" and "title" font). The current set was
>> picked by Juan and it works well for me.
>>
>
> The current set isn't bad at all, I must admit. The title is just a
> point too big in my opinion. The fonts included are listed in World
> Menu > Appearance > System fonts > List fonts ? Juan, is it
> customizable?
>
>

Yes it is. I suggest taking a look at Cuis, as it includes several
additional sizes, including 11 (although not in bold). Before preparing
size 11 (with bold, italic and bold italic) and adding it to the trunk,
I'd like to know if people thinks adding another size is worth the space
used. This is because it will take me one or two hours, and I prefer not
spending that time if people thinks it is better not to include it.

If you want to build it yourself, get
http://www.jvuletich.org/Squeak/Misc/BitmapDejaVuSourceData.zip , taka a
look at #installDejaVu and start from there.

Cheers,
Juan Vuletich

Martin Wirblat

Re: [squeak-dev] Re: Title bar bug on trunk

Juan Vuletich wrote:

> Yes it is. I suggest taking a look at Cuis, as it includes several
> additional sizes, including 11 (although not in bold). Before preparing
> size 11 (with bold, italic and bold italic) and adding it to the trunk,
> I'd like to know if people thinks adding another size is worth the space
> used. This is because it will take me one or two hours, and I prefer not
> spending that time if people thinks it is better not to include it.
>

Hi Juan,

the answer to your question whether more sizes of your nice font are
useful depends on their role. If they are thought to become the main
fonts in Squeak, then many more sizes are not only useful, they are
*necessary*. I have of course the bigger sizes in mind, at least up to
24 pixels. Declaring 9 pixels height as a standard coding font for
everyone is *unhealthy*.

For the many people here who do not understand the effect of small fonts
on computer screens: The world's epidemic spread of shortsightedness has
-among other things- directly to do with them. And it does not need
solely to be your eyes that become affected after many years of
professional work or starting too early with gazing at small computer
screens (XO!). Small fonts may also hit you in your back or cause
another chronic disease, because strong visual concentration leads to
tension elsewhere.

A post of Avi demonstrated this perfectly, perhaps unintentionally. What
is the most striking thing in this story about two young sisters?

http://www.straitstimes.com/Breaking%2BNews/Singapore/Story/STIStory_405695.html

Hint - it is in the picture, of course.

One thing I found comparing fonts from Cuis with Pharo is that
especially the bigger sizes are spaced too narrow - see the attached
image of size 24 (the lower row is from Cuis). I suspect this has to do
with the lack of proper kerning. To me it looks as if at least 3 or
better 4 pixels of additional space would make the font in this case
more readable.

Regards,
Martin

PS: Congratulation to your Cuis work. When it comes to beauty, it
compares to the current Squeak like the brightest day to the darkest
night. Of course, Cuis has also other virtues...

CuisFont24.png (21K) Download Attachment

Gary Chambers-4

Re: [squeak-dev] Re: Title bar bug on trunk

In reply to this post by Ian Trudel-2

Of course, Polymorph fixes the title-bar font/gripper issue. Feel free to
pick the bones out of it.

Regards, Gary

----- Original Message -----
From: "Ian Trudel" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Sunday, August 16, 2009 9:35 PM
Subject: Re: [squeak-dev] Re: Title bar bug on trunk

> 2009/8/15 Andreas Raab <[hidden email]>:
>> Ian Trudel wrote:
>>>
>>> Another issue but with the trunk. I have tried to update code from the
>>> trunk into my image but there's a proxy error with source.squeak.org
>>> right at this minute, which causes Squeak to freeze for a minute or
>>> two trying to reach the server.
>>
>> It seems to be fine now. Probably just a temporary issue.
>
> However, I don't think such issue should entirely freeze Squeak. An
> unresponsive UI isn't really the way to go.
>
>>> Concretely, does it mean we are limited in the font sizes for any
>>> given font loaded into Squeak?
>>
>> It just means we should limit ourselves. We can include more fonts but
>> each
>> takes a good chunk of memory (depending on point size) so we should pick
>> them carefully. You might want to ask Juan if he can post a "full" set of
>> point sizes somewhere that people can load and then we pick the three
>> most
>> relevant sizes ("small", "regular" and "title" font). The current set was
>> picked by Juan and it works well for me.
>
> The current set isn't bad at all, I must admit. The title is just a
> point too big in my opinion. The fonts included are listed in World
> Menu > Appearance > System fonts > List fonts ? Juan, is it
> customizable?
>
>>> Editing the workspace doesn't produce a change set nor monticello
>>> recognize the change. I am not exactly sure how to push this change in
>>> a monticello way. If you give me quick instructions, I will be glad to
>>> do it.
>>
>> One of the weaknesses of Monticello. I'd recommend adding a menu entry in
>> the help menu (or reusing the "about this system..." entry) to put up a
>> workspace with the proper text. Then you can construct the text via:
>>
>> text := 'Here goes the red bold text.!
>> ]style[(14 3 1 4 6)f1,f1cred;,f1,f1b,f1!' readStream nextChunkText.
>> (Workspace new contents: text) openLabel: 'About this image'.
>>
>> To create the formatting for the text, simply inspect a workspace and
>> execute:
>>
>> String streamContents: [:s| s nextChunkPutWithStyle: model contents].
>>
>> This should do the trick.
>
> Now everything seems clear. My first thought was to save an image,
> which isn't gonna cut it with Monticello. What you propose is to add a
> button to open a new window, rather than providing a trunk image with
> the license notice already present. It doesn't feel quite right.
> Wouldn't it be possible to save a project and upload it to a
> repository? Or, perhaps, we should have a container class to prepare
> the trunk image, where a project could be stored.
>
>> Cheers,
>> - Andreas
>
> Regards,
> Ian.
> --
> http://mecenia.blogspot.com/
>

Andreas.Raab

[squeak-dev] Re: Title bar bug on trunk

Gary Chambers wrote:
> Of course, Polymorph fixes the title-bar font/gripper issue. Feel free
> to pick the bones out of it.

How about integrating it instead of picking bones? I have not looked at
Polymorph in detail and someone knowledgeable (i.e., you ;-) would have
to help with it, but it seems like a valuable addition. If we can trade
it, say, for MVC, it shouldn't make much of a difference in size either.

Cheers,
- Andreas

> ----- Original Message ----- From: "Ian Trudel" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Sunday, August 16, 2009 9:35 PM
> Subject: Re: [squeak-dev] Re: Title bar bug on trunk
>
>
>> 2009/8/15 Andreas Raab <[hidden email]>:
>>> Ian Trudel wrote:
>>>>
>>>> Another issue but with the trunk. I have tried to update code from the
>>>> trunk into my image but there's a proxy error with source.squeak.org
>>>> right at this minute, which causes Squeak to freeze for a minute or
>>>> two trying to reach the server.
>>>
>>> It seems to be fine now. Probably just a temporary issue.
>>
>> However, I don't think such issue should entirely freeze Squeak. An
>> unresponsive UI isn't really the way to go.
>>
>>>> Concretely, does it mean we are limited in the font sizes for any
>>>> given font loaded into Squeak?
>>>
>>> It just means we should limit ourselves. We can include more fonts
>>> but each
>>> takes a good chunk of memory (depending on point size) so we should pick
>>> them carefully. You might want to ask Juan if he can post a "full"
>>> set of
>>> point sizes somewhere that people can load and then we pick the three
>>> most
>>> relevant sizes ("small", "regular" and "title" font). The current set
>>> was
>>> picked by Juan and it works well for me.
>>
>> The current set isn't bad at all, I must admit. The title is just a
>> point too big in my opinion. The fonts included are listed in World
>> Menu > Appearance > System fonts > List fonts ? Juan, is it
>> customizable?
>>
>>>> Editing the workspace doesn't produce a change set nor monticello
>>>> recognize the change. I am not exactly sure how to push this change in
>>>> a monticello way. If you give me quick instructions, I will be glad to
>>>> do it.
>>>
>>> One of the weaknesses of Monticello. I'd recommend adding a menu
>>> entry in
>>> the help menu (or reusing the "about this system..." entry) to put up a
>>> workspace with the proper text. Then you can construct the text via:
>>>
>>> text := 'Here goes the red bold text.!
>>> ]style[(14 3 1 4 6)f1,f1cred;,f1,f1b,f1!' readStream nextChunkText.
>>> (Workspace new contents: text) openLabel: 'About this image'.
>>>
>>> To create the formatting for the text, simply inspect a workspace and
>>> execute:
>>>
>>> String streamContents: [:s| s nextChunkPutWithStyle: model contents].
>>>
>>> This should do the trick.
>>
>> Now everything seems clear. My first thought was to save an image,
>> which isn't gonna cut it with Monticello. What you propose is to add a
>> button to open a new window, rather than providing a trunk image with
>> the license notice already present. It doesn't feel quite right.
>> Wouldn't it be possible to save a project and upload it to a
>> repository? Or, perhaps, we should have a container class to prepare
>> the trunk image, where a project could be stored.
>>
>>> Cheers,
>>> - Andreas
>>
>> Regards,
>> Ian.
>> --
>> http://mecenia.blogspot.com/
>>
>
>
>

Gary Chambers-4

Re: [squeak-dev] Re: Title bar bug on trunk

If I get some time it may be possible to factor out the changes. Commercial
pressures drive our work, of course.

How do you mean "trade it, say, for MVC"?

Regards, Gary

----- Original Message -----
From: "Andreas Raab" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Tuesday, August 18, 2009 5:46 PM
Subject: [squeak-dev] Re: Title bar bug on trunk

> Gary Chambers wrote:
>> Of course, Polymorph fixes the title-bar font/gripper issue. Feel free to
>> pick the bones out of it.
>
> How about integrating it instead of picking bones? I have not looked at
> Polymorph in detail and someone knowledgeable (i.e., you ;-) would have to
> help with it, but it seems like a valuable addition. If we can trade it,
> say, for MVC, it shouldn't make much of a difference in size either.
>
> Cheers,
> - Andreas
>
>> ----- Original Message ----- From: "Ian Trudel" <[hidden email]>
>> To: "The general-purpose Squeak developers list"
>> <[hidden email]>
>> Sent: Sunday, August 16, 2009 9:35 PM
>> Subject: Re: [squeak-dev] Re: Title bar bug on trunk
>>
>>
>>> 2009/8/15 Andreas Raab <[hidden email]>:
>>>> Ian Trudel wrote:
>>>>>
>>>>> Another issue but with the trunk. I have tried to update code from the
>>>>> trunk into my image but there's a proxy error with source.squeak.org
>>>>> right at this minute, which causes Squeak to freeze for a minute or
>>>>> two trying to reach the server.
>>>>
>>>> It seems to be fine now. Probably just a temporary issue.
>>>
>>> However, I don't think such issue should entirely freeze Squeak. An
>>> unresponsive UI isn't really the way to go.
>>>
>>>>> Concretely, does it mean we are limited in the font sizes for any
>>>>> given font loaded into Squeak?
>>>>
>>>> It just means we should limit ourselves. We can include more fonts but
>>>> each
>>>> takes a good chunk of memory (depending on point size) so we should
>>>> pick
>>>> them carefully. You might want to ask Juan if he can post a "full" set
>>>> of
>>>> point sizes somewhere that people can load and then we pick the three
>>>> most
>>>> relevant sizes ("small", "regular" and "title" font). The current set
>>>> was
>>>> picked by Juan and it works well for me.
>>>
>>> The current set isn't bad at all, I must admit. The title is just a
>>> point too big in my opinion. The fonts included are listed in World
>>> Menu > Appearance > System fonts > List fonts ? Juan, is it
>>> customizable?
>>>
>>>>> Editing the workspace doesn't produce a change set nor monticello
>>>>> recognize the change. I am not exactly sure how to push this change in
>>>>> a monticello way. If you give me quick instructions, I will be glad to
>>>>> do it.
>>>>
>>>> One of the weaknesses of Monticello. I'd recommend adding a menu entry
>>>> in
>>>> the help menu (or reusing the "about this system..." entry) to put up a
>>>> workspace with the proper text. Then you can construct the text via:
>>>>
>>>> text := 'Here goes the red bold text.!
>>>> ]style[(14 3 1 4 6)f1,f1cred;,f1,f1b,f1!' readStream nextChunkText.
>>>> (Workspace new contents: text) openLabel: 'About this image'.
>>>>
>>>> To create the formatting for the text, simply inspect a workspace and
>>>> execute:
>>>>
>>>> String streamContents: [:s| s nextChunkPutWithStyle: model contents].
>>>>
>>>> This should do the trick.
>>>
>>> Now everything seems clear. My first thought was to save an image,
>>> which isn't gonna cut it with Monticello. What you propose is to add a
>>> button to open a new window, rather than providing a trunk image with
>>> the license notice already present. It doesn't feel quite right.
>>> Wouldn't it be possible to save a project and upload it to a
>>> repository? Or, perhaps, we should have a container class to prepare
>>> the trunk image, where a project could be stored.
>>>
>>>> Cheers,
>>>> - Andreas
>>>
>>> Regards,
>>> Ian.
>>> --
>>> http://mecenia.blogspot.com/
>>>
>>
>>
>>
>
>

Andreas.Raab

[squeak-dev] Re: Title bar bug on trunk

Gary Chambers wrote:
> If I get some time it may be possible to factor out the changes.
> Commercial pressures drive our work, of course.

Obviously.

> How do you mean "trade it, say, for MVC"?

Unload one, load the other instead.

Cheers,
- Andreas

> ----- Original Message ----- From: "Andreas Raab" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Tuesday, August 18, 2009 5:46 PM
> Subject: [squeak-dev] Re: Title bar bug on trunk
>
>
>> Gary Chambers wrote:
>>> Of course, Polymorph fixes the title-bar font/gripper issue. Feel
>>> free to pick the bones out of it.
>>
>> How about integrating it instead of picking bones? I have not looked
>> at Polymorph in detail and someone knowledgeable (i.e., you ;-) would
>> have to help with it, but it seems like a valuable addition. If we can
>> trade it, say, for MVC, it shouldn't make much of a difference in size
>> either.
>>
>> Cheers,
>> - Andreas
>>
>>> ----- Original Message ----- From: "Ian Trudel" <[hidden email]>
>>> To: "The general-purpose Squeak developers list"
>>> <[hidden email]>
>>> Sent: Sunday, August 16, 2009 9:35 PM
>>> Subject: Re: [squeak-dev] Re: Title bar bug on trunk
>>>
>>>
>>>> 2009/8/15 Andreas Raab <[hidden email]>:
>>>>> Ian Trudel wrote:
>>>>>>
>>>>>> Another issue but with the trunk. I have tried to update code from
>>>>>> the
>>>>>> trunk into my image but there's a proxy error with source.squeak.org
>>>>>> right at this minute, which causes Squeak to freeze for a minute or
>>>>>> two trying to reach the server.
>>>>>
>>>>> It seems to be fine now. Probably just a temporary issue.
>>>>
>>>> However, I don't think such issue should entirely freeze Squeak. An
>>>> unresponsive UI isn't really the way to go.
>>>>
>>>>>> Concretely, does it mean we are limited in the font sizes for any
>>>>>> given font loaded into Squeak?
>>>>>
>>>>> It just means we should limit ourselves. We can include more fonts
>>>>> but each
>>>>> takes a good chunk of memory (depending on point size) so we should
>>>>> pick
>>>>> them carefully. You might want to ask Juan if he can post a "full"
>>>>> set of
>>>>> point sizes somewhere that people can load and then we pick the
>>>>> three most
>>>>> relevant sizes ("small", "regular" and "title" font). The current
>>>>> set was
>>>>> picked by Juan and it works well for me.
>>>>
>>>> The current set isn't bad at all, I must admit. The title is just a
>>>> point too big in my opinion. The fonts included are listed in World
>>>> Menu > Appearance > System fonts > List fonts ? Juan, is it
>>>> customizable?
>>>>
>>>>>> Editing the workspace doesn't produce a change set nor monticello
>>>>>> recognize the change. I am not exactly sure how to push this
>>>>>> change in
>>>>>> a monticello way. If you give me quick instructions, I will be
>>>>>> glad to
>>>>>> do it.
>>>>>
>>>>> One of the weaknesses of Monticello. I'd recommend adding a menu
>>>>> entry in
>>>>> the help menu (or reusing the "about this system..." entry) to put
>>>>> up a
>>>>> workspace with the proper text. Then you can construct the text via:
>>>>>
>>>>> text := 'Here goes the red bold text.!
>>>>> ]style[(14 3 1 4 6)f1,f1cred;,f1,f1b,f1!' readStream nextChunkText.
>>>>> (Workspace new contents: text) openLabel: 'About this image'.
>>>>>
>>>>> To create the formatting for the text, simply inspect a workspace and
>>>>> execute:
>>>>>
>>>>> String streamContents: [:s| s nextChunkPutWithStyle: model contents].
>>>>>
>>>>> This should do the trick.
>>>>
>>>> Now everything seems clear. My first thought was to save an image,
>>>> which isn't gonna cut it with Monticello. What you propose is to add a
>>>> button to open a new window, rather than providing a trunk image with
>>>> the license notice already present. It doesn't feel quite right.
>>>> Wouldn't it be possible to save a project and upload it to a
>>>> repository? Or, perhaps, we should have a container class to prepare
>>>> the trunk image, where a project could be stored.
>>>>
>>>>> Cheers,
>>>>> - Andreas
>>>>
>>>> Regards,
>>>> Ian.
>>>> --
>>>> http://mecenia.blogspot.com/
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

Casey Ransberger

Re: [squeak-dev] Re: Title bar bug on trunk

Almost everyone I know who Squeaks uses Polymorph, and I enjoyed the heck out of hacking up the Vista style look to have titlebar buttons arranged in a fashion after OS X:P

One problem that I kept having was, it seemed that the load order and versions of Polymorph & OmniBrowser had to be just right or I'd wind up pretty broken. I saw lots of bugginess, although I *was* rolling my own theme, so the bugs may have been my own.

Do people feel that Polymorph is generally stable enough to go in a base image?

- Ron

On Tue, Aug 18, 2009 at 10:50 AM, Andreas Raab <[hidden email]> wrote:

Gary Chambers wrote:

If I get some time it may be possible to factor out the changes.
Commercial pressures drive our work, of course.

Obviously.

How do you mean "trade it, say, for MVC"?

Unload one, load the other instead.

Cheers,
- Andreas

----- Original Message ----- From: "Andreas Raab" <[hidden email]>
To: "The general-purpose Squeak developers list" <[hidden email]>
Sent: Tuesday, August 18, 2009 5:46 PM
Subject: [squeak-dev] Re: Title bar bug on trunk

Gary Chambers wrote:

Of course, Polymorph fixes the title-bar font/gripper issue. Feel free to pick the bones out of it.

How about integrating it instead of picking bones? I have not looked at Polymorph in detail and someone knowledgeable (i.e., you ;-) would have to help with it, but it seems like a valuable addition. If we can trade it, say, for MVC, it shouldn't make much of a difference in size either.

Cheers,
- Andreas

----- Original Message ----- From: "Ian Trudel" <[hidden email]>
To: "The general-purpose Squeak developers list" <[hidden email]>
Sent: Sunday, August 16, 2009 9:35 PM
Subject: Re: [squeak-dev] Re: Title bar bug on trunk

2009/8/15 Andreas Raab <[hidden email]>:

Ian Trudel wrote:

Another issue but with the trunk. I have tried to update code from the
trunk into my image but there's a proxy error with source.squeak.org
right at this minute, which causes Squeak to freeze for a minute or
two trying to reach the server.

It seems to be fine now. Probably just a temporary issue.

However, I don't think such issue should entirely freeze Squeak. An
unresponsive UI isn't really the way to go.

Concretely, does it mean we are limited in the font sizes for any
given font loaded into Squeak?

It just means we should limit ourselves. We can include more fonts but each
takes a good chunk of memory (depending on point size) so we should pick
them carefully. You might want to ask Juan if he can post a "full" set of
point sizes somewhere that people can load and then we pick the three most
relevant sizes ("small", "regular" and "title" font). The current set was
picked by Juan and it works well for me.

The current set isn't bad at all, I must admit. The title is just a
point too big in my opinion. The fonts included are listed in World
Menu > Appearance > System fonts > List fonts ? Juan, is it
customizable?

Editing the workspace doesn't produce a change set nor monticello
recognize the change. I am not exactly sure how to push this change in
a monticello way. If you give me quick instructions, I will be glad to
do it.

One of the weaknesses of Monticello. I'd recommend adding a menu entry in
the help menu (or reusing the "about this system..." entry) to put up a
workspace with the proper text. Then you can construct the text via:

text := 'Here goes the red bold text.!
]style[(14 3 1 4 6)f1,f1cred;,f1,f1b,f1!' readStream nextChunkText.
(Workspace new contents: text) openLabel: 'About this image'.

To create the formatting for the text, simply inspect a workspace and
execute:

String streamContents: [:s| s nextChunkPutWithStyle: model contents].

This should do the trick.

Now everything seems clear. My first thought was to save an image,
which isn't gonna cut it with Monticello. What you propose is to add a
button to open a new window, rather than providing a trunk image with
the license notice already present. It doesn't feel quite right.
Wouldn't it be possible to save a project and upload it to a
repository? Or, perhaps, we should have a container class to prepare
the trunk image, where a project could be stored.

Cheers,
- Andreas

Regards,
Ian.
--
http://mecenia.blogspot.com/

Andreas.Raab

[squeak-dev] Re: Title bar bug on trunk

Ronald Spengler wrote:

> Almost everyone I know who Squeaks uses Polymorph, and I enjoyed the
> heck out of hacking up the Vista style look to have titlebar buttons
> arranged in a fashion after OS X:P
>
> One problem that I kept having was, it seemed that the load order and
> versions of Polymorph & OmniBrowser had to be just right or I'd wind up
> pretty broken. I saw lots of bugginess, although I *was* rolling my own
> theme, so the bugs may have been my own.
>
> Do people feel that Polymorph is generally stable enough to go in a base
> image?

We have to find out. I was asking earlier but I'll ask again: Which
version would one start with to try Polymorph? From which repository?
I'm in particular interested in finding out more about
extensions/overrides and how to eliminate them to make loading painless
and conflict-free for people.

Cheers,
- Andreas

Juan Vuletich-4

Re: [squeak-dev] Re: Title bar bug on trunk

In reply to this post by Martin Wirblat

Hi Martin,

Martin Wirblat wrote:

> Juan Vuletich wrote:
>
>> Yes it is. I suggest taking a look at Cuis, as it includes several
>> additional sizes, including 11 (although not in bold). Before
>> preparing size 11 (with bold, italic and bold italic) and adding it
>> to the trunk, I'd like to know if people thinks adding another size
>> is worth the space used. This is because it will take me one or two
>> hours, and I prefer not spending that time if people thinks it is
>> better not to include it.
>>
>
> Hi Juan,
>
> the answer to your question whether more sizes of your nice font are
> useful depends on their role. If they are thought to become the main
> fonts in Squeak, then many more sizes are not only useful, they are
> *necessary*. I have of course the bigger sizes in mind, at least up to
> 24 pixels. Declaring 9 pixels height as a standard coding font for
> everyone is *unhealthy*.
>
> For the many people here who do not understand the effect of small
> fonts on computer screens: The world's epidemic spread of
> shortsightedness has -among other things- directly to do with them.
> And it does not need solely to be your eyes that become affected after
> many years of professional work or starting too early with gazing at
> small computer screens (XO!). Small fonts may also hit you in your
> back or cause another chronic disease, because strong visual
> concentration leads to tension elsewhere.
>
> A post of Avi demonstrated this perfectly, perhaps unintentionally.
> What is the most striking thing in this story about two young sisters?
>
> http://www.straitstimes.com/Breaking%2BNews/Singapore/Story/STIStory_405695.html
>
>
> Hint - it is in the picture, of course.

Thanks for your opinion. Does anybody else have one?

>
> One thing I found comparing fonts from Cuis with Pharo is that
> especially the bigger sizes are spaced too narrow - see the attached
> image of size 24 (the lower row is from Cuis). I suspect this has to
> do with the lack of proper kerning. To me it looks as if at least 3 or
> better 4 pixels of additional space would make the font in this case
> more readable.
>

Indeed. I'll add some space for larger sizes. Thanks!

> Regards,
> Martin
>
> PS: Congratulation to your Cuis work. When it comes to beauty, it
> compares to the current Squeak like the brightest day to the darkest
> night. Of course, Cuis has also other virtues...

Thanks.

Cheers,
Juan Vuletich

>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------

Casey Ransberger

Re: [squeak-dev] Re: Title bar bug on trunk

I need bigDisplay for my X-O and my HDTV (I know, maybe I should be ashamed for putting these in the same sentence.)

The X-O actually has a ridiculously high resolution, so the default fonts are unusable on it.

- Ron

On Wed, Aug 19, 2009 at 5:39 AM, Juan Vuletich <[hidden email]> wrote:

Hi Martin,

Martin Wirblat wrote:

Juan Vuletich wrote:

Yes it is. I suggest taking a look at Cuis, as it includes several additional sizes, including 11 (although not in bold). Before preparing size 11 (with bold, italic and bold italic) and adding it to the trunk, I'd like to know if people thinks adding another size is worth the space used. This is because it will take me one or two hours, and I prefer not spending that time if people thinks it is better not to include it.

Hi Juan,

the answer to your question whether more sizes of your nice font are useful depends on their role. If they are thought to become the main fonts in Squeak, then many more sizes are not only useful, they are *necessary*. I have of course the bigger sizes in mind, at least up to 24 pixels. Declaring 9 pixels height as a standard coding font for everyone is *unhealthy*.

For the many people here who do not understand the effect of small fonts on computer screens: The world's epidemic spread of shortsightedness has -among other things- directly to do with them. And it does not need solely to be your eyes that become affected after many years of professional work or starting too early with gazing at small computer screens (XO!). Small fonts may also hit you in your back or cause another chronic disease, because strong visual concentration leads to tension elsewhere.

A post of Avi demonstrated this perfectly, perhaps unintentionally. What is the most striking thing in this story about two young sisters?

http://www.straitstimes.com/Breaking%2BNews/Singapore/Story/STIStory_405695.html

Hint - it is in the picture, of course.

Thanks for your opinion. Does anybody else have one?

One thing I found comparing fonts from Cuis with Pharo is that especially the bigger sizes are spaced too narrow - see the attached image of size 24 (the lower row is from Cuis). I suspect this has to do with the lack of proper kerning. To me it looks as if at least 3 or better 4 pixels of additional space would make the font in this case more readable.

Indeed. I'll add some space for larger sizes. Thanks!

Regards,
Martin

PS: Congratulation to your Cuis work. When it comes to beauty, it compares to the current Squeak like the brightest day to the darkest night. Of course, Cuis has also other virtues...

Thanks.

Cheers,
Juan Vuletich

------------------------------------------------------------------------

------------------------------------------------------------------------

Juan Vuletich-4

Re: [squeak-dev] Re: Title bar bug on trunk

In reply to this post by Martin Wirblat

Hi Martin,

Martin Wirblat wrote:

>
> Hi Juan,
>
> the answer to your question whether more sizes of your nice font are
> useful depends on their role. If they are thought to become the main
> fonts in Squeak, then many more sizes are not only useful, they are
> *necessary*. I have of course the bigger sizes in mind, at least up to
> 24 pixels. Declaring 9 pixels height as a standard coding font for
> everyone is *unhealthy*.
>
> ...
>
> One thing I found comparing fonts from Cuis with Pharo is that
> especially the bigger sizes are spaced too narrow - see the attached
> image of size 24 (the lower row is from Cuis). I suspect this has to
> do with the lack of proper kerning. To me it looks as if at least 3 or
> better 4 pixels of additional space would make the font in this case
> more readable.
>
> Regards,
> Martin

Please check the latest Cuis release (announced minutes ago). It
addresses the issues you raies.

Cheers,
Juan Vuletich