September 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] About removing TextSqkLink and TextSqkProjectLink

by StÃ©phane Ducasse

Hi guys I wanted to know you point of view. I fall on TextSqkLink and TextSqkProjectLink that it would be good to remove them. What your point of view on that? Stef

Sept. 13, 2008

Re: [Pharo-project] Re: Re: Building VM Freetype

by Igor Stasenko

I rebuilt VM with changeset & uploaded it replacing old .zip. FreeTypeSettings current clearBitBltSubPixelAvailable; bitBltSubPixelAvailable prints: true 2008/9/13 Igor Stasenko <siguctua(a)gmail.com>: > 2008/9/13 Andrew Tween <amtween(a)hotmail.com>: >> Hi, >> "Igor Stasenko" <siguctua(a)gmail.com> wrote in message >> news:4a5f5f320809130455h6403bc01ne6f8c7638c02cbde@mail.gmail.com... >>> >>> I uploaded the binaries + freetype plugin platform sources under >>> "squeak VM + freetype" cat: >>> https://gforge.inria.fr/frs/?group_id=1299 >> >> Cool. >> The FreeType plugin seems to work great. >> I notice that you have used FreeType 2.3.7 - that's good, the previous >> plugin used 2.2.1 which is quite old now. >> >> However, the sub-pixel anti-aliasing isn't working. >> This can be tested by evaluating ... >> >> FreeTypeSettings current >> clearBitBltSubPixelAvailable; >> bitBltSubPixelAvailable >> >> It answers true if the new BitBlt combination rule 41 is present and >> working; false otherwise. >> > >> Did you install FreeTypeBitBltSimulation.1.cs >> (http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt…) >> into your VMMaker image? >> If you did, then it is possible that the changeset isn't compatible with the >> latest VMMaker, and I'll look into it. >> > oh..sorry, i forgot to load the changeset for BitBlt. > >> Cheers, >> Andy >> >> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: > >> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> this sounds interesting. >>> But I think that this is important to still be able to not rely on >>> external >>> libraries when you want. >>> so what is the exact difference between having it for free or optional >>> - ? that you need to implement the primitive on platform where you >>> do >>> not need? >>> - ? that the system is not layered in consequence? >> >> I think both. Having it 'for free' leads developers to think that they >> can use it anytime, anywhere, like in String>>showProgressBar. Which >> from my POV is complete stupidity. And now just check different >> mailing lists and count complains about unable to getting rid of such >> 'free' uses, like asking for user input or showing warnings in >> headless image :) > > sure this is something that we should fix from an infrastructural point of > view using a notification system. > At the end we should not that PopUpMenu everywhere but only in one place in > the Plafform > code. > >> I don't want it 'for free', but instead, i want that language should >> ask for it, and then, if VM could provide it - start using it. >> Instead of having 'position & size & fullscreen flag' hanging around >> in VM -obviously, with good design, this should be completely at >> language side. >> >>> Did you check the work made around "ffnestraria" ? >> >> Surely, this could be taken as a initial base for new plugin. >> But, as it reads on http://wiki.squeak.org/squeak/3862 : >> >> This architecture is for the lowest levels of the system, the virtual >> machine and dungeon levels of the image. NO support yet exists for >> Morphic since there is a vast amount of code and class cleanup needed. > > Yes I think that we should go slowly but removing a lot of morphic cruft > will > help. > >> >> Tweak has been our sole higher level target thus far since it is >> somewhat less broken, not to mention the target of our main project >> remit. >> >> Since Pharo now actively adressing different Morphic issues, it would >> be good for those who doing it (hello Gary) to keep this idea in mind. > > Yes > >> On embedded systems you don't have a 'window', you just have a >> display. But on PCs, operating system can provide you many windows , >> which can play role as displays. What is bad, that at language side >> you don't have a notion about this, as well as it don't have notion >> whether keys/mouse are present or not. >> I think this should be represented by concrete classes, which can >> answer things like: >> - hasKeyboard(s) >> - hasMouse(s) >> - hasDisplay >> - hasWindowing >> >> for instance, on windoze, you can use a real display using two approached: >> - one can prefer using a display (which covers a whole area of >> screen), and should be allowed to control its resolution (if >> possible). >> - another one can rather use windowing and treat separate native >> windows as separate displays. >> >>> Then what is important is to have good more then proof of concepts. >>> This is sometimes that we would be interested in. >>> >>> Stef >>> >> >> Concerning Display & Forms & BitBlt with connection with host window: We already have everything we need in VM!! The only thing which is required to wire things up. Here is components which need to be merged (to work together): - SurfacePlugin & HostWindowPlugin on VM side - DisplayScreen class need to be refactored to create new host window and ask for its surface (which in own turn should be registered by HostWindowPlugin using SurfacePlugin interface). There are also an example in platforms/Cross/plugins/ExampleSurfacePlugin , how to create & register own surface and how to use it at language side. So, we really can throw out almost all windowing stuff from core VM, leaving HostWindowPlugin to handle things. Initially, i guess, that most changes will affect the Display var and DisplayScreen class. For headless mode , a Display could be replaced by NoDisplayScreen - which simply ignoring all calls LazyDisplayScreen - which sits in Display global var until first drawing attempt, and then creates a window and replacing itself by working DisplayScreen. -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

