October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [PROVENANCE INTERNET] Re: default monospaced code font

by Goubier Thierry

Esteban, I'm checking with 2.0 so it may be the reason for the lack of Source Code / Source Sans in my image :) I'll wait for the RPackage update on 3.0 and I also have to clean my settings for 3.0. Thierry Le 17/10/2013 11:40, Esteban Lorenzano a Ã©crit : > > On Oct 17, 2013, at 11:35 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Once the correct fonts are installed, the pdf looks very different :) >> >> Revised judgement: >> >> Source code pro is not bad for a monospaced font. >> Source sans pro is impressive of density (9), and has this additional readability on DejaVu sans for the $l. >> >> I'll take Source Sans Pro, then. >> >> But Pharo is not seeing it in the dialog. Is that because I did a user specific install of the fonts (and not system wide) and Pharo is not checking the user-specific fonts? > yes, that's exactly what happens :) > but also pharo should contain those fonts (it should not need an installation)... currently I'm working on figure out why that does not work. > > Esteban > > >> >> Thierry >> >> Le 17/10/2013 11:11, Goubier Thierry a Ã©crit : >>> I'll do like you because... >>> >>> I only managed to install the source code pro font so far (no default >>> install in ubuntu) and Pharo doesn't see it (LibreOffice does). I'll >>> look for the source sans pro download as well. >>> >>> (May explain the pdf issues if the fonts are not embedded in the pdf >>> document). >>> >>> Thierry >>> >>> Le 17/10/2013 10:57, Igor Stasenko a Ã©crit : >>>> ok i looked at .xlxslsx file >>>> at least, in google preview it looks more or less close to the truth :) >>>> >>>> and i can say that Source Sans Pro is a winner ( to my taste ). >>>> I like that for 'i' in it don't closes together as in 'it', comparing to >>>> dejavu , where it does. >>>> It reads very clear yet compact. >>>> >>>> On 17 October 2013 10:43, Igor Stasenko <siguctua(a)gmail.com >>>> <mailto:siguctua@gmail.com>> wrote: >>>> >>>> >>>> >>>> >>>> On 17 October 2013 10:47, Goubier Thierry <thierry.goubier(a)cea.fr >>>> <mailto:thierry.goubier@cea.fr>> wrote: >>>> >>>> >>>> >>>> Le 17/10/2013 10:29, Igor Stasenko a Ã©crit : >>>> >>>> hmm.. i have suspicion that it is actually adobe who can't >>>> handle the >>>> font properly.. >>>> because in some examples for source code pro font, the >>>> adjacent letters >>>> jump onto each other. >>>> i don't believe it is that bad (see attached)Inline images 1 >>>> >>>> >>>> Adobe or the viewer? I used evince to view it, not acrobat >>>> reader. It may point to incorrect spacing information in Source >>>> Sans Pro (I have not the errors you see in Source Code Pro). >>>> >>>> Who is in charge of the Source Pro font? Which typographer? Oh, >>>> Adobe apparently. If they can't handle it properly... >>>> >>>> i am far from blaming adobe, just wanted to say that in my viewer it >>>> does not shows things >>>> properly, because when rendered in pharo it don't have such problems. >>>> >>>> so i cannot have decent comparison.. >>>> >>>> Thierry >>>> >>>> >>>> >>>> On 17 October 2013 09:28, Goubier Thierry >>>> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr> >>>> <mailto:thierry.goubier@cea.fr >>>> <mailto:thierry.goubier@cea.fr>__>> wrote: >>>> >>>> Excellent, I like the comparison a lot! Thanks! >>>> >>>> My take is: >>>> - Unable to like Source Code Pro 9 (and it's so wide); >>>> - Source Sans Pro 9 has spacing issues (16r, the r is >>>> too close) and >>>> reading issues (it's the worse for the lL|i characters) >>>> - Source sans Pro 10 is better than 9 (but what with >>>> the 2x space?) >>>> >>>> Overall, I'd stay with DejaVu Sans 9 based on this >>>> sample. In my >>>> opinion, the best compromise density / readability. >>>> >>>> Thierry >>>> >>>> Le 16/10/2013 19:56, btc(a)openinworld.com >>>> <mailto:btc@openinworld.com> >>>> <mailto:btc@openinworld.com >>>> <mailto:btc@openinworld.com>> a Ã©crit : >>>> >>>> >>>> Goubier Thierry wrote: >>>> >>>> I'd be more impressed if the argument was >>>> helping me distinguish >>>> between | and l. >>>> >>>> >>>> Yes. It is designed to do that. Some common >>>> failings of >>>> monospaced fonts >>>> are noted [1] and dealt with. There comment section >>>> is also >>>> interesting. >>>> >>>> The attached PDFs are the result of getting the >>>> urge to compare >>>> a broad >>>> coverage of code examples (taken from "Terse Guide >>>> to Squeak") >>>> against >>>> three fonts: >>>> * DejaVu Sans 9 point >>>> * Source Code Pro [1] [2] 9 point >>>> * Source Sans Pro [3] [4] 9 point & 10 point, since >>>> the width of >>>> 10 was >>>> the same as the others at 9. >>>> Also attached is the source excel file. >>>> >>>> cheers -ben >>>> >>>> [1] >>>> >>>> http://blogs.adobe.com/____typblography/2012/09/source-____code-pro.html >>>> >>>> <http://blogs.adobe.com/__typblography/2012/09/source-__code-pro.html> >>>> >>>> >>>> <http://blogs.adobe.com/__typblography/2012/09/source-__code-pro.html >>>> >>>> <http://blogs.adobe.com/typblography/2012/09/source-code-pro.html>> >>>> [2] >>>> >>>> http://sourceforge.net/____projects/sourcecodepro.adobe/____files/ >>>> >>>> <http://sourceforge.net/__projects/sourcecodepro.adobe/__files/> >>>> >>>> >>>> <http://sourceforge.net/__projects/sourcecodepro.adobe/__files/ >>>> <http://sourceforge.net/projects/sourcecodepro.adobe/files/>> >>>> [3] >>>> >>>> http://blogs.adobe.com/____typblography/2012/08/source-____sans-pro.html >>>> >>>> <http://blogs.adobe.com/__typblography/2012/08/source-__sans-pro.html> >>>> >>>> >>>> <http://blogs.adobe.com/__typblography/2012/08/source-__sans-pro.html >>>> >>>> <http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html>> >>>> [4] >>>> >>>> http://sourceforge.net/____projects/sourcesans.adobe/____postdownload?sourc… >>>> >>>> >>>> <http://sourceforge.net/__projects/sourcesans.adobe/__postdownload?source=dlp> >>>> >>>> >>>> >>>> >>>> <http://sourceforge.net/__projects/sourcesans.adobe/__postdownload?source=dlp >>>> >>>> >>>> <http://sourceforge.net/projects/sourcesans.adobe/postdownload?source=dlp>> >>>> >>>> >>>> >>>> I'l let you try, then :) >>>> >>>> Thierry >>>> >>>> >>>> >>>> -- >>>> Thierry Goubier >>>> CEA list >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el >>>> EmbarquÃ©s >>>> 91191 Gif sur Yvette Cedex >>>> France >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>>> -- >>>> Thierry Goubier >>>> CEA list >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>> 91191 Gif sur Yvette Cedex >>>> France >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 17, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Goubier Thierry

