On Mon, Sep 8, 2008 at 6:28 PM, Gary Chambers gazzaguru2@btinternet.com wrote:

UI Enhancements (now known as Polymorph) should load in 3.10. What was the specific problem?

I think UIEnhancements is loaded on 3.10 based images. It's only on Pharo and 3.9 based images that I did not manage to install it.

On Tue, Sep 9, 2008 at 9:05 AM, laurent laffont laurent.laffont@gmail.com wrote:

Hi,

I try to run all unit tests for squeak 3.9 web image. Testing stops and I have a message from Algernon to press Ctrl R. I've done it but testing do not continue. Have you managed to run all the tests ?

I don't try to run the tests on the images. This is your job :-D. Ask Algernon developer.

On Wed, Sep 10, 2008 at 11:10 AM, Igor Stasenko siguctua@gmail.com wrote:

2008/9/10 Damien Cassou damien.cassou@gmail.com:

...

Hi,

since 3.10 based images contained NiceFonts which causes some problems, I released 2 new images without NiceFonts: sq3.10.2-7179dev08.09.2.zip and sq3.10.2-7179web08.09.2.zip (notice the .2 at the end which means it's the second release of September). Moreover, NiceFonts seems to slow down the image.

http://damien.cassou.free.fr/squeak-dev.html

What do you want me to do for future dev images? Do you want me to include or exclude this buggy NiceFonts?

How buggy thing can be considered nice? I suggest simply to wait until it become nice, without a 'buggy' adjective :)

I think a more realistic question is: "what is the bug threshold to accept a package in dev images?" :-)

On Wed, Sep 10, 2008 at 11:25 AM, Adrian Lienhard adi@netstyle.ch wrote:

On Sep 10, 2008, at 10:30 , Damien Cassou wrote:

...

Hi,

since 3.10 based images contained NiceFonts which causes some problems, I released 2 new images without NiceFonts: sq3.10.2-7179dev08.09.2.zip and sq3.10.2-7179web08.09.2.zip (notice the .2 at the end which means it's the second release of September). Moreover, NiceFonts seems to slow down the image.

http://damien.cassou.free.fr/squeak-dev.html

What do you want me to do for future dev images? Do you want me to include or exclude this buggy NiceFonts?

Answering also with a rhetoric question: who wants something buggy?

I wonder how NiceFonts can slow down the image because its just another strike font. It would certainly help if you report this to the author with some more details. I think NiceFonts can work, but it has to be done properly (e.g., you need to import italics, else the result is not good).

I already reported some problems to Juan. He didn't want to fix one of them: the problem with the Tools flap displaying unreadable captions. If you could provide a package which works well, I would certainly include it.

El 9/10/08 10:48 AM, "Juan Vuletich" juan@jvuletich.org escribió:

...

I already reported some problems to Juan. He didn't want to fix one of them: the problem with the Tools flap displaying unreadable captions. If you could provide a package which works well, I would certainly include it.

Damien, I don't think it is fair to say that the problem in the Tools flap means NiceFonts is buggy. This is an excerpt from a mail I sent you about this issue on 7/29:

Juan , keep good work on Morphic 3.0. Don't waste you time with nonsense.

Damien, please look longs reports on Mantis , mainly by Jerome, some by Ralph and some from me about the chaotic state of Fonts , StrikeFonts and TTFFonts, before pointing finger to working people.

Edgar

Edgar J. De Cleene wrote:

El 9/10/08 10:48 AM, "Juan Vuletich" juan@jvuletich.org escribió:

...

...

I already reported some problems to Juan. He didn't want to fix one of them: the problem with the Tools flap displaying unreadable captions. If you could provide a package which works well, I would certainly include it.

Damien, I don't think it is fair to say that the problem in the Tools flap means NiceFonts is buggy. This is an excerpt from a mail I sent you about this issue on 7/29:

Juan , keep good work on Morphic 3.0. Don't waste you time with nonsense.

Thanks, Edgar. I will try.

Cheers, Juan Vuletich

Damien, please look longs reports on Mantis , mainly by Jerome, some by Ralph and some from me about the chaotic state of Fonts , StrikeFonts and TTFFonts, before pointing finger to working people.

Edgar

Hi Damien,

Damien Cassou wrote:

On Wed, Sep 10, 2008 at 3:48 PM, Juan Vuletich juan@jvuletich.org wrote:

...

Damien Cassou wrote:

...

On Wed, Sep 10, 2008 at 11:25 AM, Adrian Lienhard adi@netstyle.ch wrote:

...

On Sep 10, 2008, at 10:30 , Damien Cassou wrote:

I already reported some problems to Juan. He didn't want to fix one of them: the problem with the Tools flap displaying unreadable captions. If you could provide a package which works well, I would certainly include it.

Damien, I don't think it is fair to say that the problem in the Tools flap means NiceFonts is buggy.

Hi Juan,

you are right, it was not fair. I know that Squeak has different problems and you did your best to make NiceFonts "just work". I apologize. However, there is still a problem with the tools flap and users complain. There is also a problem with composite window managers on Linux which prevent Squeak from being used on such systems and it seems to be related to the installation of NiceFonts (I haven't checked that).

I'm glad we agree. Thank you.

More about the flaps below.

WRT composite window managers on Linux, it seems I need to make sure the alpha channel is set to 1.0. I'll do it. I'll need help with testing it, though.

...

[...] Also, I don't think it is fair to complain of me not wanting to fix it. I'm not the maintainer of Flaps! The bug is there! If there is no maintainer of Flaps, or nobody wants to fix it, just use a 1bpp StrikeFont or perhaps a TTFont for #standardEToysFont (see options 1 and 2 in quoted text). BTW, keep in mind that NiceFonts does not preclude the use of either 1bpp StrikeFonts, TTFonts, or any other font that might be present in the image.

I don't understand anything about these problems and solutions. Someone else has to do it :-(.

Then I wasn't clear enough and I apologize. The script you use to load NiceFonts code sets some default fonts in Squeak to use NiceFonts. Where you do something like

Preferences setDefaultFonts: #( (setSystemFontTo: 'Vera' 10) (setListFontTo: 'Vera' 10) (setEToysFontTo: 'Vera' 10) (setPaintBoxButtonFontTo: 'Vera' 10) (setMenuFontTo: 'Vera' 12) (setBalloonHelpFontTo: 'Vera' 10) (setCodeFontTo: 'Vera' 12) (setButtonFontTo: 'Vera' 10))].

just remove the #setEToysFontTo: line. Then, the Etoys font (used for the flaps) will be the same as it was without NiceFonts. It is not a real fix, but a workaround.

An alternative you (or anyone using your images) can do is as follows: 1) Open the World Menu / Appearance / system fonts / eToys font... 2) Select a different font. Either 1 bit or TTFont (i.e. any font but my Vera). 3) Recreate the flaps. I really don't know too much about them, but changing the font for window titles will recreate them: Open the World Menu / Appearance / system fonts / window-title font... select anything but the current one

