August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Display depth on Linux

by David T. Lewis

On Tue, Aug 11, 2009 at 08:26:20AM +0100, Douglas Brebner wrote: > St?phane Ducasse wrote: > > Guys > > > > could you create a wiki pages with "Possible problems with interacting > > tools on windows" > > or something like that? > > > > Stef > > > > > I believe this problem is due to a combination of the unix vm putting > garbage into the alpha channel (the extra 8bits in 32bit colour after > RGB) and a Composite extension manager active on the X server. I think > Metacity uses Composite as does Compiz and a few others. I have zero expertise in this area, but in case it is related: Juan Vuletich posted a fix yesterday in Mantis 7376: "Bug in BitBlt (rgbMul sets alpha to 0)". I can't tell if this relates to the problem you are describing, but FWIW Juan's fix is in the latest VMMaker on SqueakSource (as of yesterday), so if you are building your on VM you can try it and see if it makes a difference. Dave

Aug. 11, 2009

Re: [Pharo-project] How to build a GUI

by Henrik Johansen

At least when I tested Cuis StrikeFonts, this was caused by the weird behavior of String >> withoutTrailingDigits. (which returns the string up to first whitespace or digit, not the string excluding last digits and/or whitespace). The same might hold true for FreeType-fonts, haven't got time to test it right now though. Cheers, Henry On Aug 11, 2009, at 12:01 42PM, Gary Chambers wrote: > As for font chooser, there seems to be a problem with the FreeType > support not selecting the correct fonts at the default sizes for > some (most?) fonts. The FreeType font selector also exhibits this > behaviour. > > Regards, Gary > ----- Original Message ----- > From: csrabak(a)bol.com.br > To: pharo-project(a)lists.gforge.inria.fr > Sent: Monday, August 10, 2009 8:56 PM > Subject: Re: [Pharo-project] How to build a GUI > > > Hi, > > > > I'm a bit (well, totally) lost on how to build a GUI with > Polymorph or > > ToolBuilder or whatever. I want to code a GUI with the same look & > feel as > > Pharo tools. I cannot find any up to date comprehensive guide on the > > subject. May be you have some links, or good books .... > > > Laurent, > > Not exactly a compreensive documentation but rather a quick start: > > In a workspace evaluate: > > UITheme exampleBasicControls. > UITheme exampleColorControls. > UITheme exampleDialogs. > UITheme exampleGroups. > UITheme exampleOtherControls. > UITheme exampleWindowWithToolbars. > > Once you're done (and if you managed *not* to click any "OK" button > on the examples ;-) ) evaluate: > > UITheme closeExampleDialogs. > > HTH > > PS.: Is it "known" (a.k.a. 'intentional') that in the Font Selector > example the Preview isn't functional? > > > > > _______________________________________________ > 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

Aug. 11, 2009

Re: [Pharo-project] How to build a GUI

by Gary Chambers

As for font chooser, there seems to be a problem with the FreeType support not selecting the correct fonts at the default sizes for some (most?) fonts. The FreeType font selector also exhibits this behaviour. Regards, Gary ----- Original Message ----- From: csrabak(a)bol.com.br To: pharo-project(a)lists.gforge.inria.fr Sent: Monday, August 10, 2009 8:56 PM Subject: Re: [Pharo-project] How to build a GUI > Hi, > > I'm a bit (well, totally) lost on how to build a GUI with Polymorph or > ToolBuilder or whatever. I want to code a GUI with the same look & feel as > Pharo tools. I cannot find any up to date comprehensive guide on the > subject. May be you have some links, or good books .... > Laurent, Not exactly a compreensive documentation but rather a quick start: In a workspace evaluate: UITheme exampleBasicControls. UITheme exampleColorControls. UITheme exampleDialogs. UITheme exampleGroups. UITheme exampleOtherControls. UITheme exampleWindowWithToolbars. Once you're done (and if you managed *not* to click any "OK" button on the examples ;-) ) evaluate: UITheme closeExampleDialogs. HTH PS.: Is it "known" (a.k.a. 'intentional') that in the Font Selector example the Preview isn't functional? ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009

Re: [Pharo-project] How to build a GUI

by nullPointer

