February 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Feb. 2, 2015

[pharo-project/pharo-core] 37b675: 40471

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 37b6758aec6761a97d981bdc8ee5408d47d79139 https://github.com/pharo-project/pharo-core/commit/37b6758aec6761a97d981bdc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-02 (Mon, 02 Feb 2015) Changed paths: M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/actions/addRequiredPackage.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/README.md A Nautilus-Tests.package/PackageTreeNautilusTest.class/definition.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/running/tearDown.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenOnMethod.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/removeClasses.st M Nautilus.package/Nautilus.class/class/opening/openOnMethod_inEnvironment_.st M NautilusRefactoring.package/NautilusRefactoring.class/class/menu/sourceCodeRefactoringMenuHolder_.st R NautilusRefactoring.package/NautilusRefactoring.class/class/menu/sourceCodeRefactoringMenu_.st A NautilusRefactoring.package/NautilusRefactoring.class/class/menu/sourceCodeRefactoringSubMenu_.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/class/removeClasses_.st A NautilusRefactoring.package/NautilusRefactoring.class/instance/private-class/classRemovalRefactoringObjectFor_.st R NautilusRefactoring.package/NautilusRefactoring.class/instance/private-class/privateRemoveClassesFor_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script471.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40471.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tool-Base.package/AbstractTool.class/instance/class/basicRemoveClass_.st A Tool-Base.package/AbstractTool.class/instance/class/removeClassMessageFor_.st M Tool-Base.package/AbstractTool.class/instance/class/removeClass_.st A Tool-Base.package/AbstractTool.class/instance/class/removeClassesMessageFor_.st M Tool-Base.package/AbstractTool.class/instance/class/removeClasses_.st A Tool-Base.package/AbstractTool.class/instance/class/removedClassHasSubclassesMessageFor_.st Log Message: ----------- 40471 14667 PackageTreeNautilus openOnMethod: not refreshing correctly https://pharo.fogbugz.com/f/cases/14667 14848 "Add required package" in Monticello should use the SearchFacade https://pharo.fogbugz.com/f/cases/14848 14842 cleaning removeClass https://pharo.fogbugz.com/f/cases/14842 14837 Code pane context menu shows superfluous items when inside class NautilusRefactoring https://pharo.fogbugz.com/f/cases/14837 http://files.pharo.org/image/40/40471.zip

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Nicolai Hess