Hi Esteban, thanks. This annoucement is very much appreciated, and will help me switch to the new RPackage. Have you changed things in the announcements as well (RPackage created / modified / unregistered?) Thierry Le 17/10/2013 12:20, Esteban Lorenzano a Ã©crit : > Hi, > > I just important an important change in Pharo. > I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. > Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) > I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. > > So, what's the change? > Now 1 RPackage 0 1 MCPackage. > As a result, package granularity is coarse, and then categories for class are stored as package tags. > Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) > This change opens the path to remove old PackageInfo, finally :) > > To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) > And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) > > THERE WILL BE BUGS! > This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! > Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) > > Please, report any issue around. > > Enjoy, > Esteban > > > > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 17, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Esteban Lorenzano

On Oct 17, 2013, at 12:57 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Are you using MorphTreeMorph? yep :) > > Thierry > > Le 17/10/2013 12:46, Esteban Lorenzano a Ã©crit : >> btw, a couple things that I know still doesn't work in Nautilus with trees: >> >> - drag and drop (I failed miserably when trying to implement it, any help here would be welcome :) >> - multiselection in packages >> >> Esteban >> >> >> On Oct 17, 2013, at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> Hi, >>> >>> I just important an important change in Pharo. >>> I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. >>> Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) >>> I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. >>> >>> So, what's the change? >>> Now 1 RPackage 0 1 MCPackage. >>> As a result, package granularity is coarse, and then categories for class are stored as package tags. >>> Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) >>> This change opens the path to remove old PackageInfo, finally :) >>> >>> To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) >>> And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) >>> >>> THERE WILL BE BUGS! >>> This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! >>> Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) >>> >>> Please, report any issue around. >>> >>> Enjoy, >>> Esteban >>> >>> >>> >>> >> >> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Oct. 17, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Esteban Lorenzano

