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

Re: [Pharo-project] A question about UIManager

by StÃ©phane Ducasse

I found theme "Answer the current theme for the receiver." (self valueOfProperty: #theme) ifNotNil: [:t | ^ t]. ^(self window ifNil: [self class]) theme in Morph theme: aUITheme "Set the current theme for the receiver." self theme = aUITheme ifFalse: [ self setProperty: #theme toValue: aUITheme. self themeChanged] and theme is defined on the Morph class so this means that we can change the UITheme current by self theme :) Stef

April 11, 2011

Re: [Pharo-project] Issue 3984 in pharo: Announcements announced when a test is runned

by pharo＠googlecode.com

Comment #2 on issue 3984 by ryd...(a)gmail.com: Announcements announced when a test is runned http://code.google.com/p/pharo/issues/detail?id=3984 Also, should this be done by an announcer of a TestRunner, or is SystemAnnouncer ok? To me, that seems a bit strange of a place to be announcing them :)

April 11, 2011

Re: [Pharo-project] Issue 3984 in pharo: Announcements announced when a test is runned

by pharo＠googlecode.com

Comment #1 on issue 3984 by ryd...(a)gmail.com: Announcements announced when a test is runned http://code.google.com/p/pharo/issues/detail?id=3984 Please... no Announcement at the end of class name :) Announcements are action notifications, and their names should indicate that. Also, Runned is not English, either Ran, or Finished, or Completed, etc.

April 11, 2011

Re: [Pharo-project] A question about UIManager

by StÃ©phane Ducasse

I was reading code on UITheme current everywhere and I was thinking: either we can add a method in Morph or we could add a trait for ThemeAndInteraction: uimanager, uitheme.... I think that using a trait would be good because we could have Morph that is the underlying layer and the tools and widgets that need to be theme managed using the trait. What do you think? There is already TEasyTheme but to me it looks too large. Stef

April 11, 2011

Re: [Pharo-project] Issue 3982 in pharo: Error: can''t find EOCD position

by pharo＠googlecode.com

Comment #6 on issue 3982 by ryd...(a)gmail.com: Error: can''t find EOCD position http://code.google.com/p/pharo/issues/detail?id=3982 This is what you see when squeaksource returns an error- I'm down page, and monticello tries to read that page as a zip file. If you encounter it again, wait a bit, then try upgrading again.

April 11, 2011

Re: [Pharo-project] fonts on Pharo website

by StÃ©phane Ducasse

It does not work on my safari :) Please revert ;D On Apr 11, 2011, at 1:55 PM, Adrian Lienhard wrote: > hehe, I wondered how long it takes to notice the new fonts ;) > > We can revert to the old font if the web font is not an improvement... Geert also noted that the font we embedded does not look the same on all browsers/platforms. > > Cheers, > Adrian > > > On Apr 11, 2011, at 13:47 , laurent laffont wrote: > >> Hi, >> >> For me the new fonts used on www.pharo-project.org are hard to read. The >> rendering on Firefox / Windows is not nice too. >> >> What do you think ? >> >> Laurent Laffont > >

April 11, 2011

Re: [Pharo-project] A question about UIManager

by StÃ©phane Ducasse