Tx On Sep 13, 2008, at 1:55 PM, Igor Stasenko wrote: > I uploaded the binaries + freetype plugin platform sources under > "squeak VM + freetype" cat: > https://gforge.inria.fr/frs/?group_id=1299 > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2008

Re: [Pharo-project] Re: Re: Building VM Freetype

by Igor Stasenko

2008/9/13 Andrew Tween <amtween(a)hotmail.com>: > Hi, > "Igor Stasenko" <siguctua(a)gmail.com> wrote in message > news:4a5f5f320809130455h6403bc01ne6f8c7638c02cbde@mail.gmail.com... >> >> I uploaded the binaries + freetype plugin platform sources under >> "squeak VM + freetype" cat: >> https://gforge.inria.fr/frs/?group_id=1299 > > Cool. > The FreeType plugin seems to work great. > I notice that you have used FreeType 2.3.7 - that's good, the previous > plugin used 2.2.1 which is quite old now. > > However, the sub-pixel anti-aliasing isn't working. > This can be tested by evaluating ... > > FreeTypeSettings current > clearBitBltSubPixelAvailable; > bitBltSubPixelAvailable > > It answers true if the new BitBlt combination rule 41 is present and > working; false otherwise. > > Did you install FreeTypeBitBltSimulation.1.cs > (http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt…) > into your VMMaker image? > If you did, then it is possible that the changeset isn't compatible with the > latest VMMaker, and I'll look into it. > oh..sorry, i forgot to load the changeset for BitBlt. > Cheers, > Andy > > >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

[Pharo-project] Re: Re: Building VM Freetype

by Andrew Tween

Hi, "Igor Stasenko" <siguctua(a)gmail.com> wrote in message news:4a5f5f320809130455h6403bc01ne6f8c7638c02cbde@mail.gmail.com... >I uploaded the binaries + freetype plugin platform sources under > "squeak VM + freetype" cat: > https://gforge.inria.fr/frs/?group_id=1299 Cool. The FreeType plugin seems to work great. I notice that you have used FreeType 2.3.7 - that's good, the previous plugin used 2.2.1 which is quite old now. However, the sub-pixel anti-aliasing isn't working. This can be tested by evaluating ... FreeTypeSettings current clearBitBltSubPixelAvailable; bitBltSubPixelAvailable It answers true if the new BitBlt combination rule 41 is present and working; false otherwise. Did you install FreeTypeBitBltSimulation.1.cs (http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt…) into your VMMaker image? If you did, then it is possible that the changeset isn't compatible with the latest VMMaker, and I'll look into it. Cheers, Andy > > > -- > Best regards, > Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by Igor Stasenko

I uploaded the binaries + freetype plugin platform sources under "squeak VM + freetype" cat: https://gforge.inria.fr/frs/?group_id=1299 -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Fwd: [Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