The real fix would involve the flaps code I said before. I believe not using niceFonts at one place is better than not being able to use them at all.

...

WRT performance issues, please send me a comparison with actual numbers. Rendering 32bpp StrikeFonts should take exactly the same time as rendering TTFonts (the code is almost identical).

I will if I manage to reproduce it but I'm not sure it was due to NiceFonts after all.

Ok.

...

At last, let me state that I will do my best to fix any bugs found in NiceFonts, as I'm already doing. I use it all day long in my image, and it is part of at leas one commercial product now.

Ok, thank you very much. I really apologize.

Thanks. We're cool then!

Cheers, Juan Vuletich

Hi folks,

Unfortunately, the problem is not in the fonts code. There is a bug in Bitblt, rule 28. Rule 28 is supposed to take the minimum value between source and destination. I use it to render 32 bit per pixel fonts. Unfortunately there is a bug in BitBlt. The result values for r, g and b are computed correctly. But the alpha channel is always set at zero (i.e. transparent). Usually the VM / OS ignores the alpha channel of the display. But with composite window managers on Linux, it is honored, and the bug is exposed.

You can try for yourself. Evaluate:

(Display pixelValueAt: 10@10)printStringBase: 16

You'll get something like this '16rFF455286'. The FF at the first byte is alpha. FF means opaque. Now, run the following code, and with the mouse go and paint the top left area of your display. Then do click. Do not clean the garbage on the screen yet.

f := Form extent: 20 @ 20 depth: 32. f fillWithColor: Color red. aBitBlt := BitBlt destForm: Display sourceForm: f fillColor: nil combinationRule: 28 destOrigin: Sensor cursorPoint sourceOrigin: 0 @ 0 extent: f extent clipRect: Display computeBoundingBox. [Sensor anyButtonPressed] whileFalse: [aBitBlt destOrigin: Sensor cursorPoint - (10@10). aBitBlt copyBits].

Now check (f pixelValueAt: 10@10) printStringBase: 16. You'll see that inside form f, the alpha is FF, i.e. opaque again.

Now print (Display pixelValueAt: 10@10) printStringBase: 16. I get '16r450000'. Adding the missing leading zeros, it is '16r00450000'. You can see that Bitblt correctly left the red unchanged and made zero green and blue. Unfortunately, alpha went to zero.

I believe this is a bug. Rule 28 means "take the minimum between source and destination". It could do the same for alpha, or it could leave alpha unchanged. Both would be acceptable behaviors. But setting alpha to zero for no good reason is a bug.

Perhaps there is some bitblt rule that can be used for setting alpha to 255 after rendering text. If someone knows how to do it, it could be a good workaround.

