- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About KeyBindings

by Tudor Girba

Hi Fernando, Sounds nice. I would be interested in having a bindings-per-morph solution. Cheers, Doru On 31 Jan 2011, at 16:18, Fernando Olivero wrote: > Hi, recently there were some discussion on implementing KeyBindings for our IDE. > > There are at least 3 frameworks which address this functionality, the > last one mentioned is the work done by Guillermo. > I've implemented another one, for Gaucho. > > From what i understand, the previous work focuses on implementing > GLOBAL keybindings . > Basically adding behavior to HandMorph or PasteUpMorph or the toolbar > ( docking bar) present in the World. > > My implementation is a generic keybinding for any Morph, which can be > applied to any morph. Special cases for the docking bar or the paste > up Morph can be easily implemented following this uniform scheme. > > I didn't have the time to integrate it into Pharo yet, but will do in > one week from now. > > I like to bring up the discussion on which one we should adopt and > integrate into Morphic, points in favor of my approach: > 1) clean > 2) customizable > 3) generic: no special cases > > I believe the other Global keybindings should be a subset of this > generic keybinding mechanism. > > Fernando > > pd: From a previous mail: > > "... > So for example, if you want to delete any Morph from the system > by pressing cmd-w, you have to add the following binding: > > condition := GMCondition > compositeWith: > #( #understandsKeyBindingCommandCondition > #uneditedCondition ) ). > binding := GMKeyBinding > actingOn: $w asciiValue > modifiedBy: #(#command) > satisfying: condition > applying: #close. > m := Morph new. > m addKeyBinding: binding . > ... > " > > pd2: Useful and related comment from Stef > ".. > A classVar Binding and an instance var binding. > **All** the methods only access binding > binding get initialized with the default table defined in Binding > => we can have table binding sharing > => we can have instance based customization. > -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Jan. 31, 2011

Re: [Pharo-project] TODO 1.2

by Lukas Renggli

> Can I suggest that we really remove the non show stopper? > and I'm sorry but we cannot maintain packages we do not know. > > Lukas could you integrate the fix I did for OB? I suggest that you publish the changes to your own repository. I would like to keep the code in http://source.lukas-renggli.ch/omnibrowser/ working in Pharo 1.1. I started to fix several of the tools for Pharo 1.2 in http://source.lukas-renggli.ch/pharo12, but there is so much broken that I run out of time :-( Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 31, 2011

Re: [Pharo-project] About KeyBindings

by Denis Kudriashov

Hello, very interesting work. Can you provide some description? What is GMCondition? What is #compositeWith: , #modifiedWith:? Best regards, Denis 2011/1/31 Fernando Olivero <fernando.olivero(a)usi.ch> > Hi, recently there were some discussion on implementing KeyBindings for our > IDE. > > There are at least 3 frameworks which address this functionality, the > last one mentioned is the work done by Guillermo. > I've implemented another one, for Gaucho. > > From what i understand, the previous work focuses on implementing > GLOBAL keybindings . > Basically adding behavior to HandMorph or PasteUpMorph or the toolbar > ( docking bar) present in the World. > > My implementation is a generic keybinding for any Morph, which can be > applied to any morph. Special cases for the docking bar or the paste > up Morph can be easily implemented following this uniform scheme. > > I didn't have the time to integrate it into Pharo yet, but will do in > one week from now. > > I like to bring up the discussion on which one we should adopt and > integrate into Morphic, points in favor of my approach: > 1) clean > 2) customizable > 3) generic: no special cases > > I believe the other Global keybindings should be a subset of this > generic keybinding mechanism. > > Fernando > > pd: From a previous mail: > > "... > So for example, if you want to delete any Morph from the system > by pressing cmd-w, you have to add the following binding: > > condition := GMCondition > compositeWith: > #( #understandsKeyBindingCommandCondition > #uneditedCondition ) ). > binding := GMKeyBinding > actingOn: $w asciiValue > modifiedBy: #(#command) > satisfying: condition > applying: #close. > m := Morph new. > m addKeyBinding: binding . > ... > " > > pd2: Useful and related comment from Stef > ".. > A classVar Binding and an instance var binding. > **All** the methods only access binding > binding get initialized with the default table defined in Binding > => we can have table binding sharing > => we can have instance based customization. > >

Jan. 31, 2011

Re: [Pharo-project] Text Selection problem in 1.2 dev

by Alain Plantec