>>> the class in a single uiManager method in Morph is a good idea. So i >>> vote in favor of Morph>>uiManager ^ MorphicUIManager default. But it should not be MorphicUIManager default. because else we cannot use the DummyUIManager. So it should be UIManager default. In general referencing to subclasses defeat the purpose of UIManager On Apr 11, 2011, at 8:57 AM, Fernando Olivero wrote: > Actually i havent uploaded the fix yet, so this is good because now i > can modify the changeset to adopt Morph>>uiManager. > > Stef, what do you think about the class vars of SystemWindow, should > they also be moved to UIManager: for example TopWindow and associated > protocol. I do not know. > In Issue 3917:Make all uses of SystemWindow go thru UIManger, i > provided an initial implementation. I've replaced the refs of > SystemWindow to UIManager>>newWindowLabelled: aString, yes it looks good. > and eliminated the class vars in favor of ivars of the MorphiUIManager. I do not know for this one. Sytef > > Fernando > > On Mon, Apr 11, 2011 at 7:37 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> thanks! >> >> Stef >> >> On Apr 10, 2011, at 10:31 PM, Fernando Olivero wrote: >> >>> I believe that any UI element, should answer uiManager. And hardcoding >>> the class in a single uiManager method in Morph is a good idea. So i >>> vote in favor of Morph>>uiManager ^ MorphicUIManager default. >>> >>> Following the same line of thought we should do the same for the >>> globals World, ActiveWorld, ActiveEvent and ActiveHand. >>> I've provided with the code in Issue 3903: Removing the Globals >>> World, ActiveHand and ActiveEvent. As well as direct references to >>> WorldState. >>> >>> Fernando >>> >>> On Sun, Apr 10, 2011 at 9:21 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Hi pharoers >>>> >>>> I was trying to change MenuMorph direct reference to use UIManager because I was thinking >>>> that a popup menu should not open alone but this is the responsibility of the UIManager and I was not happy. >>>> why because we have these >>>> UIManager default >>>> >>>> and I started to think about them (ok I'm dead nearly sleeping at 9 in the evening because I took too much sun >>>> and walk today). My gut feeling is that at least for UI code, any UI element could have an access to the current UIManager >>>> via an instance variable or a message. >>>> self uiManager. >>>> Now may be the UI World should point to the UIMAnager and each graphical element should access it like that. >>>> For non UI class then this is a different story. >>>> >>>> But I would like to get your point of view on that point. >>>> >>>> Tx >>>> >>>> stef >>>> >>> >> >> >

April 11, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by StÃ©phane Ducasse

this is a good idea. Now pay attention that we should restart to work on integrating FS and that the file exception may change. Stef On Apr 11, 2011, at 4:10 PM, Sven Van Caekenberghe wrote: > Hi All, > > I have this idea that I would like to discuss on the next Pharo sprint and maybe start to implement if there is some consensus on it. > > It has been mentioned many times before on this list that Object>>#error: should be replaced by signalling specific Exceptions in as many cases as possible (or where it makes sense). Even today, there was http://code.google.com/p/pharo/issues/detail?id=3987 ! > > I think the core system should set the example here, by defining a number of general purpose exceptions and by using them. Going over #error: senders will be a lot of work but can be done in incremental/Pharo steps. > > So I went over the current hierarchy, scanned quickly through their references and some #error: senders by fundamental classes and looked at some other Smalltalks. I came up with the following very rough draft of an extended hierarchy (** marks new exceptions). In between brackets are the instance variables. Of course, we have to discuss about naming, instance variables and opportunities for reuse and inheritance (could be fun). > > I am no expert on exceptions and would certainly like to learn more. I am probably overlooking some aspects. We have to keep this Smalltalk like, flexible, dynamic, not start mimicing other languages. > > Any step in this direction will be an improvement over the current situation. Really using them correctly throughout the system will take some time. Defining the hierarchy could be done rather quickly. Refactoring is always possible later on. > > Exception (messageText) > Abort > Error > ArithemticError > ZeroDivide (dividend) > FloatingPointException > RangeError ** (from, to) > NaNError ** > FileStreamException (fileName) > FileDoesNotExistException (readOnly) > FileExistsException (fileClass) > CannotDeleteFileException > FileWriteError > FileReadError ** > FileClosedException ** > CannotAccessFileException ** > ReadonlyFileException ** > MessageNotUnderstood (message, receiver) > NonBooleanReceiver (object) > OutOfMemory > Halt > AssertionFailure > BreakPoint > SyntaxError ** !exists! (input, position) > NumberFormatException ** > HeadlessError ** > TimedOut ** (object, operation, timeout) > VerificationException > IllegalOperation ** (operation, object) > SizeMismatch (objects) > LowMemory ** (percentageFree) > SubclassResponsibility ** (message, receiver) > NotYetImplemented ** (message, receiver) > CannotInstanciate ** (class) > ReadOnlyObject ** (object) > OutOfFreeSpace ** (object, size) > InvalidArgument ** (message, receiver, argument) > NotIndexable ** (object) > NoKeyedAccess ** (object) > NonIntegerIndex ** (receiver, index) > SubscriptOutOfBounds ** (receiver, index, from, to) > NotFoundException ** (receiver, object) > KeyNotFound ** > ValueNotFound ** > ElementNotFound ** > StreamException (stream) > PositionError ** (index, from, to) > EndOfStream ** > BeginOfStream ** > > All feedback is welcome. > > Regards, > > Sven > > >

April 11, 2011

Re: [Pharo-project] [COTDC] 46 - SUnitUnloader

by Sven Van Caekenberghe

I am SUnitUnloader, a little tool to unload SUnit and a fixed set of Tests from the current image. Usage: SUnitUnloader new unloadAll Caveat: #unloadTestPackages uses a fixed and probably ill maintained list of what packages hold unit tests. On 11 Apr 2011, at 20:21, laurent laffont wrote: > Today: SUnitUnloader > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent

April 11, 2011

Re: [Pharo-project] UIBuilder Tool

by eMko

You can download it from squeaksource http://www.squeaksource.com/UIBuilder.html . If you want some practical information, watch youtube http://www.google.cz/search?q=uibuilder+pharo+youtube&ie=utf-8&oe=utf-8&aq=… One big drawback of Pharo smalltalk is lack of good documentation, but things are getting better and better. -- View this message in context: http://forum.world.st/UIBuilder-Tool-tp3442594p3442745.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 11, 2011