- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: KernelImage fixes (was: Re: [squeak-dev] Burn the Squeak Image! (Why I am running for board))

by StÃ©phane Ducasse

not sure that this is still correct but I found that lost in my spam filter Sorry pavel. Begin forwarded message: > From: Pavel Krivanek <pavel.krivanek(a)gmail.com> > Date: March 1, 2009 5:12:20 PM CEST > To: stephane ducasse <stephane.ducasse(a)free.fr> > Subject: KernelImage fixes (was: Re: [squeak-dev] Burn the Squeak > Image! (Why I am running for board)) > > Hi Stef, > > there are some opened issues so we may start with them: > 310 and 311 - the goal is to be able to unload all tests. As Adrian > sugested, we may place it the package Tests - at least for now. > 346 - easy and safe to integrate > 348 - very important issue. Maybe you should place in one update fix > for MorphicUIManager>>interactiveParserFor: and in the next the rest > of the patch to prevent loading problems > There was one wrong step in the development of Pharo during removing > of MVC. Pharo deleted all MVC related code however in some cases it > was the sign to use the UIManager. > 71, 59 - very critical patch but I will have to check if the patches > are suitable for the latest pharo > > I suggest to remove the unused class variable Current from the > ColorTheme (issue 467) firstly - that cleans a lot of obsoleteClasses. > > I think that we need one important step in the development of Pharo - > the next image that will not contain any code that can be unloaded. > That should help us to increase the Pharo quality because now most > packges are on the logical level in contradistiction to KernelImage > where all packages are standalone unloadable entities. > The ideal state is when we have the minimal core image with logical > packages (like Collections) and the rest will be all unloadable > packages. > > Cheers, > -- Pavel > > > > On Sun, Mar 1, 2009 at 9:57 AM, stephane ducasse > <stephane.ducasse(a)free.fr> wrote: >> >>> The KernelImage ZOO including the building environment is here: >>> http://squeak.cz/public/pub/KernelImage/current/ >>> >>> Of course it is not perfect - the smallest image works only in Linux >>> and MorphicCore needs a lot of fixes so people should start with >>> MorphicExt and so on but it is usable starting point if someone is >>> interested... >>> >>> -- Pavel >> >> Hi pavel >> >> do you have some fixes, cs list that we could slowly integrate to >> pharo? >> >> Stef >> >

May 7, 2009

[Pharo-project] 10300 keystroke shortcut missing

by Alexandre Bergel

Cmd-x to remove elements Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 7, 2009

Re: [Pharo-project] Thoughts about Pharo GUI

by StÃ©phane Ducasse

where is your code? I have a huge list of pretty cool ideas but only two hands and one life. Stef On May 7, 2009, at 2:15 AM, stepken wrote: > Hi! > > Connecting Pharo to SUN Lively Morphic GUI: > > http://research.sun.com/projects/lively/ > > has lots of advantages: > > * decoupling of GUI and steering engine in hardware, like X-Server > from X.org > * independance of hardware and OS. > * speed - drawing canvas in SVG is implemented in C, steeting in > JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter > (http://llvm.org/) and even offers OpenGL as C-lib (Khronos) -> > No > more plugin's into VM necessary for graphics, same with > vector-font libraries. > * comfort - You can develop your smalltalk software from > everywhere, > e.g. pharo vm installed at a webhoster ... or local over loopback > interface. > * Lively and Squeak Morphic mental models fit perfectly, adaption > should be really easy. Dan Ingall being one of the designers of > Lively... > * Pharo's killer applications seaside and pier also are remote > applications, also using ActionScript and browser -> why not for > graphics, morphic and etoys? > * Chrome/FireFox tends to become the standard universal > visualisation and I/O toolkit for all OS, so why not being > lightyears ahead by consequently implementing the GUI in Chrome/ > FF? > > few disadvantages: > > * sound, videostreaming, printing problematic, but easily solvable, > because FF/Chrome already have that features built in ;-) > > I'm a bit disappointed by the fact, that the squeak / pharo jitter > still > has not the expected performance impact. Elliot does a good work, but > Frank Lesser with its DNG engine is showing actually, what is > technically possible ...C-Speed for Smalltalk and ! Apple is behind > LLVM > and JAVA 6 is showing also, that C-Speed can be reached in full > OO-Languages, see the "language shootout". By the way: ActionScript > is a > full OO-language, like Smalltalk. > > I really wondered, why not LLVM has become the standard jitter in > Pharo. > Power/ARM/Sparc/Intel ... processors are already supported! > > I think, any proprietary Jitter is a design fault ... > > just my 2 ct. > > Have fun, Guido Stepken > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 7, 2009

