April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Announcement real problems - please read and comment.

by Denis Kudriashov

Hello,. 2011/4/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Henrik what is your answer to problem 1 > > Problem 1 > - the second announcement was never sent, because the first one > broke the second was blocked. > >> we should make sure that if an announcement leads to an error, > other annoucements on the same emit should pass > > Because we can get the system down just because one guy can register a bug. > I have similar problems in my domain. And my solution is asynchronous announcer. Each announcement subscriber should be notified in separate process. It is very easy to implement

April 2, 2011

[Pharo-project] Pharo sprint at Brussels Friday 15th of April

by StÃ©phane Ducasse

Hi guys Johan Brichau and Andy Kellens are organizing a sprint at VUB. Please let us know who will join. I will join Stef

April 2, 2011

Re: [Pharo-project] fancier tab morph

by Tudor Girba

This would be the idea. Gary has reviewed it briefly and said that it looks Ok and we should integrate it in the TabMorph (right now I use subclassing). Gary said that he will take a closer look at it soon. Cheers, Doru On 2 Apr 2011, at 09:25, StÃ©phane Ducasse wrote: > Doru what about integrating it in 1.3? > > Stef > > On Apr 2, 2011, at 8:34 AM, Tudor Girba wrote: > >> Hi, >> >> In the context of Glamour, I worked on a Morphic tab widget a bit more and here is the status (see the screenshots for some examples): >> - it computes the pages lazily only when you want to first show the page >> - it provides the possibility of closing the tab >> - it offers the possibility of rendering a toolbar for each page displayed to the right of the pages. >> >> If you want to play with them, you can: >> - download the latest moose image: >> http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… >> >> - execute the following to get an example of closable tabs: >> GLMBasicExamples new accumulator openOn: 42 >> >> - execute the following to get an example of tabs with different toolbars attached (to the right): >> GLMBasicExamples new tabsWithDifferentActions openOn: 42 >> >> >> There are still a couple of issues left: >> - When the title of a tab is too large, it pushes the bounds of the pane beyond what is visible. >> - Also, when we have multiple tabs, they again go overboard. >> - Similar things happen with the toolbar. >> >> However, the good news is that Gary is looking into this :) >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Relationships are of two kinds: those we choose and those that happen. They both matter." >> >> <ClosableTab.png><TabWithActions.png> > > -- www.tudorgirba.com "Presenting is storytelling."

April 2, 2011

Re: [Pharo-project] Issue 3939 in pharo: Small DSA refactorings from squeak

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #2 on issue 3939 by stephane...(a)gmail.com: Small DSA refactorings from squeak http://code.google.com/p/pharo/issues/detail?id=3939 Thanks!

April 2, 2011

Re: [Pharo-project] Solarized Color Scheme

by StÃ©phane Ducasse

