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

[Pharo-project] [update 1.1] #11412

by Marcus Denker

11412 ----- Issue 2912: Cog changes for 1.1.1 Issue 2896: Make sure system notifications for Smalltalk are up-to-date Issue 2893: Network bugs -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 5, 2010

Re: [Pharo-project] Is there a way to limit taskbar

by Schwab,Wilhelm K

Stef, That's impressive :) I have long believed our goal should be to produce something like Chris Uppal's Ghoul: http://metagnostic.dolphinmap.net/Ghoul.html Just in case the link does not work, I have attached the screenshot of Ghoul itself in action. Some background: Dolphin creates two different types of error logs. First is a simple log of callstacks with no information about parameters. The result can be reasonably compact and is often sufficient to sort out problems. However, there were situations in which crashes could take out the vm w/o leaving a trace of what happened, so a second, more detailed log called a crash dump was born. Dolphin's crash dumps are relatively detailed snapshots of the callstack with arguments. Parameters limit the size by leaving out "the middle." Crash dumps can be triggered programmatically at any time (with no harm to the running image), and as the name suggests, if Dolphin actually crashes. In the Dolphin spirit of providing information about what it is doing, new entries are appended to an existing log. Ghoul opens a crash dump log, parses the multiple dumps that it contains, and shows a debugger like view on the result. It is WONDERFUL. Note the drop-down list at the top of the screenshot; it can be lengthy, and selects individual callstacks from the log. With a given dump selected, Ghoul shows the callstack in the left pane and debugger-like inspector and code panes on the right. The code is from the image that loads the dump, which can be misleading if there have been major changes since the log was recorded, but it is a very useful tool. Another gem is F.M.B. (filtered method browser) on the same web site. Another great place to look for inspiration on tools is Ian Bartholomew's site: http://www.idb.me.uk/goodies.html His ChunkBrowser is legendary, providing something very similar to Pharo's GUI for recovering lost changes, only with a much better design. Chunks can be filtered, sorted and selected in very powerful and understandable ways. There is no going back once you have used it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [Stephane.Ducasse(a)inria.fr] Sent: Sunday, September 05, 2010 3:35 AM To: Pharo Development Subject: [Pharo-project] Is there a way to limit taskbar Hi guys in one of our server we got that! - two reactions - we should limit the number of taskbar elements - would be good to have also a real logger (if this is not the case here) instead of transcript to report structured log I will have a look at SimpleLog of goran Stef Begin forwarded message: > From: Damien Pollet <damien.pollet(a)inria.fr> > Date: September 4, 2010 8:00:33 PM GMT+02:00 > To: notre liste <lsehub-staff(a)lists.gforge.inria.fr> > Subject: Re: [Lsehub-staff] apparently http://rmod.lille.inria.fr/ does not answer... anymore. > Reply-To: notre liste <lsehub-staff(a)lists.gforge.inria.fr> > > VNC works, but here's what it looks like. I don't have access to the world menu, I could open a workspace but it appears somewhere else than visible. > > Pharo needs a proper message logger I guess :) > >

Sept. 5, 2010

Re: [Pharo-project] polymorph theme feedback

by Tudor Girba