Begin forwarded message: > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Date: September 13, 2008 11:28:56 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: Igor Stasenko <siguctua(a)gmail.com>, Michael Rueger <michael(a)impara.de > > > Subject: Re: [Pharo-project] Re: Building VM Freetype > Reply-To: johnmci(a)smalltalkconsulting.com > > Ok, first we statically loaded any *.dll into the freetype plugin > because we found earlier versions of os-x didn't have > the required version of freetype needed to support what we were > doing, also it was a complete mess on the linux side > with regard to what you would find there if you dynamically loaded > the plugin. > > the freetype plugin source code I have was loaded from http://source.impara.de/freetype > > I see the FT2Constants seems to be shared between the freetype base > package and the plugin package, so it appears you > need to load the base in order for the plugin to load. I'm not sure > anyone noticed this since you need to load the base in order > to test the plugin in any case. > > > On Sep 13, 2008, at 8:59 AM, StÃ©phane Ducasse wrote: > >> >> >> Begin forwarded message: >> >>> From: "Igor Stasenko" <siguctua(a)gmail.com> >>> Date: September 13, 2008 8:24:36 AM CEDT >>> To: "An open mailing list to discuss any topics related to an open- >>> source Smalltalk" <pharo-project(a)lists.gforge.inria.fr> >>> Subject: Re: [Pharo-project] Re: Building VM Freetype >>> Reply-To: An open mailing list to discuss any topics related to an >>> open-source Smalltalk <pharo-project(a)lists.gforge.inria.fr> >>> >>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I hope other will answer but I thought that we could have a pluggin >>>> and bundle in the deployed packages. >>>> The idea for pharo is to have a similar setup than seaside a one >>>> click app >>>> so the >>>> vm and its plugin would be there (but may be the plugin should >>>> not be in the >>>> image). >>> >>> Plugin is built-in in the VM. But freetype library is coming as >>> separate dynamic library. >>> Is this ok? >>> >>> There can be another option, but it would require to change the >>> plugin >>> code - to not link VM with import lib, but to load freetype.dll on >>> demand. The plugin can simply check if this .dll available and start >>> using it, or if not - fail to initialize, telling the system that >>> plugin functionality is not available. >>> >>>> >>>> Mike or john? On sophie how did you manage that the freetype >>>> bundle could >>>> not be present? >>>> >>> >>> Actually, to build a plugin, you need just headers + freetype.def >>> file >>> which then can be used to >>> create the imports library from it. >>> Building a freetype.dll can be completely separate process. >>> >>> I can remove dependency from freetype.lib, and leave only a >>> freetype.def and create import lib by own, when making VM. >>> But this is not safe, because now you must guarantee that you using >>> correct .dll. (well, you need to guarantee it in either case). >>> >>>> If I remember correctly some people on squeak have been >>>> recompiling it for >>>> 64 bits >>>> >>>>> I done with it. >>>>> The resulting VM will not start without freetype.dll. >>>>> Should i link it statically? But then you should hone their >>>>> license >>>>> stuff... >>>>> >>>>> Also, building freetype on windoze impossible using gnutools which >>>>> used for building VM. >>>>> It's make simply can't understand some things, which i assume >>>>> appear >>>>> in later make versions. >>>>> So, i building freetype using my msys/mingw environment, and then >>>>> simply producing >>>>> - freetype.lib (imports library) >>>>> - freetype.dll >>>>> >>>>> or maybe, i wrong, maybe it can be built using gnutools, but this >>>>> would require too much voodoo dancing. >>>>> it would be cool to make it cleanly build w/o manual work, but >>>>> i'm not >>>>> high expert in makefiles black voodoo. >>>>> >>>>> Okay, who wants the VM? And where i can put the stuff + >>>>> instructions + >>>>> blablabla? >>>> >>>> You can use the code google page for that. >>>> >>>> Stef >>>>> >>>>> >>>>> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>>>>> >>>>>> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>>>>>> >>>>>>> As always, things not working out of the box. >>>>>>> >>>>>>> - VM builds from unzipped VM sources OK >>>>>>> - but for building with VMMaker generated sources, had to fix >>>>>>> 'gnuify' >>>>>>> file to make a clean build >>>>>>> >>>>>>> i dreaming to build vm straight from squeak, without horrid >>>>>>> makefiles. >>>>>>> I heard that Keith did a 'Bob' tool which can be used as a >>>>>>> kind of >>>>>>> make utility. >>>>>>> But i think, to fully replace makefiles, it needs an >>>>>>> OSProcessPlugin >>>>>>> to be able to interact with OS/shell. >>>>>>> >>>>>> >>>>>> Next step, tried to load freetype plugin.... >>>>>> http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz >>>>>> http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz >>>>>> >>>>>> and guess what? YES! It can't be loaded! :) >>>>>> >>>>>> MC complains about following: >>>>>> >>>>>> This package depends on the following classes: >>>>>> FT2Constants >>>>>> >>>>>> The FT2Constants is the pool dictionary used by plugin. But not >>>>>> defined within package. >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> <fonts.jpg>_______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > >

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