Thank ethan I would really like to see your colors used in our environment. Now I think that we have to work on the mapping to constructs. BTW we had fun on (not so related) microprints (was just an experiment: http://scg.unibe.ch/archive/papers/Robb05b-microprintsESUG.pdf Stef On Apr 2, 2011, at 5:34 AM, Ethan Schoonover wrote: > Tudor Girba <tudor.girba@...> writes: > >>> the red in @param in java does not work so it is strange > > The red has been revised for beta2 (it's the only color I had an alternate for > -- two alternates actually, one of which was further tested and will be the > final color). The old red was L value 45 and was the only accent color that > dark. Red is very challenging in general (particularly given the contraints I > set in order to toggle light and dark) and I have truly spent *days* testing > reds for this scheme. No kidding. I dreamt Lab and hex values. The new > red is L 50 which translates to sRGB space as a much less saturated value. > >> I tested it with Sim Daltonism: >> http://michelf.com/projects/sim-daltonism/ >> It does pretty well (except for Protanopia). > > I'll take a look at that tool as well. For what it's worth, I did do some > testing (loaded the scheme into colorschemer and simulated color blindness) as > well during the development of Solarized. What I finally came back to was > ensuring that L*a*b lightness was accurate and consistent. > > My assumption was that L lightness would translate to an equivalent L lightness > (regardless of *a*b perceived value) in most color blindness, but this may not > be an accurate assumption. This would at least retain readability. I try to > limit colors > to "value added" accents only. > > Feedback from those interested in this issue specifically is welcome. I'm sure > I could do some more work in this area. > > Best, > Ethan Schoonover > es(a)ethanschoonover.com > >

April 2, 2011

Re: [Pharo-project] Solarized Color Scheme

by StÃ©phane Ducasse

good to know Stef On Apr 1, 2011, at 10:36 PM, Tudor Girba wrote: > Hi, > > On 1 Apr 2011, at 20:53, StÃ©phane Ducasse wrote: > >> the red in @param in java does not work so it is strange >> same remarks for ruby. >> Now the text color is nice and lavande are nice but I wonder for color blind people > > I tested it with Sim Daltonism: > http://michelf.com/projects/sim-daltonism/ > > It does pretty well (except for Protanopia). > > Cheers, > Doru > > > >> On Apr 1, 2011, at 1:27 PM, Tudor Girba wrote: >> >>> Interesting link. Thanks. >>> >>> Cheers, >>> Doru >>> >>> >>> On 1 Apr 2011, at 13:22, Sven Van Caekenberghe wrote: >>> >>>> I remember there were some discussions about (theme / syntax highlighting) colors on this list in the past, and someone said that picking good colors is an art. I came across this site: >>>> >>>> http://ethanschoonover.com/solarized >>>> >>>> And it seems to me that this could be a good basis for a professional color scheme in one of Pharo's look and feels. As a fan / user of Glamorous, using the light theme on top of it would seem great. >>>> >>>> I am just posting this as a way to bookmark this link and because it might be useful. >>>> >>>> Solarized is MIT licensed. >>>> >>>> Sven >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > >

April 2, 2011

Re: [Pharo-project] fancier tab morph

by StÃ©phane Ducasse

Doru what about integrating it in 1.3? Stef On Apr 2, 2011, at 8:34 AM, Tudor Girba wrote: > Hi, > > In the context of Glamour, I worked on a Morphic tab widget a bit more and here is the status (see the screenshots for some examples): > - it computes the pages lazily only when you want to first show the page > - it provides the possibility of closing the tab > - it offers the possibility of rendering a toolbar for each page displayed to the right of the pages. > > If you want to play with them, you can: > - download the latest moose image: > http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… > > - execute the following to get an example of closable tabs: > GLMBasicExamples new accumulator openOn: 42 > > - execute the following to get an example of tabs with different toolbars attached (to the right): > GLMBasicExamples new tabsWithDifferentActions openOn: 42 > > > There are still a couple of issues left: > - When the title of a tab is too large, it pushes the bounds of the pane beyond what is visible. > - Also, when we have multiple tabs, they again go overboard. > - Similar things happen with the toolbar. > > However, the good news is that Gary is looking into this :) > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that happen. They both matter." > > <ClosableTab.png><TabWithActions.png>

April 2, 2011

Re: [Pharo-project] who is using softSqueak and standard Squeak

by StÃ©phane Ducasse

Thanks. I will remove the old theme and keep this one. Stef On Apr 2, 2011, at 1:24 AM, Patrick Barroca wrote: > Hello, > > > I published the theme on squeaksource, it loads in 1.2 and 1.3. > Repo is http://www.squeaksource.com/PBASandbox > > I named it StandardUITheme, > > > > On Fri, Apr 1, 2011 at 8:57 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks > > I want to rename, repackage, glamourous and remove the bubble oriented color squeak look and keep one old sq colored for now. > On Apr 1, 2011, at 3:04 PM, Patrick Barroca wrote: > > > Hello, > > > > Just to say that I have now a simple theme extending UITheme with the look of Glamourous and the support of squeak windows colour management. > > > > Since I worked in 1.2 I have yet to verify how this load in Pharo 1.3 and then I will publish it ;) > > > > On Wed, Mar 30, 2011 at 3:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > My first look yesterday night taught me that different windows colour management is a basic behaviour of UITheme via #patchworkUIThemeColorFor:. > > > If I simply subclass UITheme and do nothing more I get more or less a standard squeak theme with coloured windows minus some fills and borders styles. > > > > > > From here I think I could try to make a simple theme with the look of Glamourous one with support for squeak windows colour management. > > > Is this the right direction ? > > > > yes :) > > I plan to refactor/clean the theme package too. > > So if you have results let us know. > > > > Stef > > > > > > > > -- > > Patrick Barroca > > > > > -- > Patrick Barroca > <PharoScreenshot.2.png>