2015-02-02 11:23 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > On Mon, Feb 2, 2015 at 8:06 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Ok, the best I could do: >> >> Sadly, it only works because I changed the default lcd_filter from cairo. >> in cairo 1.7. was a public API for the lcd_filter. >> since 1.8 this API is private again (the code for the different filter >> settings is still there). >> > > > In trying to learn some background info, this found article [1] seems > good, from which I learn: > > * Freely scalable it must be free from character drift. > > I guess this is what we want ? > > * Three main types of font rendering: > > * Hinting trades accuracy for consistency, and as a consequence of > this, hinted text _accumulates character drift_ with hinted glyphs, often > possessing different metrics to their un-hinted counterparts. > > So I guess we don't use hinting, which implies not freely scalable ? > > * Anti-aliasing results in output which is accurate but blurred, > trading contrast for consistency and accuracy. > > * Sub-pixel-rendering exploits the physical geometry of LCD screens to > increase the horizontal resolution of the device. Needs to be filtered to > avoid color fringing and is incompatible with aggressive hinting strategies. > Yes, in the freetypeplugin settings, you can switch between Monitortype LCD and CRT > > * Sub-pixel-positioning is a generalisation of anti-aliasing and/or > sub-pixel-rendering to allow for more accurate glyph placement, and is > incompatible with aggressive hinting strategies. > Yes, in the freetypeplugin settings, you can change the hinting style Light/Normal/Full. With Full-Hinting there is no subpixelantialising anymore. Similiar options are available for cairo/freetype. The settings for Monitortype and hinting have an influence on the rendering in the freetype library *and* the postprocessing that is done in pharos FreeTypePlugin. The same for FreeType and Cairo > > That article [1] advises: > > * For sub-pixel-rendering to function correctly it is necessary to > enable the patent encumbered LCD filtering API. Many distributions, > including Debian, do this already and is generally not a problem. > > * Versions of Cairo before the 1.10 release use their own intra-pixel > filter. As of 2009 there are two sets of patches available that update > legacy releases of Cairo to use an FIR inter-pixel filter. The first set > pre-dates the filtering interface in FreeType and uses a custom FIR filter > with the coefficients outlined in Gib98. The second set of patches, by > David Turner, take advantage of the FreeType filtering interface. > > * It is recommended that distributions upgrade to Cairo 1.10 where at > all possible. Here [2] is a post on that. > > So btw, what version of Cario are we using? I see latest is version > 1.12.18. > > [1] https://freddie.witherden.org/pages/font-rasterisation/#spo07 > [2] http://lists.cairographics.org/archives/cairo/2010-January/018859.html > > > > >> You can choose between >> FT_LCD_FILTER_NONE >> FT_LCD_FILTER_LEGACY >> FT_LCD_FILTER_LIGHT >> FT_LCD_FILTER_DEFAULT >> >> the default is FT_LCD_FILTER_LEGACY >> but for this (so far, the best) result I used >> FT_LCD_FILTER_DEFAULT >> But there is no public API for this function anymore, so I had to >> change the code. >> >> >> We have to discuss how we proceed. >> >> The problems: >> font rendering looks ugly ( at least for small font size like for menus, >> lists and codepanes) >> font rendering looks different on windows and linux >> >> possible solutions: >> change build options for Freetype on Windos (enable >> FT_CONFIG_OPTION_SUBPIXEL_RENDERING, potential patent infringement?) >> change default filter (patching cairo source) >> >> or we leave everything as it is. >> I do not know, and I'm starting to lose all interest. >> >> >> nicolai >> >> >> >> 2015-02-01 19:38 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> **** patents! >>> >>> Hours, and days digging in the code for font rendering with cairo. >>> I tried to find out why this "colored" subpixel antialising is not >>> working although >>> all option settings are set (in cairo) and in the source code of cairo >>> the FT_SetLCDFilter >>> call is really used! But the output does is just the same as with >>> CAIRO_ANTIALIAS_GRAY, >>> >>> ... until I found THIS in the freetype config: >>> >>> /* Uncomment the line below if you want to activate sub-pixel rendering */ >>> /* (a.k.a. LCD rendering, or ClearType) in this build of the library. */ >>> /* */ >>> /* Note that this feature is covered by several Microsoft patents */ >>> /* and should not be activated in any default build of the library. */ >>> /* */ >>> /* This macro has no impact on the FreeType API, only on its */ >>> /* _implementation_. For example, using FT_RENDER_MODE_LCD when calling */ >>> /* FT_Render_Glyph still generates a bitmap that is 3 times wider than */ >>> /* the original size in case this macro isn't defined; however, each */ >>> /* triplet of subpixels has R=G=B. */ >>> >>> >>> >>> >>> ARGH! >>> >>> It still does not look as good as with the pharos freetypeplugin, but AT >>> LEAST it looks >>> equally on windows and linux , yeh. >>> >>> >>> attached are three screenshots comparing >>> the different athens drawings with the freetypeplugin >>> athens on linux vs ftplugin >>> athens on windows vs ftplugin >>> athens on windows with enabled FT_CONFIG_SUBPIXEL_RENDERING vs ftplugin >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 2015-01-31 10:18 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> >>>> >>>> In athens, there are "hints" you can set. >>>> (CairoFontOptions/hintMetricsOff/hintMetricsOn/hintStyleFull ....) >>>> I played a bit with different settings. Changing this settings change >>>> the output, but I can not get it to look >>>> like with the freetype plugin. I understand that this can not look >>>> equally, because the FreeTypePlugin and caire work differently, >>>> but the athens result looks bad compared with the other one. >>>> >>>> >>>> >>>>> - Pixel fitting. (The aliasing going on at the top of characters) Put >>>>> Hinting: None in FreeType advanced features, and you will probably see >>>>> something similar to the Athens rendering. >>>>> >>>> >>>> Yes, we can change the freetypeplugin setting and cairofontoption >>>> setting to make the output look equally - ugly :) >>>> >>>> >>>> Nicolai >>>> >>>> Igor explained to me that FreeType offers a degenerated mode that when >>>> the font does have the information for bold, kerning,.... >>>> computes a "guessed and approximated" default. Cairo does not offer >>>> this api else Athens would use it. >>>> So what would be interesting is to test using font having all the >>>> information to see if Cairo display well the fonts. >>>> >>>> Stef >>>> >>> >>> >> >

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Igor Stasenko