Re: [Pharo-project] NetNameResolver problem on Linux Ubuntu 9.04

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > new issue and you fill it. > on http://code.google.com/p/pharo/issues/ > Stef > done http://code.google.com/p/pharo/issues/detail?id=794 alain > On May 6, 2009, at 4:01 AM, Cameron Sanders wrote: > > >> This is the solution I used for the Mac. See the recent thread of: >> Monticello/ftp stopped working for me. >> >> The FTP side has another defect I mentioned... and I guess I need to >> learn where to enter that detail in the bug tracking system. >> -Cam >> >> On May 5, 2009, at 4:42 PM, Alain Plantec wrote: >> >> >>> Hi all, >>> Since one week I have network problems: >>> system update is not working, Monticello can't open any http >>> repository... >>> I've investigated a little bit and found that NetNameResolver always >>> fail when trying to resolve >>> www.squeaksource.com as an example: >>> NetNameResolver addressForName: 'www.squeaksource.com' >>> result is always nil. >>> I can make it work only by setting true to the #UseOldNetwork >>> NetNameResolver class variable. >>> I'm on Ubuntu 9.04, I'm using Exupery VM 0.15.1. >>> >>> I do not have any problem on a VirtualBox/Ubuntu 8.10, same VM. >>> >>> Cheers >>> Alain >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

May 7, 2009

Re: [Pharo-project] Thoughts about Pharo GUI

by Igor Stasenko

just found http://code.google.com/p/libjit-linear-scan-register-allocator/wiki/LLVM_an… 2009/5/7 Igor Stasenko <siguctua(a)gmail.com>: > 2009/5/7 stepken <stepken(a)web.de>: >> Hi! >> >> Connecting Pharo to SUN Lively Morphic GUI: >> >> http://research.sun.com/projects/lively/ >> >> has lots of advantages: >> >> Â Â * decoupling of GUI and steering engine in hardware, like X-Server >> Â Â Â from X.org >> Â Â * independance of hardware and OS. >> Â Â * speed - drawing canvas in SVG is implemented in C, steeting in >> Â Â Â JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter >> Â Â Â (http://llvm.org/) and even offers OpenGL as C-lib (Khronos) -> No >> Â Â Â more plugin's into VM necessary for graphics, same with >> Â Â Â vector-font libraries. >> Â Â * comfort - You can develop your smalltalk software from everywhere, >> Â Â Â e.g. pharo vm installed at a webhoster ... or local over loopback >> Â Â Â interface. >> Â Â * Lively and Squeak Morphic mental models fit perfectly, adaption >> Â Â Â should be really easy. Dan Ingall being one of the designers of >> Â Â Â Lively... >> Â Â * Pharo's killer applications seaside and pier also are remote >> Â Â Â applications, also using ActionScript and browser -> why not for >> Â Â Â graphics, morphic and etoys? >> Â Â * Chrome/FireFox tends to become the standard universal >> Â Â Â visualisation and I/O toolkit for all OS, so why not being >> Â Â Â lightyears ahead by consequently implementing the GUI in Chrome/FF? >> >> few disadvantages: >> >> Â Â * sound, videostreaming, printing problematic, but easily solvable, >> Â Â Â because FF/Chrome already have that features built in ;-) >> >> I'm a bit disappointed by the fact, that the squeak / pharo jitter still >> has not the expected performance impact. Elliot does a good work, but >> Frank Lesser with its DNG engine is showing actually, what is >> technically possible ...C-Speed for Smalltalk and ! Apple is behind LLVM >> and JAVA 6 is showing also, that C-Speed can be reached in full >> OO-Languages, see the "language shootout". By the way: ActionScript is a >> full OO-language, like Smalltalk. >> >> I really wondered, why not LLVM has become the standard jitter in Pharo. >> Power/ARM/Sparc/Intel ... processors are already supported! > > I studied LLVM functionality some time ago. And i don't remember what > exactly turns my nose off from it. Maybe because its too C-centric > approach: they care much about Globals, Linkage, custom-defined data > types, dynamic C code compilation which is totally have no use for > smalltalk. > I didn't found the ways how i could define own calling convention(s) , > other than cdecl. And to make smalltalk contexts efficient, IMO, you > have to change it. > From what i have seen, in examples like this > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html > Â .. LLVM is like a replacement of GCC compiler with mix of useful and > not so enhancements (in terms of smalltalk VM needs). Not sure how > this could help with making VM which could run smalltalk code - you're > still need to write it from scratch. > > Mainly, what i would like to reuse from LLVM is native code generator. > But again, from what i have seen, the code generator is focused to be > a backend for C compiler only. > That's only an impression, i could be wrong. > >> >> I think, any proprietary Jitter is a design fault ... >> >> just my 2 ct. >> >> Have fun, Guido Stepken >> >> _______________________________________________ >> 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.