On Sep 13, 2008, at 10:25 AM, Michael Rueger wrote: > Igor Stasenko wrote: >> ohh... a small correction. >> Not #hasDisplay, but #hasDisplays. >> Which is conceptually VERY important! > > And Ffenestri provides support for that. We actually have something > running (sort of ;-) ) that opens multiple native windows based on > ffenestri. > > I'm all for factoring out the input and display stuff into plugins, > ffenestri is IMHO a good base for that. You can still use bitblt or > balloon for display, so you don't necessarily have to rely on > external libraries as GTK does. So this is good. > > > IIRC the newer VMs already delay opening the window and only do it > on first access, so a first step in the right direction. > > But this, again, raises the question of VM building ;-) yes! > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: > 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> this sounds interesting. >> But I think that this is important to still be able to not rely on >> external >> libraries when you want. >> so what is the exact difference between having it for free or >> optional >> - ? that you need to implement the primitive on platform >> where you do >> not need? >> - ? that the system is not layered in consequence? > > I think both. Having it 'for free' leads developers to think that they > can use it anytime, anywhere, like in String>>showProgressBar. Which > from my POV is complete stupidity. And now just check different > mailing lists and count complains about unable to getting rid of such > 'free' uses, like asking for user input or showing warnings in > headless image :) sure this is something that we should fix from an infrastructural point of view using a notification system. At the end we should not that PopUpMenu everywhere but only in one place in the Plafform code. > I don't want it 'for free', but instead, i want that language should > ask for it, and then, if VM could provide it - start using it. > Instead of having 'position & size & fullscreen flag' hanging around > in VM -obviously, with good design, this should be completely at > language side. > >> Did you check the work made around "ffnestraria" ? > > Surely, this could be taken as a initial base for new plugin. > But, as it reads on http://wiki.squeak.org/squeak/3862 : > > This architecture is for the lowest levels of the system, the virtual > machine and dungeon levels of the image. NO support yet exists for > Morphic since there is a vast amount of code and class cleanup needed. Yes I think that we should go slowly but removing a lot of morphic cruft will help. > > Tweak has been our sole higher level target thus far since it is > somewhat less broken, not to mention the target of our main project > remit. > > Since Pharo now actively adressing different Morphic issues, it would > be good for those who doing it (hello Gary) to keep this idea in mind. Yes > On embedded systems you don't have a 'window', you just have a > display. But on PCs, operating system can provide you many windows , > which can play role as displays. What is bad, that at language side > you don't have a notion about this, as well as it don't have notion > whether keys/mouse are present or not. > I think this should be represented by concrete classes, which can > answer things like: > - hasKeyboard(s) > - hasMouse(s) > - hasDisplay > - hasWindowing > > for instance, on windoze, you can use a real display using two > approached: > - one can prefer using a display (which covers a whole area of > screen), and should be allowed to control its resolution (if > possible). > - another one can rather use windowing and treat separate native > windows as separate displays. > >> Then what is important is to have good more then proof of concepts. >> This is sometimes that we would be interested in. >> >> Stef >> > > > -- > Best regards, > Igor Stasenko AKA sig. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 13, 2008