On 2 February 2015 at 12:31, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2015-02-02 10:46 GMT+01:00 Igor Stasenko <siguctua(a)gmail.com>: > >> >> >> On 2 February 2015 at 01:06, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> Ok, the best I could do: >>> >>> Sadly, it only works because I changed the default lcd_filter from cairo. >>> in cairo 1.7. was a public API for the lcd_filter. >>> since 1.8 this API is private again (the code for the different filter >>> settings is still there). >>> You can choose between >>> FT_LCD_FILTER_NONE >>> FT_LCD_FILTER_LEGACY >>> FT_LCD_FILTER_LIGHT >>> FT_LCD_FILTER_DEFAULT >>> >>> the default is FT_LCD_FILTER_LEGACY >>> but for this (so far, the best) result I used >>> FT_LCD_FILTER_DEFAULT >>> But there is no public API for this function anymore, so I had to >>> change the code. >>> >>> >>> We have to discuss how we proceed. >>> >>> The problems: >>> font rendering looks ugly ( at least for small font size like for menus, >>> lists and codepanes) >>> font rendering looks different on windows and linux >>> >>> possible solutions: >>> change build options for Freetype on Windos (enable >>> FT_CONFIG_OPTION_SUBPIXEL_RENDERING, potential patent infringement?) >>> change default filter (patching cairo source) >>> >>> or we leave everything as it is. >>> I do not know, and I'm starting to lose all interest. >>> >> >> I guess, to understand what happens, best would be to write a small C app, >> that does the rendering.. and see what goes where. >> Something doesn't works there.. but i was unable to figure what or why. >> >> I doubt that changing freetype library build settings is right way to >> deal with issue, >> because >> a) both cairo/freetype used on linux out of the box >> > > But I think freetype on linux has this config enabled (and in fact, the > rendering looks > different on windows and linux until I changed that option for windows) > and I read somewhere, that ubunut(or other distributions?) patched cairo, > just > to get this filter setting api back. > > > >> b) many many apps, using these libs to render with subpixel quality. >> > > This is what drives me crazy, doing text rendering right, is difficult > yes, but this is > the reason why we are using dedicated libraries. > > Then, my guess, making it work on linux would be the first step. Changing build options for building cairo/freetype libs for our VMs is not a big deal then, as long as we will know how to do things properly. > > >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Nicolai Hess

2015-02-02 11:13 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > > On Mon, Feb 2, 2015 at 10:51 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> > On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess(a)web.de> wrote: >> > >> > I do not know, and I'm starting to lose all interest. >> >> Nicolai, >> >> Please don't give up. >> > > Yeah, don't. You rock. > :) Thanks > >> You are doing great work and we are all *very* impressed with your >> attitude/drive/motivation, especially since you are covering such a wide >> range of subjects. I know that the hard thing right now is that you do not >> find enough sparring partners (that goes for others tackling different >> issues as well). > > >> Sven >> > > Phil > > > > > >

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Nicolai Hess

2015-02-02 10:46 GMT+01:00 Igor Stasenko <siguctua(a)gmail.com>: > > > On 2 February 2015 at 01:06, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Ok, the best I could do: >> >> Sadly, it only works because I changed the default lcd_filter from cairo. >> in cairo 1.7. was a public API for the lcd_filter. >> since 1.8 this API is private again (the code for the different filter >> settings is still there). >> You can choose between >> FT_LCD_FILTER_NONE >> FT_LCD_FILTER_LEGACY >> FT_LCD_FILTER_LIGHT >> FT_LCD_FILTER_DEFAULT >> >> the default is FT_LCD_FILTER_LEGACY >> but for this (so far, the best) result I used >> FT_LCD_FILTER_DEFAULT >> But there is no public API for this function anymore, so I had to >> change the code. >> >> >> We have to discuss how we proceed. >> >> The problems: >> font rendering looks ugly ( at least for small font size like for menus, >> lists and codepanes) >> font rendering looks different on windows and linux >> >> possible solutions: >> change build options for Freetype on Windos (enable >> FT_CONFIG_OPTION_SUBPIXEL_RENDERING, potential patent infringement?) >> change default filter (patching cairo source) >> >> or we leave everything as it is. >> I do not know, and I'm starting to lose all interest. >> > > I guess, to understand what happens, best would be to write a small C app, > that does the rendering.. and see what goes where. > Something doesn't works there.. but i was unable to figure what or why. > > I doubt that changing freetype library build settings is right way to deal > with issue, > because > a) both cairo/freetype used on linux out of the box > But I think freetype on linux has this config enabled (and in fact, the rendering looks different on windows and linux until I changed that option for windows) and I read somewhere, that ubunut(or other distributions?) patched cairo, just to get this filter setting api back. > b) many many apps, using these libs to render with subpixel quality. > This is what drives me crazy, doing text rendering right, is difficult yes, but this is the reason why we are using dedicated libraries. > > > -- > Best regards, > Igor Stasenko. >

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Sven Van Caekenberghe