Another workaround is to do Prederences setPreferencesFrom: #((subPixelRenderFonts false)) This will turn off subpixel rendering, using only gray levels for AA. This uses BitBlt rule 34, that does not have this problem.

Cheers, Juan Vuletich

Mariano Martinez Peck wrote:

WRT composite window managers on Linux, it seems I need to make
sure the alpha channel is set to 1.0. I'll do it. I'll need help
with testing it, though.

Just let me know when and how and I will test it as soon as I have time. I was one of those who has that problem.

cheers,

mariano

pd: juan: si me pedis algo, pedimelo en castellano jajaj ;)

---

---

Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.524 / Virus Database: 270.6.6 - Release Date: 8/19/2008 12:00 AM

Bert Freudenberg wrote:

Am 11.09.2008 um 15:39 schrieb Juan Vuletich:

...

Usually the VM / OS ignores the alpha channel of the display. But with composite window managers on Linux, it is honored, and the bug is exposed.

This is a VM problem and has a fix, as already discussed previously:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/130935.ht...

• Bert -

Thanks Bert. I wonder what would need to happen for this fix to be included in the compiled VM's most people use.

Cheers, Juan Vuletich

I have installed Nice Fonts in this new vm and works perfetly. Now I have a question....It put me nice fonts but fonts seems to be too big for me (code fonts, menu fonts...all of them). How can I change this? how can I know which fonts I have currently set for each type (code, menu and so on) ?

many thanks,

mariano

On Thu, Sep 11, 2008 at 11:38 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

Bert: I have done exactly what you said in other mail:

$ svn co http://squeakvm.org/svn/squeak/branches/olpc squeak-vm $ cd squeak-vm/platforms/unix $ make $ sudo make install

... which installs in /usr/local

And works perfect!!!

However, I have a question. In the link I see this VM is under "olpc". Is this correct?

many thanks,

mariano

On Thu, Sep 11, 2008 at 11:02 AM, Juan Vuletich juan@jvuletich.orgwrote:

...

Bert Freudenberg wrote:

...

Am 11.09.2008 um 15:39 schrieb Juan Vuletich:

Usually the VM / OS ignores the alpha channel of the display. But with

...

composite window managers on Linux, it is honored, and the bug is exposed.

This is a VM problem and has a fix, as already discussed previously:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/130935.ht...

• Bert -

Thanks Bert. I wonder what would need to happen for this fix to be included in the compiled VM's most people use.

Cheers, Juan Vuletich

Am 12.09.2008 um 04:38 schrieb Mariano Martinez Peck:

Bert: I have done exactly what you said in other mail:

$ svn co http://squeakvm.org/svn/squeak/branches/olpc squeak-vm $ cd squeak-vm/platforms/unix $ make $ sudo make install

... which installs in /usr/local

And works perfect!!!

However, I have a question. In the link I see this VM is under "olpc". Is this correct?

Yes. The OLPC "XO" laptop is a regular Linux machine so that VM works fine on any Linux. There is only one OLPC-specific change in there, the rest is bug fixes and improvements. All of this will be merged back to the main VM when time permits.

- Bert -

many thanks,

mariano

On Thu, Sep 11, 2008 at 11:02 AM, Juan Vuletich juan@jvuletich.org wrote: Bert Freudenberg wrote: Am 11.09.2008 um 15:39 schrieb Juan Vuletich:

Usually the VM / OS ignores the alpha channel of the display. But with composite window managers on Linux, it is honored, and the bug is exposed.

This is a VM problem and has a fix, as already discussed previously:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/130935.ht...

• Bert -

Thanks Bert. I wonder what would need to happen for this fix to be included in the compiled VM's most people use.

Cheers, Juan Vuletich

On Thu, Sep 11, 2008 at 3:39 PM, Juan Vuletich juan@jvuletich.org wrote:

Another workaround is to do Prederences setPreferencesFrom: #((subPixelRenderFonts false)) This will turn off subpixel rendering, using only gray levels for AA. This uses BitBlt rule 34, that does not have this problem.

Thanks for the report. Do you recommend me to do that on all dev images? What are the cons?

On Wed, Sep 10, 2008 at 9:14 PM, Juan Vuletich juan@jvuletich.org wrote:

Then I wasn't clear enough and I apologize. The script you use to load NiceFonts code sets some default fonts in Squeak to use NiceFonts. Where you do something like

Preferences setDefaultFonts: #( (setSystemFontTo: 'Vera' 10) (setListFontTo: 'Vera' 10) (setEToysFontTo: 'Vera' 10) (setPaintBoxButtonFontTo: 'Vera' 10) (setMenuFontTo: 'Vera' 12) (setBalloonHelpFontTo: 'Vera' 10) (setCodeFontTo: 'Vera' 12) (setButtonFontTo: 'Vera' 10))].

just remove the #setEToysFontTo: line. Then, the Etoys font (used for the flaps) will be the same as it was without NiceFonts. It is not a real fix, but a workaround.

I will try that, thank you.