StÃ©phane Ducasse-2 wrote: > > >> Now i dont store the code in nowhere, >> because is still in alpha state. > > don't do that! :) > Publish often - just say that this is alpha. > Once one of my friends lost two years of dev because nice guys came > during his holidays and > let him only the wallpaper in his house. They stole absolutely > everything. > The neighbour thought they were movers. > > Well. I will finish the Menu editor and then up the source.But I warn than the code is ugly and plenty of errors :| regards. -- View this message in context: http://n2.nabble.com/How-to-build-a-GUI-tp3419005p3422900.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 11, 2009

Re: [Pharo-project] Wiki for Pharo future work [WAS] preparing 1.1

by StÃ©phane Ducasse

> > It would be great to include Keith's CleanUp protocol, as you > mentioned - > http://n2.nabble.com/Fwd:-Cleanups--td3256306.html > > Ideally, would every class implement cleanUp? > > SmalltalkImage current cleanUpAll should be guaranteed to yield an > image > with no obsoletes. > > Cheers, ...Stan We have to check and tied up a bit more the protocol so far this is not clear to me what is exactly the protocol we want. So I would love to see proposals (with code :)) Stef

Aug. 11, 2009

Re: [Pharo-project] How to build a GUI

by StÃ©phane Ducasse

On Aug 11, 2009, at 10:01 AM, nullPointer wrote: > > > > StÃ©phane Ducasse-2 wrote: >> >> What will be the license of your toolBuilder? >> Then if you need help for the serialization did you do a call? >> Where the code is stored? >> > > The license will be MIT as Pharo. Excellent! > Now i dont store the code in nowhere, > because is still in alpha state. don't do that! :) Publish often - just say that this is alpha. Once one of my friends lost two years of dev because nice guys came during his holidays and let him only the wallpaper in his house. They stole absolutely everything. The neighbour thought they were movers. > I believe in one or two weeks i could up in > squeakSource, for first usable version. People also can have a look and give hand. > > I believe than the best way for serialization is the same than another > environments as VS, where the building of code is "plain", > > | myMorph | > myMorph := MyMorph new. > myMorph layout: blablahblah.. > myMorph label: blabla... > ... > ^ myMorph > > but is too the most hard, i believe. > > regards > > > > -- > View this message in context: http://n2.nabble.com/How-to-build-a-GUI-tp3419005p3422402.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009

Re: [Pharo-project] Wiki for Pharo future work [WAS] preparing 1.1

by Stan Shepherd

StÃ©phane Ducasse-2 wrote: > > I will do a pass on the items in the future because some are at > different plans. > > Stef > > It would be great to include Keith's CleanUp protocol, as you mentioned - http://n2.nabble.com/Fwd:-Cleanups--td3256306.html Ideally, would every class implement cleanUp? SmalltalkImage current cleanUpAll should be guaranteed to yield an image with no obsoletes. Cheers, ...Stan -- View this message in context: http://n2.nabble.com/Wiki-for-Pharo-future-work--WAS--preparing-1.1-tp34135… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 11, 2009

Re: [Pharo-project] [squeak-dev] Squeak 4.x should adopt Pharo 1.0

by StÃ©phane Ducasse

