Pharo-dev

By thread

pharo-dev@lists.pharo.org

1 participants
144619 messages

Re: [Pharo-project] About using RB changes in Gaucho and Pharo

by StÃ©phane Ducasse

On Sep 5, 2010, at 9:45 AM, Fernando olivero wrote: > When i started working on the new Gaucho, i tried to use/understand the current change model without success. yes we can all forget. This part is ugly and brittle > So i chose to use the RB engine ( thanks lukas for nicely maintaining it!) > > In the soon to be released Gaucho1.1 i'm using RB changes to record every change made to the system, changes that take part during a Gaucho development session. > So i will be able to provide an insight to the feasability of using RB changes to record and persist sessions, and easily provide undo's . Maybe this work could be plugged into a new Pharo changes system! Yes we plan to use RBChange as a foundation infrastructure. I with veronica plan to also have a declarative code model so that we can do decent recentChanges and the rest. BTW there is a nice Undo framework of a couple of classes in sophie I added a first fileout to the bug entry. > > > Fernando > > pd: > BTW, i enhanced the RB changes with AddPackageRefactoring and others related to the UI, ( in this way i'm also recording every UI event ). After the ESUG i will try to integrate the relevant ones to RB. what are the UI event? because I would like to replacement SystemChangeNotifier events by announcements (check systemAnnouncement) as in ConfigurationOfRPackage. > > >> >>> 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. >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 5, 2010

Re: [Pharo-project] [update 1.1] #11412

by Schwab,Wilhelm K

+1 Please leave out the new inspector. Inspectors should be simple, and the explorer does a nice job of presenting a recursive tree; that's enough IMHO. One inspector change I did like was a port to Dolphin of VW's (???) "diving inspector." Double clicking on items did not open a new inspector; it simply changed the model of the current inspector. There was a context menu item to inspect which *did* open a new inspector, so nothing was lost and most of the time, it did exactly what was intended. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Marcus Denker [marcus.denker(a)inria.fr] Sent: Sunday, September 05, 2010 11:50 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [update 1.1] #11412 On Sep 5, 2010, at 5:44 PM, Tudor Girba wrote: > Sounds cool. Will there be a Pharo 1.1.1 release? > > Yes, as soon as possible... the idea is to first do a core with all the small things people found. The idea here is to just collect what is fixed. Not fix more. (there can always be a 1.1.2 later... no need to no do the next tiny thing) Then do a 1.1 main image, here we can use the latest OB/RB from Lukas. Another thing I think we should do it to not add the newInspector this time. 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

Sept. 5, 2010

Re: [Pharo-project] [update 1.1] #11412

by Marcus Denker

On Sep 5, 2010, at 5:44 PM, Tudor Girba wrote: > Sounds cool. Will there be a Pharo 1.1.1 release? > > Yes, as soon as possible... the idea is to first do a core with all the small things people found. The idea here is to just collect what is fixed. Not fix more. (there can always be a 1.1.2 later... no need to no do the next tiny thing) Then do a 1.1 main image, here we can use the latest OB/RB from Lukas. Another thing I think we should do it to not add the newInspector this time. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 5, 2010

Re: [Pharo-project] [update 1.1] #11412

by Tudor Girba

Sounds cool. Will there be a Pharo 1.1.1 release? Cheers, Doru On 5 Sep 2010, at 16:55, Marcus Denker wrote: > > On Sep 5, 2010, at 4:47 PM, Lukas Renggli wrote: > >>> Issue 2912: Cog changes for 1.1.1 >> >> Cool, that means Cog works out of the box? >> > > This are the changes that Moose uses... so yes, I think so. (did not > test it yet, though). > > 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 -- www.tudorgirba.com "Beauty is where we see it."

Sept. 5, 2010

Re: [Pharo-project] [update 1.1] #11412

by Henrik Johansen

A couple of issues that applies to 1.1.1 was marked as closed when they were integrated in 1.2, I reverted to fixed in case you are up for another round :) Cheers, Henry Den 5. sep. 2010 kl. 16:34 skrev Marcus Denker <marcus.denker(a)inria.fr>: > 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. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 5, 2010

Re: [Pharo-project] [update 1.1] #11412

by Marcus Denker

On Sep 5, 2010, at 4:47 PM, Lukas Renggli wrote: >> Issue 2912: Cog changes for 1.1.1 > > Cool, that means Cog works out of the box? > This are the changes that Moose uses... so yes, I think so. (did not test it yet, though). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 5, 2010

Re: [Pharo-project] [update 1.1] #11412

by Lukas Renggli

> Issue 2912: Â Â Cog changes for 1.1.1 Cool, that means Cog works out of the box? Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 5, 2010

[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

Jump to page: