- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3706 in pharo: In OB: Text in comment pane of Browser uses syntax highlighting

by pharo＠googlecode.com

Comment #2 on issue 3706 by Benjamin...(a)gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 I will tak e a look, but OB is so in-understandable ...

March 3, 2011

[Pharo-project] GUI ?

by Olivier Auverlot

Hi, Someone have a good documentation or tutorial for learning how to create GUI avec Pharo ? In particuliar, I search a description of the objects like buttons, fields, treeview , radio buttons, checkbox and the events mechanism. On the ML, i can read messages about Morphic and Polymorph ? what is the difference ? Best regards Olivier ;-) www.auverlot.fr

March 3, 2011

[Pharo-project] LDAPlayer

by Olivier Auverlot

Hi, I have uploaded today an updated version of LDAPlayer with some minor corrections for Pharo 1.1.1. All seems work perfectly. If you need an LDAP connector for Pharo, it's a good solution. I will try to produce a tutorial in the next days. http://www.squeaksource.com/@I6MXr0KZ8IlD2Fnn/CKF0ucuM Best regards Olivier ;-) www.auverlot.fr

March 3, 2011

Re: [Pharo-project] Glamour-Morphic-Theme package rename?

by StÃ©phane Ducasse

The idea is that alain would like to have only one theme but fully parametrized and that we can unify all that. Typically orange should not be a subclass :). Now you are probably right and I want to remove some other not working theme: Pro and a couple of others. On Mar 2, 2011, at 7:43 PM, DougEdmunds wrote: > Shouldn't the Glamour-Morphic-Theme package be renamed to fall > under Polymorph-Widgets, like the other themes? > > It seem that otherwise, the package system will get cluttered > with individual theme names. I think of the packaging system > as most generic to more specific (using the hyphens). > > Glamour-Morphic-Theme seems to stick out as not following > this naming convention. > > -- > View this message in context: http://forum.world.st/Glamour-Morphic-Theme-package-rename-tp3332037p333203… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 3, 2011

Re: [Pharo-project] Inspect it wrong shortcut

by StÃ©phane Ducasse

Tx for reporting. can you open a bug entry? Stef On Mar 3, 2011, at 10:27 AM, tn wrote: > KeyboardEvent keyValue for 'ctrl + i' is evaluated to 9 as ASCII control > code, > and the value conflicts to Character tab value. > I tried to correct source code for this problem. > Below is the workaround for Pharo-1.1.1-OneClickCogVM on Windows XP. > -------------------- > InputEventSensor>>processEvent: > > processEvent: evt > > ... > > "Finally keyboard" > type = EventTypeKeyboard > ifTrue: [ > (evt at: 4)=0 ifTrue: [ "-- add --" > "Sswap ctrl/alt keys if neeeded" > KeyDecodeTable > at: {evt at: 3. evt at: 5} > ifPresent: [:a | > evt > at: 3 put: a first; > at: 6 put: a first; "-- add --" > at: 5 put: a second]. > ]. "-- add --" > "Update state for polling calls" > modifiers := evt at: 5. > ^evt]. > ... > > In order to work this code, Preference Control and Alt keys must be set to > "Full matching". > Because ASCII control characters (e.g. ^i) is mapped to character code with > KeyDecodeTable, only at the time. > > About key event, see InputEventFetcher class comment. > And it is interesting that to contrast implementations between Pharo and > Squeak4.2. > Each implementation is below. > > Pharo: InputEventSensor>>processEvent: > Squeak4.2: EventSensor>>processEvent: > > Thanks, > > > -- > View this message in context: http://forum.world.st/Inspect-it-wrong-shortcut-tp1306494p3333001.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 3, 2011

Re: [Pharo-project] About RPackage

by StÃ©phane Ducasse

On Mar 1, 2011, at 10:57 PM, Tudor Girba wrote: > Hi Stef, > > This was the decisions that two of us (I mean me and you) took :). > > Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system. Doru I'm afraid that it will not work because it means that suddenly people will have to change all the configurationOf. We should come up with a smooth transition phase (now this is true that if we could get rid of categories it would be good) > The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages. > > The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package. the problem is that it implies that we will have to change all the configurationOfXXX (or we should shrink all the packages > > Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way. > > Cheers, > Doru > > > > On 1 Mar 2011, at 22:44, StÃ©phane Ducasse wrote: > >> Hi cyrille/doru and others. >> >> I do not understand why >> RPackage organizer packages contains System? >> >> In fact all the categories are mapped to packages and I wonder why. >> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >> but it means that in such a case we should merge categories to get back the package we have right now >> else we will end up with loading/saving problems. >> >> >> Stef > > -- > www.tudorgirba.com > > "Presenting is storytelling." > >