no, they remain the same. I changed the RPackageOrganizer reaction to them, thought... but that shouldn't be a problem, On Oct 17, 2013, at 12:52 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi Esteban, > > thanks. This annoucement is very much appreciated, and will help me switch to the new RPackage. > > Have you changed things in the announcements as well (RPackage created / modified / unregistered?) > > Thierry > > Le 17/10/2013 12:20, Esteban Lorenzano a Ã©crit : >> Hi, >> >> I just important an important change in Pharo. >> I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. >> Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) >> I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. >> >> So, what's the change? >> Now 1 RPackage 0 1 MCPackage. >> As a result, package granularity is coarse, and then categories for class are stored as package tags. >> Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) >> This change opens the path to remove old PackageInfo, finally :) >> >> To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) >> And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) >> >> THERE WILL BE BUGS! >> This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! >> Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) >> >> Please, report any issue around. >> >> Enjoy, >> Esteban >> >> >> >> >> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Oct. 17, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Esteban Lorenzano

btw, a couple things that I know still doesn't work in Nautilus with trees: - drag and drop (I failed miserably when trying to implement it, any help here would be welcome :) - multiselection in packages Esteban On Oct 17, 2013, at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I just important an important change in Pharo. > I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. > Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) > I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. > > So, what's the change? > Now 1 RPackage 0 1 MCPackage. > As a result, package granularity is coarse, and then categories for class are stored as package tags. > Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) > This change opens the path to remove old PackageInfo, finally :) > > To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) > And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) > > THERE WILL BE BUGS! > This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! > Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) > > Please, report any issue around. > > Enjoy, > Esteban > > > >

Oct. 17, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30495 Home: https://github.com/pharo-project/pharo-core

Oct. 17, 2013

IMPORTANT: RPackage behavior changed and Nautilus updated

by Esteban Lorenzano

Hi, I just important an important change in Pharo. I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. So, what's the change? Now 1 RPackage 0 1 MCPackage. As a result, package granularity is coarse, and then categories for class are stored as package tags. Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) This change opens the path to remove old PackageInfo, finally :) To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) THERE WILL BE BUGS! This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) Please, report any issue around. Enjoy, Esteban

Oct. 17, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 3 regressions found. RPackage.Tests.RPackageReadOnlyCompleteSetupTest.testAddTag RPackage.Tests.RPackageReadOnlyCompleteSetupTest.testAddTagNames RPackage.Tests.RPackageSetTest.testPolymorphicWithPackageInfo

Oct. 17, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 3 regressions found. RPackage.Tests.RPackageReadOnlyCompleteSetupTest.testAddTag RPackage.Tests.RPackageReadOnlyCompleteSetupTest.testAddTagNames RPackage.Tests.RPackageSetTest.testPolymorphicWithPackageInfo

Oct. 17, 2013

Re: [Pharo-dev] [PROVENANCE INTERNET] Re: default monospaced code font

by Igor Stasenko

On 17 October 2013 12:02, Henrik Johansen <henrik.s.johansen(a)veloxit.no>wrote: > > On Oct 17, 2013, at 11:40 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > On Oct 17, 2013, at 11:35 AM, Goubier Thierry <thierry.goubier(a)cea.fr> > wrote: > > > >> Once the correct fonts are installed, the pdf looks very different :) > >> > >> Revised judgement: > >> > >> Source code pro is not bad for a monospaced font. > >> Source sans pro is impressive of density (9), and has this additional > readability on DejaVu sans for the $l. > >> > >> I'll take Source Sans Pro, then. > >> > >> But Pharo is not seeing it in the dialog. Is that because I did a user > specific install of the fonts (and not system wide) and Pharo is not > checking the user-specific fonts? > > yes, that's exactly what happens :) > > but also pharo should contain those fonts (it should not need an > installation)... currently I'm working on figure out why that does not work. > > > > Esteban > > I noticed display of fallback-fonts is broken for StrikeFonts now, (select > Bitmap Deja Vu and any non-western language (or French) to have the > palindrome preview X out) I guess that's not a big issue if the plan for > 3.0 is embedding true type/freetype fonts in the image and removing > StrikeFonts altogether though. > > there will be a single fallback raster font (single resolution, to not take much space), for the cases when freetype unavail. > Cheers, > Henry > -- Best regards, Igor Stasenko.

Oct. 17, 2013