Another point: the tab button should be different from the regular button. Right now, I added a hack in the button drawing that goes like this: buttonNormalFillStyleFor: aButton "Return the normal button fillStyle for the given button." (aButton valueOfProperty: #noFill ifAbsent: [false]) ifTrue: [^ SolidFillStyle color: Color transparent ]. ^ self glamorousNormalFillStyleFor: aButton height: aButton height And when I create the tab button, I populate the #noFill property: (aWin newButtonFor: each getState: nil action: #actOn: arguments: {aBrowser} getEnabled: nil labelForm: each icon help: each title) valueOfProperty: #noBorder ifAbsentPut: [true]; valueOfProperty: #noFill ifAbsentPut: [true]; yourself Still, this is a hack :). Cheers, Doru On 4 Sep 2010, at 23:25, Tudor Girba wrote: > Hi again, > > While working on the Glamorous Theme, I basically had to learn the > design of polymorph and or the theme system. I think the structure > is pretty nice, but it still requires work to offer more > flexibility. I list here some of the notes I took. I would be happy > to provide more feedback and even work with someone on this: > > - How to control the rounded/square corners of the droplist, normal > list and text boxes? > > - How to control a Splitter drawing? > It looks like it does not matter what we specify in > separatorFillStyleFor:, it is still drawn embossed. > > - How to control the menu title? > I would like to be able to control the color of the title of the > menu (the one that appears for example in the world menu). > > - How to control the menu rendering? > I would like to be able to control the fill style of the menu. > > - How to control the color of the PanelMorph when the Window is not > active? > Right now it just gets lighter. I would like to be able to control > it, but it looks impossible from the Theme. > > - How to control the padding of a panel, groupbox, or tab? > > - How to control the space between buttons in a toolbar? > > - How to control the menu button in a toolbar? > When there is a button with a menu in a toolbar, a default button is > created with a gradient that cannot be controlled from the theme. > > - How to control the menu close button after the menu was pinned? > > - How to control the display of a splitter in a menu? > The MenuLineMorph hardcodes the minWidth and minHeight. It should be > delegated to the Theme. > > - MorphTreeMorph needs to work with Theme (e.g., in adoptPaneColor:) > > - How to control the arrows of scrollbars? In particular, we would > need to be able to define the forms in the theme, not just the > vertices. > > - The settings for the menu rendering seem to affect the rendering > of the progress bars. There should be separate entries for the two > in the Theme. > > - It is unclear what the ThemeSettings is for. What goes here and > what goes in the Theme? > > - Some icons are defined in the Theme instance variables, and some > are defined in the ThemeIcons. > > - Is it intended for the ThemeSettings to be subclassed? > > - Some preferences from ThemeSettings are hardcoded. For example: > menuShadowColor or menuTitleBorderColor. > > - How to control the tick of a checkbox or of a radio button? > Right now, there is a tick that gets drawn even if I specify the > radioButtonSelectedForm or checkboxSelectedForm > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > -- www.tudorgirba.com "Obvious things are difficult to teach."

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Igor Stasenko

On 5 September 2010 12:23, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 05 Sep 2010, at 09:54, StÃ©phane Ducasse wrote: > >> screenshots PLEASE! > > http://homepage.mac.com/svc/Screenshots/Screenshot-20100905T111347.png > No round corners! kewl! :)) > Doru, > > I made the #baseSelectionColor almost black (I didn't like the blue, de gustibus non est disputandum ;-) by overwriting it: > > baseSelectionColor > Â Â Â Â ^ "Color r: 0.38 g: 0.64 b: 0.88" Color darkGray muchDarker > > I could subclass as well I guess, or you could make it into a variable with a setter, what do you think ? > > Anyway, very well done, it feels very fast, which was a goal I presume. > > Sven > > PS: the name is a nice pun too! > _______________________________________________ > 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. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Sven Van Caekenberghe

On 05 Sep 2010, at 12:02, Tudor Girba wrote: > In my mind, the theme should be the entry point that attaches a name to a consistent design. We already have ThemeSettings which already introduce a lot of complexity and which leads to a mess. I would actually prefer to have only a hierarchy of Themes without any, or in exceptional cases very limited, parametrization options. > > Perhaps the selection color could be made a parameter, but at the moment I would still prefer subclassing. OK, I understand, UIThemes are already complex enough. I'll subclass, the hooks are there (you made some extra elements explicit, so that is good). Sven

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Tudor Girba

Hi, On 5 Sep 2010, at 11:23, Sven Van Caekenberghe wrote: > > On 05 Sep 2010, at 09:54, StÃ©phane Ducasse wrote: > >> screenshots PLEASE! > > http://homepage.mac.com/svc/Screenshots/Screenshot-20100905T111347.png > > Doru, > > I made the #baseSelectionColor almost black (I didn't like the blue, > de gustibus non est disputandum ;-) by overwriting it: > > baseSelectionColor > ^ "Color r: 0.38 g: 0.64 b: 0.88" Color darkGray muchDarker :) No comment. > I could subclass as well I guess, or you could make it into a > variable with a setter, what do you think ? In my mind, the theme should be the entry point that attaches a name to a consistent design. We already have ThemeSettings which already introduce a lot of complexity and which leads to a mess. I would actually prefer to have only a hierarchy of Themes without any, or in exceptional cases very limited, parametrization options. Perhaps the selection color could be made a parameter, but at the moment I would still prefer subclassing. > Anyway, very well done, it feels very fast, which was a goal I > presume. Thanks. Speed was a goal indeed. Cheers, Doru > Sven > > PS: the name is a nice pun too! :) -- www.tudorgirba.com "Reasonable is what we are accustomed with."

Sept. 5, 2010

Re: [Pharo-project] glamorous theme :)

by Tudor Girba