> On 02 Feb 2015, at 11:40, stepharo <stepharo(a)free.fr> wrote: > > + 10000 ^ 10000 You mean, + 10000 ** 10000, right ;-) > Stef > Le 2/2/15 10:51, Sven Van Caekenberghe a Ã©crit : >>> On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>> I do not know, and I'm starting to lose all interest. >> Nicolai, >> >> Please don't give up. >> >> You are doing great work and we are all *very* impressed with your attitude/drive/motivation, especially since you are covering such a wide range of subjects. I know that the hard thing right now is that you do not find enough sparring partners (that goes for others tackling different issues as well). >> >> Sven >> >> > >

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by stepharo

+ 10000 ^ 10000 Stef Le 2/2/15 10:51, Sven Van Caekenberghe a Ã©crit : >> On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> I do not know, and I'm starting to lose all interest. > Nicolai, > > Please don't give up. > > You are doing great work and we are all *very* impressed with your attitude/drive/motivation, especially since you are covering such a wide range of subjects. I know that the hard thing right now is that you do not find enough sparring partners (that goes for others tackling different issues as well). > > Sven > >

Feb. 2, 2015

Re: [Pharo-dev] athens font rendering and subpixel antialiasing

by Igor Stasenko

On 2 February 2015 at 11:23, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, Feb 2, 2015 at 8:06 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Ok, the best I could do: >> >> Sadly, it only works because I changed the default lcd_filter from cairo. >> in cairo 1.7. was a public API for the lcd_filter. >> since 1.8 this API is private again (the code for the different filter >> settings is still there). >> > > > In trying to learn some background info, this found article [1] seems > good, from which I learn: > > * Freely scalable it must be free from character drift. > > I guess this is what we want ? > > * Three main types of font rendering: > > * Hinting trades accuracy for consistency, and as a consequence of > this, hinted text _accumulates character drift_ with hinted glyphs, often > possessing different metrics to their un-hinted counterparts. > > So I guess we don't use hinting, which implies not freely scalable ? > > * Anti-aliasing results in output which is accurate but blurred, > trading contrast for consistency and accuracy. > > * Sub-pixel-rendering exploits the physical geometry of LCD screens to > increase the horizontal resolution of the device. Needs to be filtered to > avoid color fringing and is incompatible with aggressive hinting strategies. > > * Sub-pixel-positioning is a generalisation of anti-aliasing and/or > sub-pixel-rendering to allow for more accurate glyph placement, and is > incompatible with aggressive hinting strategies. > > That article [1] advises: > > * For sub-pixel-rendering to function correctly it is necessary to > enable the patent encumbered LCD filtering API. Many distributions, > including Debian, do this already and is generally not a problem. > > * Versions of Cairo before the 1.10 release use their own intra-pixel > filter. As of 2009 there are two sets of patches available that update > legacy releases of Cairo to use an FIR inter-pixel filter. The first set > pre-dates the filtering interface in FreeType and uses a custom FIR filter > with the coefficients outlined in Gib98. The second set of patches, by > David Turner, take advantage of the FreeType filtering interface. > > * It is recommended that distributions upgrade to Cairo 1.10 where at > all possible. Here [2] is a post on that. > > So btw, what version of Cario are we using? I see latest is version > 1.12.18. > > CMCairo>>downloadURL ^ 'http://www.cairographics.org/releases/cairo-1.12.14.tar.xz' > [1] https://freddie.witherden.org/pages/font-rasterisation/#spo07 > [2] http://lists.cairographics.org/archives/cairo/2010-January/018859.html > > > > >> You can choose between >> FT_LCD_FILTER_NONE >> FT_LCD_FILTER_LEGACY >> FT_LCD_FILTER_LIGHT >> FT_LCD_FILTER_DEFAULT >> >> the default is FT_LCD_FILTER_LEGACY >> but for this (so far, the best) result I used >> FT_LCD_FILTER_DEFAULT >> But there is no public API for this function anymore, so I had to >> change the code. >> >> >> We have to discuss how we proceed. >> >> The problems: >> font rendering looks ugly ( at least for small font size like for menus, >> lists and codepanes) >> font rendering looks different on windows and linux >> >> possible solutions: >> change build options for Freetype on Windos (enable >> FT_CONFIG_OPTION_SUBPIXEL_RENDERING, potential patent infringement?) >> change default filter (patching cairo source) >> >> or we leave everything as it is. >> I do not know, and I'm starting to lose all interest. >> >> >> nicolai >> >> >> >> 2015-02-01 19:38 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> **** patents! >>> >>> Hours, and days digging in the code for font rendering with cairo. >>> I tried to find out why this "colored" subpixel antialising is not >>> working although >>> all option settings are set (in cairo) and in the source code of cairo >>> the FT_SetLCDFilter >>> call is really used! But the output does is just the same as with >>> CAIRO_ANTIALIAS_GRAY, >>> >>> ... until I found THIS in the freetype config: >>> >>> /* Uncomment the line below if you want to activate sub-pixel rendering */ >>> /* (a.k.a. LCD rendering, or ClearType) in this build of the library. */ >>> /* */ >>> /* Note that this feature is covered by several Microsoft patents */ >>> /* and should not be activated in any default build of the library. */ >>> /* */ >>> /* This macro has no impact on the FreeType API, only on its */ >>> /* _implementation_. For example, using FT_RENDER_MODE_LCD when calling */ >>> /* FT_Render_Glyph still generates a bitmap that is 3 times wider than */ >>> /* the original size in case this macro isn't defined; however, each */ >>> /* triplet of subpixels has R=G=B. */ >>> >>> >>> >>> >>> ARGH! >>> >>> It still does not look as good as with the pharos freetypeplugin, but AT >>> LEAST it looks >>> equally on windows and linux , yeh. >>> >>> >>> attached are three screenshots comparing >>> the different athens drawings with the freetypeplugin >>> athens on linux vs ftplugin >>> athens on windows vs ftplugin >>> athens on windows with enabled FT_CONFIG_SUBPIXEL_RENDERING vs ftplugin >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 2015-01-31 10:18 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> >>>> >>>> In athens, there are "hints" you can set. >>>> (CairoFontOptions/hintMetricsOff/hintMetricsOn/hintStyleFull ....) >>>> I played a bit with different settings. Changing this settings change >>>> the output, but I can not get it to look >>>> like with the freetype plugin. I understand that this can not look >>>> equally, because the FreeTypePlugin and caire work differently, >>>> but the athens result looks bad compared with the other one. >>>> >>>> >>>> >>>>> - Pixel fitting. (The aliasing going on at the top of characters) Put >>>>> Hinting: None in FreeType advanced features, and you will probably see >>>>> something similar to the Athens rendering. >>>>> >>>> >>>> Yes, we can change the freetypeplugin setting and cairofontoption >>>> setting to make the output look equally - ugly :) >>>> >>>> >>>> Nicolai >>>> >>>> Igor explained to me that FreeType offers a degenerated mode that when >>>> the font does have the information for bold, kerning,.... >>>> computes a "guessed and approximated" default. Cairo does not offer >>>> this api else Athens would use it. >>>> So what would be interesting is to test using font having all the >>>> information to see if Cairo display well the fonts. >>>> >>>> Stef >>>> >>> >>> >> > -- Best regards, Igor Stasenko.