good summary :) We started pharo because we could not move anymore. We will continue to pay attention to what they other forks are doing. Stef On Aug 10, 2009, at 11:10 PM, Miguel Enrique CobÃ¡ Martinez wrote: > El lun, 10-08-2009 a las 21:07 +0100, Keith Hodges escribiÃ³: >> Dear All, >> >> As far as I see it the only sensible way ahead for squeak 3.11 is to >> adopt Pharo 1.0 as the next base version of squeak (i.e. 4.0), and to >> begin a series of initiatives to promote compatibility with squeak >> pieces that pharo doesn't support. >> >> The previous squeak 3.11 vision accepted, and now rejected, by the >> squeak board was to develop a process that would allow squeak to >> harvest >> the contributions of all the other forks, or other major initiatives, >> and for significant contributions to be shared by all the forks. >> >> All of a sudden there was an "oh no pharo is ahead of us" panic that >> ensued last month as a result of new squeak-dev people that were not >> involved in, nor seemed aware of the goals of the 3.11 process. >> Within >> this process Pharo may simply be viewed as a research project carried >> out on behalf of the wider squeak community, that will be >> harvestable in >> good time. > > I don't agree with you on this point. Pharo has its own merits to > exists > and it didn't fork as a "research project" for the squeak community. > As its web page states, its goal is: > > "to deliver a clean, innovative, open-source *Smalltalk*" > > emphasis mine. Not a clean Squeak. > As the day pass the foundations grow stronger and itself gains more > and > more identity and independence. This, if nothing really big happens on > Squeak, will attract more developers and new users. There is no date > yet > to deliver a new version of Squeak, and this, together with the Pharo > 1.0 release, will be less energy to try to maintain code for several > forks and several packages will choose to support the one with more > *apparent* users. > What I want to say is, there is, as each day pass, less homesick for > the > past and more joy for the future. > > >> >> However now that this idea is no longer going to be developed, we >> need >> to limit the number of diverging active forks as much as possible, >> rather than creating new ones ("trunk" makes the problem worse not >> better). > > This is a point that I have never accepted of your thesis. There is no > way to put all the "forks" in the same > process/mindshare/goals/repositories. It is impossible. Even if they > do > it just for upsetting people. This isn't going to happen. > > The forks, as the young people, want to be free, independents, of its > parents. They don't want to be like their parents project but a little > different. They WANT to be better (whatever this means to the fork) > and > independent. They want to learn their own lessons. > > If for accident they happen to be compatible good, but if not, well, > as > the Linux community can show, there can not be a single distro > neither a > single code base that runs in every distro. How they solved it, by > assinging mainteiner of each package that tracks the upstream project > and adapt it to the specific distro. Something like this will happen > with squeak/pharo/cuis. The upstream developers will have its > development platform but someone else will adapt it to other > platforms. > > > >> Once the output of "trunk" is released in whatever form we will >> then have yet another base image to manage code for, and I don't >> think >> that that is an acceptable outcome. >> >> When it comes to the elections next year, if there is anyone who >> would >> like to run on the "Squeak to adopt Pharo" ticket, then I will vote >> for >> them. >> > > If this happen, then good for both of the communities. But until this > happen, most new users will learn by the lists about pharo and when > trying and comparing it to squeak, will make its choice. Some of them > will stay with squeak, some of them will try again squeak when a new > release is made and some of them will stay with pharo for ever. > > One (at least me) can't be jumping or using several smalltalk versions > (the same way that I don't like to administer linux of several > flavors, > it add unnecessary complexity and work). > >> best regards >> >> Keith >> >> p.p.s. Bob is not going to be released as open source, if you would >> like >> the ability to build your images daily, and run the test suites >> against >> your deliverables, then please do email me for licensing terms. >> > > This is really a sad thing to read. Of course it is your decision, bad > for us as it sound as Bob was a very good piece of software. On the > other side, this sounds also like a emotional response more than a > rational one. But if the community can't use your code, well, like the > BitKeeper on the Linux kernel code case, someone will have to think > something. > > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009

Re: [Pharo-project] How to build a GUI

by nullPointer

StÃ©phane Ducasse-2 wrote: > > What will be the license of your toolBuilder? > Then if you need help for the serialization did you do a call? > Where the code is stored? > The license will be MIT as Pharo. Now i dont store the code in nowhere, because is still in alpha state. I believe in one or two weeks i could up in squeakSource, for first usable version. I believe than the best way for serialization is the same than another environments as VS, where the building of code is "plain", | myMorph | myMorph := MyMorph new. myMorph layout: blablahblah.. myMorph label: blabla... ... ^ myMorph but is too the most hard, i believe. regards -- View this message in context: http://n2.nabble.com/How-to-build-a-GUI-tp3419005p3422402.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 11, 2009

Re: [Pharo-project] a process to maintain non core package

by Michael Roberts