April 2, 2011

Re: [Pharo-project] Issue 3934 in pharo: Add isDisplayed in SystemWindow

by StÃ©phane Ducasse

yes I was doing that with him and the protocol accessing World submorphs sucks a bit. > Also #isInWorld relates more to Morphic terminology, than #isDisplayed. > So if Ben agrees, i propose rolling back this change. > > Is not #isInWorld not sufficient? >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: <pharo(a)googlecode.com> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Friday, April 01, 2011 4:09 PM >>> Subject: [Pharo-project] Issue 3934 in pharo: Add isDisplayed in SystemWindow >>> >>> >>>> Status: FixProposed >>>> Owner: Benjamin...(a)gmail.com >>>> Labels: Nautilus >>>> >>>> New issue 3934 by Benjamin...(a)gmail.com: Add isDisplayed in SystemWindow >>>> http://code.google.com/p/pharo/issues/detail?id=3934 >>>> >>>> isDisplayed >>>> " Answer true if I am a submorph of World, ie if I am displayed " >>>> >>>> Attachments: >>>> SystemWindow.BenjaminVanRyseghem.1.cs 303 bytes >>>> >>> >>> >> >> >> >

April 2, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by StÃ©phane Ducasse

>> Hi guys >> >> We found a problem with ben and RPackage. >> Here is the scenario and may be you can help us finding the right solutions. >> >> Nautilus renames a class >> the class got renamed >> -> an announcement is raised >> - nautilus gets notified, it asks rpackageOrganizer (which also listens to the same event) >> -> rpackageOrg breaks because the class if was referting to does not exist anymore. > This sounds like mess in logic. > You ask package of class that is in the process of being renamed? No Just the browser ask the package its classes to display them and the package has not been refreshed because this is done by the announcement that is after the one that led to a refresh > Why would you expect this to work? > Use more announcements to represent multiple steps in renaming process, for example both ClassRenaming and ClassRenamed. > Changing it's package is something you do as an action that should be _part_ of renaming, while updating it's location is something you would do _after_ renaming is complete. Probably we will check that. >> Problem 2 >> If rappckageOrganizer would be reached before Nautilus we would not get any problem (beside the problem 1). >> >> - we spent one hour playing with alternatives. >> We thought that if RPackage would points to classes a rename would not break the system. >> While this is true for class, the same problem will occur for method rename since compiled method are not shared and a new compiled method >> is compiled. >> >> - If RPackage was as deep inside the system as superclass/subclass, the invariant would be directly maintained by the system >> and we would not have to rely on announcement. But now we should find a solution. >> >> >> may be we should be able to say that an announcement has a priority. >> Typically we would like to say that when RPackageOrganizer register interests it should be served first. >> we could have a systemLevel priority that could be specified on registration. >> >> what do you think? > Bad, bad, bad, bad, baaaaaad idea. > I know from experience that once you concede that announcement listener order should matter, you are setting yourself up to fail. > Although you know one listener _HAS_ to respond first, there will always be someone else who want to respond "firstester". > Not to mention the logic in this case becomes next to impossible to follow/debug/ maintain, as you've already experienced. > > For a proper solution, introduce more Announcements for actions which should happen in different phases of a process, as explained above. > > Cheers, > Henry > > PS. I was unable to load RPackage. In which image? > The initialize method of PackageOrganizer in RPackage-Core calls registerInterestToSystemAnnouncement, which is an extensions in RPackage-SystemIntegration. Yes this is normal. I will try to load it to check. May the configurationOfRPackage has not been updated > PPS. There's a neat method called #on:send:to:, which would be perfect for the different actions in RPackage-SystemIntegration. But why should we rely on a different event system? > PPPS. Is the code for Nautilus available anywhere? Yes in Nautilus on squeaksource.

April 2, 2011