Indeed, I struggled with this, too, and I have no idea why it happens. It should overlap with the normal border. It looks like some kind of Morphic voodoo :) Doru On 5 Sep 2010, at 09:37, Sven Van Caekenberghe wrote: > > On 05 Sep 2010, at 09:08, Tudor Girba wrote: > >> Hi Sven, >> >> I am not sure I understand what you are referring to. Could you be >> more explicit? > > Sorry: if you switch to the Pro theme (UIThemePro from the Polymorph- > Themes-Pro package, PharoInbox) and do "UITheme > exampleBasicControls." you get the following window: > > <Screen shot 2010-09-05 at 09.28.50.png> > > The Default Button has an ugly blue border (well the blue border has > the wrong shape). Every dialog has this ugly button that's why it is > a pity because the Theme is otherwise quite nice. > > I really got lost trying to fix this (I lack knowledge of all this > drawing code). But you probably encountered similar problems. > >> The reason I chose square shapes is that as long as we do not have >> proper and fast antialiasing, it requires images (like in the >> watery2 theme) which are time consuming to produce, or it just does >> not look nice. > > Having a fast theme is also a definitive plus, sure. > >> Cheers, >> Doru >> >> On 5 Sep 2010, at 08:23, Sven Van Caekenberghe wrote: >> >>> Hi Doru, >>> >>> Nice indeed, clean & professional, x-platform. I see that you >>> managed to get 'button with focus' (blue border) drawn correctly, >>> even though you subclass 'Watery2' which has round buttons, which >>> was a problem with the Pro theme. I tried to solve it, but I got >>> lost. Maybe you can see what is wrong there ? (see my mail aug 30). >>> >>> Regards, >>> >>> Sven >>> >>> On 04 Sep 2010, at 23:18, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> Over the past week I worked on a new theme for Pharo called the >>>> Glamorous Theme :). The theme is developed in the context of the >>>> Glamour project, and its goal is to create a look that: >>>> - does not look like a specific operating system. In particular, >>>> the icons should be operating system agnostic, because, for >>>> example, people in Windows are confused by the red, yellow, green >>>> buttons of apple. >>>> - uses a limited amount of colors and effects. >>>> >>>> It is still work in progress, but you can get the current version >>>> by executing: >>>> >>>> Gofer new >>>> squeaksource: 'Glamour'; >>>> package: 'Glamour-Morphic-Theme'; >>>> load. >>>> GLMUITheme defaultSettings: nil. >>>> GLMUITheme beCurrent. >>>> GLMUITheme setPreferredWorldBackground. >>>> >>>> Cheers, >>>> Doru > > _______________________________________________ > 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 "Not knowing how to do something is not an argument for how it cannot be done."

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Sven Van Caekenberghe

On 05 Sep 2010, at 09:54, StÃ©phane Ducasse wrote: > screenshots PLEASE! http://homepage.mac.com/svc/Screenshots/Screenshot-20100905T111347.png Doru, I made the #baseSelectionColor almost black (I didn't like the blue, de gustibus non est disputandum ;-) by overwriting it: baseSelectionColor ^ "Color r: 0.38 g: 0.64 b: 0.88" Color darkGray muchDarker I could subclass as well I guess, or you could make it into a variable with a setter, what do you think ? Anyway, very well done, it feels very fast, which was a goal I presume. Sven PS: the name is a nice pun too!

Sept. 5, 2010

Re: [Pharo-project] systemNavigation cleaning

by Lukas Renggli

I've split the refactoring model into various packages as outlined in the previous mail. The dependencies between the tests are slightly problematic, but will eventually be fixed as depicted in red in the attached dependency graph. It shouldn't matter for loading, so there is no hurry. Thank you for updating the configuration Mariano. Note that OB-Refactory depends on all the non-test packages. Lukas On 4 September 2010 14:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Sep 4, 2010, at 1:08 PM, Lukas Renggli wrote: > >>>> I agree that SystemNavigation is ugly, but *a lot* of existing code >>>> depends on it. >>> >>> Well if I start forking all the classes that we should fix because there are used it will be endless. >>> I was thinking to start also to look at senders and use deprecate. >>> >>> do you have a lot of external tools that use it? >> >> Yes, all tools use it: >> >> Â Monticello, Paragraph Editor (new and old), OmniBrowser, >> eCompletion, Refactoring Engine. >> >> Now I removed its use from the BrowserEnvironment in the refactoring >> engine itself. There are still a couple of references though, where >> people used the wrong abstraction layer when implementing stuff >> (platform code instead of the abstraction of the refactoring engine). >> >>> So what do you suggest? >>> Separating BrowserEnvironment and its superclass from RB and starting to >>> Â Â Â Â - check its api >>> Â Â Â Â - improve it >>> Â Â Â Â - migrate caller of systemNavigation -> BrowserEnvironment (rename browserEnvironment) >> >> Yeah, maybe one step would be to split the refactoring engine into >> smaller and independent packages: >> >> Â AST-Core (that already is separate) >> Â Refactoring-Environment (this is currently part of > > yes this would be good so that we can start do the idea with the integration related to systemDictionary been a potential leave of the composition > tree we talked last time you visit us. > >> Refactoring-Core, but would work independently) >> Â Refactoring-Changes (this is currently part of Refactoring-Core, >> but would work independently) > > yes I'm curious to see if/how we could use changes to represent changeset. > > >> Â Refactoring-Refactorings (this is currently part of >> Refactoring-Core and depends on all of the above) >> Â Refactoring-Lint (this is currently part of Refactoring-Core and >> depends on all of the above) >> >> Like this Pharo could integrate Refactoring-Environment and >> Refactoring-Changes independently. > > :) > >> I'll see if I can repackage the refactoring browser a bit, might take >> a while though because the tests are not that nicely separated. > > I imagine. > Now incremental changes is the only way for us :) >> >> Lukas >> >> -- >> Lukas Renggli >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Sept. 5, 2010

[Pharo-project] Issue 2909

by Pavel Krivanek

Hi, please integrate this issue: http://code.google.com/p/pharo/issues/detail?id=2909 The original version by Stef included two tests of the same selector: self deny: (sels includes: #submorphs). self deny: (sels includes: #submorphs). Was it a purpuse? -- Pavel

Sept. 5, 2010