This sounds great. Can you fill in some links on the wiki? Thanks mike On Monday, August 10, 2009, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: > Miguel Enrique CobÃ¡ Martinez wrote: >> El dom, 09-08-2009 a las 21:01 +0100, Keith Hodges escribiÃ³: >> >>> Keith Hodges wrote: >>> >>>> Adrian Lienhard wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> I really think we need a package management system and a process to >>>>> maintain it. >>>>> >>>>> The goal is that loading and using non-core packages "just >>>>> works" >>>>> >>> Same goal as for Sake/Packages, and it works for me. >>> >>> >>>>> Â (unlike for instance SqueakMap, where loading more often fails >>>>> than succeeds because there are a lot of obsolete packages and a >>>>> dependency mechanism is missing). >>>>> >>>>> - There should be a responsible maintainer for each package >>>>> >>>>> >>> Not a realistic proposition. Better to be open to all to maintain on >>> behalf of the community. >>> >> >> Why not, the debian project use this model since 1996 or something like >> that. >> The same package system the use report packages not maintained anymore >> (orphans and waiting for mantainer) >> >> >>>>> - For each package there should be a known way to discuss and report >>>>> problems >>>>> >>>>> >>> That's just arbitrary metadata in the package definition, for more >>> general topics we use the packages(a)squeakfoundation.org mailing list >>> >>>>> - A gate keeper includes and removes packages from the set depending >>>>> on their status >>>>> >>>>> >>> Probably too complicated to be practical. >>> >>>>> This limits the set of included packages (at least initially) but >>>>> would increase the quality and hence the user experience. >>>>> >>>>> Maybe there could be two sets, a stable and an unstable set. New >>>>> >>>>> >>> Sake/Packages supports a stable and a beta release of each package. >>> >>>>> packages would first go to the unstable set and then move up to the >>>>> stable set after a while. >>>>> >>>>> An automated build process could load packages into new builds and >>>>> report the result of the tests. >>>>> >>>>> >>> Bob does that. >>> >>>>> The package management system does not need to be very sophisticated, >>>>> >>>>> >>> Sake is as simple as possible for defining actions with dependencies. >>> >>>>> but it should manage dependencies and have a simple GUI (to search for >>>>> packages and see what is already loaded). >>>>> >>>>> >>> Sake/Packages uses the class browser as is, no extra GUI is required. >>> >>> Packages provided explore >>> >>> shows you what is loaded, and this should be merged into >>> PackageOrganization. >>> >>> Keith >>> >> >> Keith, it really appear that you have built the platform to bring this >> dream a reality, but somehow (the details are not relevant now) you >> haven't materialized a "steve jobs" kind of show off of it. >> I believe your words, based on your other projects that I use. What do >> you need, as Stephan said, to bring a complete, working, and as simple >> to understand for all of us of your tools. >> This is my proposal: >> >> I think that if you can put a working example (minimal, a couple of >> packages, and the core) using Pharo, the pharo community happily will >> support you. No more fights, no more angry mails, just the working full >> simple demo. >> I offer to you access to a server with a homologated IP to install (I >> can help you here too) to setup the repositories to test your tools. >> If the community agree to use your tools and process I can also buy and >> donate the domain to host this infrastructure. In the beginning I will >> host it, if someday it grows more than I can support (bandwidth mainly, >> the space isn't problem) then we will discuss with the community to >> migrate the repos to a bigger servers or to ask for donations or some >> other I've seen Keiths Seaside gui he made for Bob though I don't know if he > wants it to be shown around. It looks nice. > > Here's a quick explanation for those not familiar with them. > Sake is essentially Make for Smalltalk, allowing you to define tasks > that can depend on other tasks. > Bob is a build tool, which handles all the actual building using Sake > tasks to define what to do. > > With Bob+Sake, you can define a build to: > 1. Start with a defined image. > 2. Load a set of packages into that image (either specific versions or > the latest ones). > 3. Apply specific fixes from the bug tracker. > 4. Run tests. > 5. Save the new image and export all the new package versions to a new > folder. > > You can define tasks to apply features to an image such as closures or > perform updates between versions or even update applications. > > For example, you can define tasks to do the following sort of things > Pharo1.0beta -> Pharo1.0final > Pharo1.0beta -> Pharo-latest. > Squeak 3.10.2 image -> 3.10.2+closures. > Squeak 3.8 image -> 3.8+closures. > Seaside 2.8 -> 2.9. > Pharo-latest -> Pharo-latest + Seaside-latest + your own favourite packages. > > Once defined, these will allow anyone to repeatably and reliably produce > an updated image+packages without changing the original image. You can > then do things like upgrade a production image based on 1.0beta to > 1.0final just by using the same task but telling it to start with your > production image instead of the 1.0beta distribution image. Since it > produces a new image you don't risk clobbering your original. > > You should also be able to replace the update stream with distributing > build definitions for Bob. > > I believe one of the key points to this setup is that you don't need to > work on the image as a single blob any more, you only work on the > packages and use Bob to handle the messy image building stuff. That does > depend on the image being sectioned into packages of course. > > If I've had any misunderstandings here I hope Keith will correct me but > the system looks awesome :) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 11, 2009