>> I do not understand why but it looks really a problem with text selection It's not a problem with text selection. The problem is that profStef next changes the contents of the morph (with setText:). Nothing anormal here but, while doing so it kills the editor from where the selection is evaluated. See the portion of #evaluateSelection given below: -------------------- evaluateSelection ... result := [ rcvr class evaluatorClass new evaluate: self selectionForDoitAsStream in: ctxt to: rcvr notifying: self <------***** the problem is here ***** ifFail: [FakeClassPool adopt: nil. ^ #failedDoit] logged: true. ] ... ----------------- The receiver is passed as the requestor and it is bad because after the selection has been evaluated, the receiver is destroyed by the #setText: and a new editor is built. After having evaluated the selection, the compiler sends several messages to the requestor. Then it crashes because the requestor is destroyed by the evaluation ... :) So the solution is to set the editor morph as the requestor (which is stable), not the editor. Cheers Alain

Jan. 31, 2011

Re: [Pharo-project] Text Selection problem in 1.2 dev

by Alain Plantec

yes, it doesn't work because the fix has been overwritten with old code. I think that only SmalltalkEditor>>#evaluateSelection has been touched. Just browse this method, then open versions and set #evaluateSelection back to its previous version (12/21/2010). Le 31/01/2011 17:17, StÃ©phane Ducasse a Ã©crit : > Alain in > 13033 > > Gofer > ... metacelloRepository > > > (ConfigurationOfProfStef project version: '1.6') load. > > ProfStef go > > > > >> It seems to me that it has already been reported and fixed a time ago. >> see http://code.google.com/p/pharo/issues/detail?id=3472 >> take >> >> SLICE-Issue-3472-Text-selection-problem-in-Pharo-dev-12 and >> SLICE-Issue-3472-Text-selection-problem-in-Pharo-dev-12-Part-2 >> >> Cheers >> Alain >> >> Le 31/01/2011 14:23, StÃ©phane Ducasse a Ã©crit : >>> hi guys >>> >>> in 1.2 dev when I play with ProfStef go I get an error after a couple of screens normally 3. >>> >>> I do not understand why but it looks really a problem with text selection >>> >>> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/ >>> >>> Stef >>> >>> >>> >> > >

Jan. 31, 2011

[Pharo-project] Sound package fixes

by StÃ©phane Ducasse

Hi we merged all the squeak fixes to Sound and published them in PharoNonCorePackages It will be loaded in 1.3 dev but you can load them if you want to try. Stef

Jan. 31, 2011

[Pharo-project] Issue 3637 in pharo: [Hudson] archive builds automatically every 20 updates

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3637 by marcus.d...(a)gmail.com: [Hudson] archive builds automatically every 20 updates http://code.google.com/p/pharo/issues/detail?id=3637 We should archive the image all 20 updates to gforge so that they are available here: http://www.pharo-project.org/pharo-download/unstable-core http://www.pharo-project.org/pharo-download/stable-core

Jan. 31, 2011

Re: [Pharo-project] would be nice if configuration comment always contain how to load them :(

by Miguel CobÃ¡

Don't forget that the aim is to have all the configurations updated to the new symbolic version capabilities of the Metacello. Given that, then the standard (official) way to load (either by hand or by tools like the browser) *any* configuration will be something similar to: Gofer it "or new" squeaksource: "MetacelloRepository"; project: "XXX"; load. ((Smalltalk globals at: #ConfigurationOfXXX) project version: #stable) load This of course will be hidden from users by the existence of the user-tools and will install the stable version tested for the image version metacello it is running on. Of course it will be way to load a specific version (either because a bug fix hunting or simply by personal preference) of a given configuration. Something like: ((Smalltalk globals at: #ConfigurationOfXXX) project version: '1.4-something') load But this will be only for specific users and for specific reasons. Most users only want the stable version for its platform and metacello's symbolic versions give them that. Cheers. El lun, 31-01-2011 a las 17:23 +0100, Luc Fabresse escribiÃ³: > +1 > > > #Luc > > > 2011/1/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 31, 2011

[Pharo-project] Issue 3636 in pharo: [Hudson] load last core automatically

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3636 by marcus.d...(a)gmail.com: [Hudson] load last core automatically http://code.google.com/p/pharo/issues/detail?id=3636 Right now, we have images in the image dir. These we need to update by hand right now. The idea: download the last archived image http://www.pharo-project.org/pharo-download/stable-core http://www.pharo-project.org/pharo-download/unstable-core and use that.

Jan. 31, 2011

[Pharo-project] Issue 3635 in pharo: [Hudson] reuse images downstream

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3635 by marcus.d...(a)gmail.com: [Hudson] reuse images downstream http://code.google.com/p/pharo/issues/detail?id=3635 Pharo Full should use the image created by Pharo core. Normally this should work, but it did not. Maybe because we use a build slave?

Jan. 31, 2011