May 7, 2009

Re: [Pharo-project] Thoughts about Pharo GUI

by Igor Stasenko

2009/5/7 stepken <stepken(a)web.de>: > Hi! > > Connecting Pharo to SUN Lively Morphic GUI: > > http://research.sun.com/projects/lively/ > > has lots of advantages: > > Â Â * decoupling of GUI and steering engine in hardware, like X-Server > Â Â Â from X.org > Â Â * independance of hardware and OS. > Â Â * speed - drawing canvas in SVG is implemented in C, steeting in > Â Â Â JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter > Â Â Â (http://llvm.org/) and even offers OpenGL as C-lib (Khronos) -> No > Â Â Â more plugin's into VM necessary for graphics, same with > Â Â Â vector-font libraries. > Â Â * comfort - You can develop your smalltalk software from everywhere, > Â Â Â e.g. pharo vm installed at a webhoster ... or local over loopback > Â Â Â interface. > Â Â * Lively and Squeak Morphic mental models fit perfectly, adaption > Â Â Â should be really easy. Dan Ingall being one of the designers of > Â Â Â Lively... > Â Â * Pharo's killer applications seaside and pier also are remote > Â Â Â applications, also using ActionScript and browser -> why not for > Â Â Â graphics, morphic and etoys? > Â Â * Chrome/FireFox tends to become the standard universal > Â Â Â visualisation and I/O toolkit for all OS, so why not being > Â Â Â lightyears ahead by consequently implementing the GUI in Chrome/FF? > > few disadvantages: > > Â Â * sound, videostreaming, printing problematic, but easily solvable, > Â Â Â because FF/Chrome already have that features built in ;-) > > I'm a bit disappointed by the fact, that the squeak / pharo jitter still > has not the expected performance impact. Elliot does a good work, but > Frank Lesser with its DNG engine is showing actually, what is > technically possible ...C-Speed for Smalltalk and ! Apple is behind LLVM > and JAVA 6 is showing also, that C-Speed can be reached in full > OO-Languages, see the "language shootout". By the way: ActionScript is a > full OO-language, like Smalltalk. > > I really wondered, why not LLVM has become the standard jitter in Pharo. > Power/ARM/Sparc/Intel ... processors are already supported! I studied LLVM functionality some time ago. And i don't remember what exactly turns my nose off from it. Maybe because its too C-centric approach: they care much about Globals, Linkage, custom-defined data types, dynamic C code compilation which is totally have no use for smalltalk. I didn't found the ways how i could define own calling convention(s) , other than cdecl. And to make smalltalk contexts efficient, IMO, you have to change it. >From what i have seen, in examples like this http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html .. LLVM is like a replacement of GCC compiler with mix of useful and not so enhancements (in terms of smalltalk VM needs). Not sure how this could help with making VM which could run smalltalk code - you're still need to write it from scratch. Mainly, what i would like to reuse from LLVM is native code generator. But again, from what i have seen, the code generator is focused to be a backend for C compiler only. That's only an impression, i could be wrong. > > I think, any proprietary Jitter is a design fault ... > > just my 2 ct. > > Have fun, Guido Stepken > > _______________________________________________ > 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.