March 3, 2011

Re: [Pharo-project] Inspect it wrong shortcut

by tn

KeyboardEvent keyValue for 'ctrl + i' is evaluated to 9 as ASCII control code, and the value conflicts to Character tab value. I tried to correct source code for this problem. Below is the workaround for Pharo-1.1.1-OneClickCogVM on Windows XP. -------------------- InputEventSensor>>processEvent: processEvent: evt ... "Finally keyboard" type = EventTypeKeyboard ifTrue: [ (evt at: 4)=0 ifTrue: [ "-- add --" "Sswap ctrl/alt keys if neeeded" KeyDecodeTable at: {evt at: 3. evt at: 5} ifPresent: [:a | evt at: 3 put: a first; at: 6 put: a first; "-- add --" at: 5 put: a second]. ]. "-- add --" "Update state for polling calls" modifiers := evt at: 5. ^evt]. ... In order to work this code, Preference Control and Alt keys must be set to "Full matching". Because ASCII control characters (e.g. ^i) is mapped to character code with KeyDecodeTable, only at the time. About key event, see InputEventFetcher class comment. And it is interesting that to contrast implementations between Pharo and Squeak4.2. Each implementation is below. Pharo: InputEventSensor>>processEvent: Squeak4.2: EventSensor>>processEvent: Thanks, -- View this message in context: http://forum.world.st/Inspect-it-wrong-shortcut-tp1306494p3333001.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 3, 2011

Re: [Pharo-project] About RPackage

by StÃ©phane Ducasse

>> >> Ok I do not remember the protocol. >> we should ask the PackageOrganizer to create a package? >> or just to register it. > > The RPackage class>>named: is an internal method used only by the RPackageOrganizer for creating a package. > > If you want to ensure a package, you should use (I do not like the name :)): yes this is more than registering. this is ensurePackageNamed: > RPackageOrganizer>>registerPackageNamed: aSymbol > ^ packages at: aSymbol asSymbol ifAbsentPut: [RPackage named: aSymbol] > > You can get to the default organizer via "RPackage organizer". > > So, something like: RPackage organizer registerPackageNamed: 'MyPackage' should do it. > >> I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it. >> So in the PackageInfo logic there are two points; >> - registration >> - query/creation >> >> I have no problem to discard - query/creation >> So to which of these two aspects are you referring to. > > In the current RPackage implementation, #named: is a method meant to be used only internally. The problem with tying creation to registration is that you cannot use multiple Organizers easily (this was the reason why we decoupled the two). > > What we could do is to rename #named: to #newWithName: and have named: be only a compatibility method that does: > > named: aString > ^ RPackage organizer registerPackageNamed: aString Yes good idea. > > > Cheers, > Doru > > > >> Stef >> >>> >>> Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. >>> >>> Cheers, >>> Doru >>> >>> >>> On 1 Mar 2011, at 22:59, StÃ©phane Ducasse wrote: >>> >>>> Another point >>>> >>>> RPackage>>named: aString >>>> >>>> | newPackage | >>>> newPackage := self new name: aString ;yourself. >>>> "self organizer registerPackage: newPackage." >>>> ^ newPackage >>>> >>>> does not register the package and this looks suspicion to me. >>>> >>>> >>>> In addition I do not remember the exact logic but the pattern with PackageInfo is that >>>> >>>> PackageInfo named: #foo creates the package if it does exist >>>> >>>> PackageInfo class>>named: aString >>>> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] >>>> >>>> So do you remember because it may be better to have the same creation protocol. >>>> >>>> Stef >>>> >>>> >>>>> Hi cyrille/doru and others. >>>>> >>>>> I do not understand why >>>>> RPackage organizer packages contains System? >>>>> >>>>> In fact all the categories are mapped to packages and I wonder why. >>>>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >>>>> but it means that in such a case we should merge categories to get back the package we have right now >>>>> else we will end up with loading/saving problems. >>>>> >>>>> >>>>> Stef >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Being happy is a matter of choice." > > > >

March 3, 2011

Re: [Pharo-project] [TODO 1.2] Things to do for 1.2

by StÃ©phane Ducasse

> Hi, > > I wonder if we will ever make it... No dispair :) Just good energy > > Issues needed to be fixed for the Core Image: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.2 Issue 3763: assert failure during Decompiler>>popIntoTemporaryVariable: so far this is not a show stopper. we should have a simpler reproduceable case. so we can move it to 1.2.1 > > Issues needed to be fixed for the Full Image: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage 3620 ---- Accepted Settings: OCompletion settings appear twice not a show stopper > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

March 3, 2011

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by pharo＠googlecode.com

Comment #13 on issue 3620 by stephane...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 yes.

March 3, 2011