Feb. 2, 2015

Internship at Thales

by Marcus Denker

There is an offering at Thales for an internship for a student (in france): > Thank you for your interest in a career with Thales. Below you will find a link to the job that you found on the mobile website. When clicked, this link will allow you to view the job details again and Apply for the job. > > > STAGE Multi fenÃªtrage sous Pharo Smalltalk (Logiciel) (H\F) <http://jobs.thalesgroup.co.uk/fr/france/software-engineering/jobid6338665-s…> Job ID: 1413963 Job Location: Brest, Bretagne, France Position Type: Software Engineering Business Unit: Thales Systemes Aeroportes S.A. Post Date: 01/12/2015 Partout oÃ¹ des dÃ©cisions critiques doivent Ãªtre prises, Thales est prÃ©sent. Sur les marchÃ©s que nous servons -Â aÃ©ronautique, espace, transport terrestre, sÃ©curitÃ©, dÃ©fenseÂ -, nous assurons la maÃ®trise de la Â« chaÃ®ne de dÃ©cision critique Â» pour aider nos clients Ã choisir la meilleure option et Ã agir en consÃ©quence. Lâexpertise de sesÂ 65 000 collaborateurs, sa puissance technologique et sa prÃ©sence opÃ©rationnelle dansÂ 56 paysÂ font ainsi de Thales un acteur clÃ© de la sÃ©curitÃ© des citoyens, des infrastructures et des Etats. <> La Global Business Unit SystÃ¨mes de Mission de DÃ©fense, leader europÃ©en et troisiÃ¨me acteur mondial sur ses marchÃ©s par sa taille et son niveau technologique, conÃ§oit des Ã©quipements et des systÃ¨mes de mission pour avions, hÃ©licoptÃ¨res et drones militaires, bÃ¢timents de surface et lutte sous la mer. Elle propose Ã©galement une offre complÃ¨te de services de maintenance en condition opÃ©rationnelle. Thales SystÃ¨mes AÃ©roportÃ©s, filiale du Groupe Thales (3200 collaborateurs) regroupe diffÃ©rents domaines dâactivitÃ©s : systÃ¨mes de mission pour avions de mission et drones, Radars aÃ©roportÃ©s de combat et surveillance, SystÃ¨mes de Guerre Electronique (air, terre, mer, espace), Soutien et Service Client. Dans le cadre de notre dÃ©veloppement, nous recherchons un(e) : STAGE : Multi-fenÃªtrage sous Pharo Smalltalk (Logiciel) â H/F BasÃ©(e) Ã Brest (29) Contexte : Notre entitÃ© dÃ©veloppe rÃ©guliÃ¨rement des maquettes dâinterfaces homme-machine (IHM) innovantes. Lâinnovation se situe autant au niveau de lâergonomie quâau niveau du design graphique visuel ou des Ã©lÃ©ments dâinteraction. Le maquettage est souvent utilisÃ© en sÃ©ance avec les opÃ©rationnels, dâoÃ¹ lâemploi dâun langage dynamique comme Smalltalk qui permet la modification rapide (et en sÃ©ance) du code et des Ã©lÃ©ments dâinteraction. Le maquettage/prototypage des interfaces Homme-Machine est donc actuellement rÃ©alisÃ© sous SMOCK, un framework de maquettage dÃ©veloppÃ© en Smalltalk. Smalltalk Pharo est un excellent candidat pour la plateforme finale d'exÃ©cution du framework de maquettage/prototypage, cependant, certaines limitations de Pharo nous empÃªchent de l'utiliser de maniÃ¨re industrielle. Missions : Nous souhaitons expÃ©rimenter un environnement de maquettage sous Pharo, cependant, cette derniÃ¨re limite lâaffichage des IHM Ã lâintÃ©rieur d'une seule fenÃªtre de l'OS. Nous souhaitons, en relation avec la communautÃ© Pharo, dÃ©velopper le multi-fenÃªtrage. Le stagiaire devra implÃ©menter un mÃ©canisme permettant l'ouverture et gestion de fenÃªtres multiples dans les OS Windows et Linux Ã minima. Une rÃ©utilisation de code existant dans la communautÃ© Pharo et une reversion de code en OpenSource est envisageable. Le candidat sera l'interlocuteur entre Thales et la communautÃ© Pharo. Le candidat Ã©valuera diffÃ©rentes solutions de multi- fenÃªtrage sous diffÃ©rents critÃ¨res (performance, robustesse de la solution, portabilitÃ© de la solution...). La solution devra anticiper le futur et prÃ©voir d'afficher des contenus visuels variÃ©s (vidÃ©o, primitives de dessin 2D, OpenGL...). L'objectif sera de dÃ©velopper un prototype IHM multi-fenÃªtres de dÃ©monstration sur Pharo afin de dÃ©montrer les nouvelles capacitÃ©s et un aperÃ§u des performances. Formation souhaitÃ©e : Master 2 Pro ou 3Ã¨me annÃ©e d'Ecole d'IngÃ©nieur. Connaissances souhaitÃ©es : Le stagiaire devra avoir une connaissance du Smalltalk ou Ãªtre motivÃ© par lâapprentissage de celui-ci. Il devra ensuite Ãªtre motivÃ© par la conception dâinterface homme machine de nouvelles gÃ©nÃ©rations et novatrices. PÃ©riode souhaitÃ©e et durÃ©e : Ã partir de janvier 2015 pour une durÃ©e de 6 mois.

Feb. 2, 2015