May 7, 2009

Re: [Pharo-project] Thoughts about Pharo GUI

by Sebastian Sastre

Hi Guido, since the oracle adquisition of sun in april 20, don't forget to add to the list something like: the only one that can say anything about its future is the Oracle board. Is obvious that oracle is only interested in java. Who can now say anything about valuable sun projects just vaporized by this adquisition? the industry will get stronger or weaker? for those products we can only wait and see. Right now there are plenty of scared sun consumers (not to mention mysql in pain pre-ex-users) sebastian > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de stepken > Enviado el: Wednesday, May 06, 2009 21:16 > Para: pharo-project(a)lists.gforge.inria.fr > Asunto: [Pharo-project] Thoughts about Pharo GUI > > Hi! > > Connecting Pharo to SUN Lively Morphic GUI: > > http://research.sun.com/projects/lively/ > > has lots of advantages: > > * decoupling of GUI and steering engine in hardware, like X-Server > from X.org > * independance of hardware and OS. > * speed - drawing canvas in SVG is implemented in C, steeting in > JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter > (http://llvm.org/) and even offers OpenGL as C-lib > (Khronos) -> No > more plugin's into VM necessary for graphics, same with > vector-font libraries. > * comfort - You can develop your smalltalk software from > everywhere, > e.g. pharo vm installed at a webhoster ... or local > over loopback > interface. > * Lively and Squeak Morphic mental models fit perfectly, adaption > should be really easy. Dan Ingall being one of the designers of > Lively... > * Pharo's killer applications seaside and pier also are remote > applications, also using ActionScript and browser -> why not for > graphics, morphic and etoys? > * Chrome/FireFox tends to become the standard universal > visualisation and I/O toolkit for all OS, so why not being > lightyears ahead by consequently implementing the GUI > in Chrome/FF? > > few disadvantages: > > * sound, videostreaming, printing problematic, but easily > solvable, > because FF/Chrome already have that features built in ;-) > > I'm a bit disappointed by the fact, that the squeak / pharo > jitter still > has not the expected performance impact. Elliot does a good work, but > Frank Lesser with its DNG engine is showing actually, what is > technically possible ...C-Speed for Smalltalk and ! Apple is > behind LLVM > and JAVA 6 is showing also, that C-Speed can be reached in full > OO-Languages, see the "language shootout". By the way: > ActionScript is a > full OO-language, like Smalltalk. > > I really wondered, why not LLVM has become the standard > jitter in Pharo. > Power/ARM/Sparc/Intel ... processors are already supported! > > I think, any proprietary Jitter is a design fault ... > > just my 2 ct. > > Have fun, Guido Stepken > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 7, 2009

[Pharo-project] Thoughts about Pharo GUI

by stepken

Hi! Connecting Pharo to SUN Lively Morphic GUI: http://research.sun.com/projects/lively/ has lots of advantages: * decoupling of GUI and steering engine in hardware, like X-Server from X.org * independance of hardware and OS. * speed - drawing canvas in SVG is implemented in C, steeting in JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter (http://llvm.org/) and even offers OpenGL as C-lib (Khronos) -> No more plugin's into VM necessary for graphics, same with vector-font libraries. * comfort - You can develop your smalltalk software from everywhere, e.g. pharo vm installed at a webhoster ... or local over loopback interface. * Lively and Squeak Morphic mental models fit perfectly, adaption should be really easy. Dan Ingall being one of the designers of Lively... * Pharo's killer applications seaside and pier also are remote applications, also using ActionScript and browser -> why not for graphics, morphic and etoys? * Chrome/FireFox tends to become the standard universal visualisation and I/O toolkit for all OS, so why not being lightyears ahead by consequently implementing the GUI in Chrome/FF? few disadvantages: * sound, videostreaming, printing problematic, but easily solvable, because FF/Chrome already have that features built in ;-) I'm a bit disappointed by the fact, that the squeak / pharo jitter still has not the expected performance impact. Elliot does a good work, but Frank Lesser with its DNG engine is showing actually, what is technically possible ...C-Speed for Smalltalk and ! Apple is behind LLVM and JAVA 6 is showing also, that C-Speed can be reached in full OO-Languages, see the "language shootout". By the way: ActionScript is a full OO-language, like Smalltalk. I really wondered, why not LLVM has become the standard jitter in Pharo. Power/ARM/Sparc/Intel ... processors are already supported! I think, any proprietary Jitter is a design fault ... just my 2 ct. Have fun, Guido Stepken

