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

Re: [Pharo-project] [ANN 1.1] Pre-built core 1.1.1

by Lukas Renggli

I am already re-building everything on Hudson with this image. Hopefully things go well. One-click images will use Cog. Lukas On 18 September 2010 09:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Sep 18, 2010, at 9:34 AM, Sven Van Caekenberghe wrote: > >> >> On 12 Sep 2010, at 12:02, Marcus Denker wrote: >> >>> Â Â Â https://gforge.inria.fr/frs/download.php/27479/PharoCore-1.1.1.zip >> >> The images inside are 11414 but the filenames say otherwise: >> > Uhh.... I will redo it. > > There are two other fixes I missed, too. > >> >> Will the official 'stable' link move to this one too (or did it already) ? >> > > No, this will be done as soon as we have a full image, too. > > Â Â Â Â Marcus > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Sept. 18, 2010

Re: [Pharo-project] [ANN 1.1] Pre-built core 1.1.1

by Marcus Denker

On Sep 18, 2010, at 9:34 AM, Sven Van Caekenberghe wrote: > > On 12 Sep 2010, at 12:02, Marcus Denker wrote: > >> https://gforge.inria.fr/frs/download.php/27479/PharoCore-1.1.1.zip > > The images inside are 11414 but the filenames say otherwise: > Uhh.... I will redo it. There are two other fixes I missed, too. > > Will the official 'stable' link move to this one too (or did it already) ? > No, this will be done as soon as we have a full image, too. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 18, 2010

Re: [Pharo-project] Community in the IDE

by laurent laffont

2010/9/18 GÃ¶ran Krampe <goran(a)krampe.se> > On 09/17/2010 12:58 PM, George Herolyants wrote: > >> Implemented in some commercial Java IDE. Never tried, but sounds great! :) >> > > I have thought about going further - a publish/subscribe system for > "development events" where you decide what events you want to publish and > what you want to receive. Then you could get immediate feedback if someone > *right now* is modifying a class you wrote, or if someone is publishing a > new version of a package you are using etc etc. > I like the idea. Do someone know a working IRC client (or have the courage to don his superhero costume and make it working to save our lives :) on Pharo ? So we can use #pharo-project channel on irc.freenode.net. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ > > regards, GÃ¶ran > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 18, 2010

[Pharo-project] [ANN 1.1] Pre-built core 1.1.1

by Sven Van Caekenberghe

On 12 Sep 2010, at 12:02, Marcus Denker wrote: > https://gforge.inria.fr/frs/download.php/27479/PharoCore-1.1.1.zip The images inside are 11414 but the filenames say otherwise: $ unzip -l ~/Downloads/PharoCore-1.1.1.zip Archive: /Users/sven/Downloads/PharoCore-1.1.1.zip Length Date Time Name -------- ---- ---- ---- 0 09-12-10 11:58 PharoCore-1.1.1/ 8242224 09-12-10 11:58 PharoCore-1.1.1/PharoCore-1.1-11411.changes 14285724 09-12-10 11:58 PharoCore-1.1.1/PharoCore-1.1-11411.image 16235372 10-19-09 17:02 PharoCore-1.1.1/PharoV10.sources -------- ------- 38763320 4 files A bit confusing and probably not the intention. Will the official 'stable' link move to this one too (or did it already) ? Sven

Sept. 18, 2010

Re: [Pharo-project] Community in the IDE

by GÃ¶ran Krampe

On 09/17/2010 12:58 PM, George Herolyants wrote: > Implemented in some commercial Java IDE. Never tried, but sounds great! :) I have thought about going further - a publish/subscribe system for "development events" where you decide what events you want to publish and what you want to receive. Then you could get immediate feedback if someone *right now* is modifying a class you wrote, or if someone is publishing a new version of a package you are using etc etc. regards, GÃ¶ran

Sept. 18, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Juan Vuletich

DeNigris Sean wrote: > I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it. > > I think it's amazingly powerful and universally misunderstood. I agree. > Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: > 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible > 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI. > > Morphic seems ideal for group #1. I think the key questions are: > * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it? > I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering. > * what would it take (if possible) to get there from the current implementation? > The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2. > Two issues I've noticed: > 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. > 2. I'm not clear whether the hooks for modifying behavior are > a. available in all the right places > b. working > c. widely understood > > I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users. > I'd like to be part of that. Are you setting up a mail list? > A quick example of my (seemingly common) experience: > For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph. > > I tried (one of these felt very satisfying): > * Morph>>on:send:to:, which sounded good, but never got called > * intercepting Morph>>processEvent:using: (which I was told was not a good idea) > * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). > * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass. > > Sean Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already. You'd really try Cuis. You'll find it much easier to understand and extend. Cheers, Juan Vuletich

Sept. 17, 2010

Re: [Pharo-project] Morphic

by Jimmie Houchin