May 7, 2009

Re: [Pharo-project] UML diagram (OBEnhancement)

by David RÃ¶thlisberger

> I would not put superOb in scriptloader like that you can do what you > want and we too :) superOB per se is cool to have, the question is just which code OB uses for the UML generation. This code is defined in Mondrian, not in OB. So instead of removing superOB we better agree on a standard UML diagram format to be displayed. People can then switch themselves to an extended format, if they please. David > On May 6, 2009, at 4:18 PM, CÃ©drick BÃ©ler wrote: > >> Hi guys, (cc'ed to pharo list - we're talking about the UML diagram >> used in OBEnhancement) >> >> 2009/5/6 David RÃ¶thlisberger <roethlis(a)iam.unibe.ch>: >>> Hi CÃ©dric, >>> >>> I also like what you did for the UML diagram. >> I didn't push it to the repository because they were some personal >> choices and you underlined some of them. >> >>> Some issues I encountered: >>> >>> - class-side methods should not be at the bottom, but at the top, and >>> displayed with underlined font to be more UML-compliant. >> Oh I forgot about that. Looks ok to me though I don't know yet how to >> underline text in Mondrian (the text is a single stream with cr's) >> >>> - not sure about adding the method protocol. If included, I'd >>> rather go for >>> ordering the method alphabetically and then show the protocol in >>> parentheses >> yes there is an ordering problem. The alphabetical order is ok, but >> printing the protocol beside could lead to long lines and then wide >> rectangles in the diagrams. >> >> Even if not standard, I actually prefer the ordering by protocol >> mainly because it shows the method intention and it forces to use >> them. >> Nevertheless, to be consistent, I'd like to have a list of predefined >> protocols that can be ordered (initialize, accessing, ...) but this is >> outside the scope of the UML diagram. >> >> Could we agree on that in Pharo (standard list of method protocols) ? >> Can someone propose a starting point... >> >> What do you think ? (we could also provide an alternative ordering >> trough a popumenu "alphabetical/protocol") >> >>> - accessors should be present, IMO. >> I agree for the general case but decided to not show them in my >> diagrams. >> >> This is part of a wider strategy. I explore using ivar as slots and >> hence not consider accessors as methods. Each ivar has automatic >> accessors that I try to complete with pragma's for further processing. >> Something like <type: min: max: visibility: >... >> Just experiencing... but anyways, I find accessing methods adding too >> much extra noise in the diagrams. I'd prefer completing ivars with >> their visibility characteristic. Maybe another candidate for the >> popumenu (hide accessors). >> >> >>> - empty areas at the end should not be shown at all, eg. if there >>> are no >>> class methods, class vars. I'd instead suggest to show class vars >>> underlined >>> in the variable area at the top, class methods underlined at the >>> top of the >>> method area, which means that there are only two areas. If there >>> are no vars >>> or methods defined, keep the empty area, but having two or three >>> empty areas >>> is very confusing (and non-standard). >> ok, you're right. Still, I need to know how to underline text... Do I >> need to use TextAttribute ? Any pointers ? >> >>> For classes without methods and vars (there are some of those...) >>> we should >>> only show the rectangle with the class name. >> ok. >> >> >>> I'd very much appreciate if you could extend your implementation to >>> address >>> these issues. >> I'll try to do so ;) >> >> I've also planned to fill menus (browse, implement, senders, >> variables, etc... + export as PNG + ...) and hoverText (class comment, >> method definitions ...). >> >> Such a diagram could be an alternative/complementary way of browsing >> code... >> >>> Note that OB uses your implementation, as we rely on the class >>> UMLEnhClassDiagram from Alex' Mondrian version containing your >>> extensions. >> Yep, I saw that ;) >> >> Cheers, >> >> CÃ©drick >> >>> Thanks a lot, >>> David >>> >>>> I like your extension. Adding edges will not be a problem. You're >>>> the >>>> second one to ask for it. >>>> I will do some coding tonight or tomorrow, will come back to you >>>> soon. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 30 Apr 2009, at 16:59, CÃ©drick BÃ©ler wrote: >>>> >>>>> Hi Alexandre and David, >>>>> >>>>> I just saw that you merged the development of Mondrian with >>>>> OBDiagram. >>>>> Sounds good to me. Though, I missed some information in the UML >>>>> class >>>>> diagram, so I did my own. I joined it in cas you'd like it (plus a >>>>> diagram example). One remark though, I simply remove accessing >>>>> methods >>>>> as I find they "pollute" my diagrams. It's ok for me but I guess >>>>> not >>>>> for general diagrams. >>>>> >>>>> I actually play more with accessing method so that I can have their >>>>> status and type (declaration in pragmas). Do you think it will be >>>>> doable to draw associations between classes (if declared in >>>>> pragmas) ? >>>>> >>>>> Cheers, >>>>> >>>>> -- >>>>> CÃ©drick >>>>> <UMLFullClassDiagram.st><xorp.png> >>> >> _______________________________________________ >> 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

May 6, 2009

Re: [Pharo-project] [OT] Pharo wallpaper

by Mariano Martinez Peck

On Wed, May 6, 2009 at 3:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > You can get the halos back using the preference > halosEnabled > Perfect!!! I could resize and put it as background :) Thanks! Mariano > > Stef > > On May 6, 2009, at 5:04 PM, Mariano Martinez Peck wrote: > > > > > > > On Thu, Apr 23, 2009 at 8:10 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com > > > wrote: > > When you put an image as background, is there an option to maximize > > it to the full zize instead of mosaic ? > > > > no one ? > > > > Since I don't have halos anymore, I don't know hot to resize > > (stretch) an image. > > > > Cheers, > > > > Mariano > > > > > > Thanks! > > > > Mariano > > > > > > On Thu, Apr 23, 2009 at 12:53 PM, Lukas Renggli <renggli(a)gmail.com> > > wrote: > > I am not a fan of photo wallpapers, but if there is a need for a > > picture I can offer this one: > > > > http://tinyurl.com/c3vqrx > > > > I made it on a trip with Stef to Nice in the village of Menton. > > > > Lukas > > > > On Thu, Apr 23, 2009 at 2:59 PM, Sebastian Sastre <ssastre(a)seaswork.com > > > wrote: > > > would be a good choice > > > sebastian > > > > > >> -----Mensaje original----- > > >> De: pharo-project-bounces(a)lists.gforge.inria.fr > > >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > > >> nombre de Torsten Bergmann > > >> Enviado el: Thursday, April 23, 2009 08:08 > > >> Para: pharo-project(a)lists.gforge.inria.fr > > >> Asunto: [Pharo-project] [OT] Pharo wallpaper > > >> > > >> The following wallpaper [1] looks very good behind the Watery > > Theme2 > > >> and the Pharo logo. It also gives an association with seaside. > > >> > > >> On the website it's claimed at least as free for download, it > > remains > > >> intellectual property of the media company. We could ask for > > >> permission > > >> or should digg in all our holiday photos to get something similar. > > >> > > >> [1] > > >> http://www.wallpapersphere.com/preview/scenery/seascape/1280+x > > >> +800/791/19581 > > >> [2] > > >> > http://www.wallpapersphere.com/nature-wallpapers/scenery/seascape.html > > >> > > >> -- > > >> Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + > > >> Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* > > >> http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 6, 2009