On 9/17/2010 12:29 PM, DeNigris Sean wrote: > I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it. > > I think it's amazingly powerful and universally misunderstood. Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: > 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible > 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI. I don't know all the answers. But I do believe there is a tremendous amount of unsubstantiated claims about "native" UIs and there value or importance. First and foremost the biggest offenders of non-native UIs or rather look-and-feel for apps on almost any OS is the OS vendor themselves. Yet, there users seem to do fine. Come on, is iTunes a native look-and-feel for an OS? Or Safari, two apps from the creator of oh so elegant and beautiful. I don't really think so. I don't even think they are particularly attractive or intuitive. Or Quicktime. Or Internet Explorer. Or Windows Media. etc... I really can't go into any further detail as I am not currently using a Mac and I use as little MS software as I possibly can on my Windows OS machine. How about old Visual Basic or Hypercard apps? How about AIM, Yahoo Messenger, or whatever current cool tool is out there. Are they following any of the mantras tossed around by the we want native crowd? Not really. How about educational software and games. Both very common with lots of use. People seem to manage fine. Do I think Squeak/Pharo have to have arrived at their best UI. No, not at all. But I definitely do not believe "native" is better. And "native" never automatically means intuitive. It may be or not depending on the app. And non-native does not mean un-intuitive and poor quality. I do think we can do better. I do like the idea of having multiple OS windows available to the app developer. But I don't like being dependent on anybody else to fix a bug or port their UI or widgets to the next great OS. Heck I'm ready for Pharo 2.x/3.x to become my next OS. :) Whatever we do. I believe it is very important for us to maintain our control over our destiny. For me, wx, qt or whatever just simply reduces us to the same playing field as Python, Ruby, etc. I really believe we can be better. It is one of the reasons I use Squeak/Pharo/Smalltalk. To me the more we can do in Smalltalk the better. I say that fully understanding outside requirements. I am currently in the process of building an application in Pharo which requires the use of a Windows COM dll. This is a business requirement. Unfortunately, that is something I can not do in Pharo right now. Yes I know one of you wizard may be able to do something with Alien, FFI, or whatever. But it is something not currently accessible to people who only use the Smalltalk side of things. It is very easy to do in Python, which is what I used to write an intermediate application which communicates between the COM dll and my Pharo app. So I do understand, certain real world use case requirements for interfacing outside elements. I just don't believe the UI is really one, especially when counter examples are so incredibly abundant and are some of the biggest apps in use anywhere and often written by the OS vendor. I am not an implementer of any of these things, only a user. But these are some things I observe. YMMV, IMHO, all the standard disclaimers. :) :) :) Jimmie

Sept. 17, 2010

Re: [Pharo-project] Some thoughts...

by Michael Haupt

Hi Igor, On Fri, Sep 17, 2010 at 8:28 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > but i need help building VM & testing it on mac, since i don't have mac I'm game. Have a safe trip back, Michael

Sept. 17, 2010

Re: [Pharo-project] Morphic

by Schwab,Wilhelm K

Ironically, I am one of those "pushing" for native widgets. Ironic, because I do so not for the usual argument of speed (which I consider to be a fallacy in general), but because we need discipline. I think Morphs would be a wonderful thing inside a native MorphicWorldPresenter or some other entity in an MVP or similar framework based on native widgets and used for the main tool shells. People working on new UI concepts would create a "boring" tool shell with a world in it an knock themselves with Morphic. The text editors would be platform native so input focus, modality etc. would work as expected almost by default. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of DeNigris Sean [sean(a)clipperadams.com] Sent: Friday, September 17, 2010 1:29 PM To: The general-purpose Squeak developers list; pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Morphic I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it. I think it's amazingly powerful and universally misunderstood. Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI. Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it? * what would it take (if possible) to get there from the current implementation? Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users. A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph. I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass. Sean _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 17, 2010

Re: [Pharo-project] Some thoughts...

by Igor Stasenko

once i get home, i'll start working on it. both mac and linux implementations is quite similar. but i need help building VM & testing it on mac, since i don't have mac On 17 September 2010 02:29, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > lets get it working on the mac too please! > > On Sep 16, 2010, at 9:23 PM, Igor Stasenko wrote: > >> Amen :) >> >> >> >> On 15 September 2010 12:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> nativeBoost too :) >>> >>> Stef >>> >>> On Sep 15, 2010, at 11:08 AM, Tudor Girba wrote: >>> >>>> Indeed, this sounds really exciting. >>>> >>>> Doru >>>> >>>> >>>> On 14 Sep 2010, at 17:59, StÃ©phane Ducasse wrote: >>>> >>>>> thanks alex :) >>>>> We will.... >>>>> >>>>> Stef >>>>> >>>>>> Hi, >>>>>> >>>>>> I really would like to see projects like Opal and Ocean happening. Even though I may not have the time to directly contribute to them, they are important and I will use them. I am struggling these days to instrument the whole Pharo image and this is not easy. I am eagerly waiting for Opal. I got burned in the past with networks. >>>>>> >>>>>> So, please continue... >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel Â http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Yesterday is a fact. >>>> Tomorrow is a possibility. >>>> Today is a challenge." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > 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. 17, 2010