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

Re: [Pharo-project] 2.0 is back in "usable" state

by Sven Van Caekenberghe

Indeed, thanks a lot, we're back in business ;-) Great work ! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 12 Sep 2012, at 18:04, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi guys, > > I think Pharo 2.0 is back in an usable state :) > > Beware, that doesn't means that it is stable and bug free! > In particular, I think there are still some problems around RPackage and the new SystemAnnouncer, but you can resume using it and providing bug reports/fixes. > > Enjoy, > Esteban > > ps: That means tomorrow I will resume the integration of issues, etc. but the stability effort is still ongoing...

Sept. 12, 2012

[Pharo-project] RE : 2.0 is back in "usable" state

by GOUBIER Thierry

Thanks Esteban, Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] Date d'envoi : mercredi 12 septembre 2012 18:04 Ã : Pharo-project(a)lists.gforge.inria.fr Development Objet : [Pharo-project] 2.0 is back in "usable" state Hi guys, I think Pharo 2.0 is back in an usable state :) Beware, that doesn't means that it is stable and bug free! In particular, I think there are still some problems around RPackage and the new SystemAnnouncer, but you can resume using it and providing bug reports/fixes. Enjoy, Esteban ps: That means tomorrow I will resume the integration of issues, etc. but the stability effort is still ongoing...

Sept. 12, 2012

Re: [Pharo-project] 2.0 is back in "usable" state

by Mariano Martinez Peck

Thanks a lot Esteban. It is nice to have an engineer when things start to look complicated :) On Wed, Sep 12, 2012 at 6:04 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi guys, > > I think Pharo 2.0 is back in an usable state :) > > Beware, that doesn't means that it is stable and bug free! > In particular, I think there are still some problems around RPackage and > the new SystemAnnouncer, but you can resume using it and providing bug > reports/fixes. > > Enjoy, > Esteban > > ps: That means tomorrow I will resume the integration of issues, etc. but > the stability effort is still ongoing... > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 12, 2012

Re: [Pharo-project] [update 2.0] #20281

by Guillermo Polito

uhu!!! :D On Wed, Sep 12, 2012 at 5:55 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > 20281 > ----- > > Issue 6654: Make one RPackage maps one PackageInfo > http://code.google.com/p/pharo/issues/detail?id=6654 > > (pass 3) > > - Monticello to use RPackageSet > > finish :) > >

Sept. 12, 2012

Re: [Pharo-project] [update 2.0] #20281

by Camillo Bruni

\(^-^)/ oueeehh! thanks a lot! On 2012-09-12, at 17:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 20281 > ----- > > Issue 6654: Make one RPackage maps one PackageInfo > http://code.google.com/p/pharo/issues/detail?id=6654 > > (pass 3) > > - Monticello to use RPackageSet > > finish :) >

Sept. 12, 2012

[Pharo-project] 2.0 is back in "usable" state

by Esteban Lorenzano

Hi guys, I think Pharo 2.0 is back in an usable state :) Beware, that doesn't means that it is stable and bug free! In particular, I think there are still some problems around RPackage and the new SystemAnnouncer, but you can resume using it and providing bug reports/fixes. Enjoy, Esteban ps: That means tomorrow I will resume the integration of issues, etc. but the stability effort is still ongoing...

Sept. 12, 2012

[Pharo-project] [update 2.0] #20281

by Esteban Lorenzano

20281 ----- Issue 6654: Make one RPackage maps one PackageInfo http://code.google.com/p/pharo/issues/detail?id=6654 (pass 3) - Monticello to use RPackageSet finish :)

Sept. 12, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 342 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 12, 2012

Re: [Pharo-project] RE : Keymapping KMShortcut combining

by Goubier Thierry

Le 12/09/2012 07:33, StÃ©phane Ducasse a Ã©crit : > if you have code that ease the replacement of hardcoded binding by key mapper, publish it so that we integrate > it like that everybody will benefit from it. > > Stef Have a look at http://code.google.com/p/pharo/issues/detail?id=6656; I'd like a review on how it's integrated in Spec. (Temporarily, Keymapping blocks all crtl and cmd shortcuts to reach Morphic, so we can see what is really necessary or not). What remains if you're Ok with the design is. - Making sure all shortcuts are in Keymapping - Removing all the relevant code from Spec(not much) and Morphic (a lot). For Spec, I'm tempted by removing the keyboard handler stuff and ask people to use Keymapping shortcuts instead; not sure if anybody is using that anyway ? Thierry > > > >> Yes, I was thinking of the $a cmd | $a cmd shift thing. >> >> Oh, the ugly code (the one that changes the KMDispatcher, right ?). It's patching the relevant Morphs. The solution you use when you want to hack Morphic without recoding it :( >> >> Anything better than that would do, a Spec or Morphic API for the application to be able to reset/recode shortcuts when needed :) a nice when: #keymapChange do: aBlock. >> >> Some of the work is to switch to hardcoded Keymappings... and to allow dynamic, instance-based control as well. >> >> What I tried is to remove all hardcoded shortcuts, and it works. I then merged my menus and shortcuts, and made sure my application could control which shortcuts were active. But, in the process, I desactivated for my instances the global Keymaps, the one Nautilus uses for its shortcuts. >> >> Thierry >> >> ________________________________________ >> De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [camillobruni(a)gmail.com] >> Date d'envoi : mardi 11 septembre 2012 22:48 >> Ã : Pharo-project(a)lists.gforge.inria.fr >> Objet : Re: [Pharo-project] RE : Keymapping KMShortcut combining >> >> On 2012-09-11, at 22:21, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> I've seen the combination and modifiers for Keymapper already; what I would like is the alternative : >>> >>> Either >>> Character tab >>> or >>> Character tab ctrl >>> >>> (because I've linked tab to nextFocus in a TreeModel, and ctrl + tab in a TextModel (since tab can't be used)) Ok, not much of a gain anyway, so no need to add this to Keymapper. >> >> I though once about this as well, so you can do something like >> $a cmd | $a cmd shift >> >> >>> Ben, Guillermo and StÃ©phane, in AltBrowser, all hard-coded shortcuts are desactivated and only the AltBrowser defined shortcuts are active (and those shortcuts are dependent on the selection and resetted on each selection change : it's mostly a recreation of the existing shortcuts, like doIt, copy/paste, navigation, etc...). It takes as code : >>> >>> - A subclass of KMDispatcher with two methods (keymapObservers and dispatchKeystroke:). >>> - The code to replace each necessary KMDispatcher by this subclass. >>> - The code to reset and add shortcuts to those KMDispatchers. >> >> As far as I remember I once had my own image which used KM shortcuts for all the default >> shortcuts with proper Settings entries (maybe I find the image somewhere so I can share >> the settings code (cause it's really only copy pasting...) >> >>> So, apart from a bit of incompatibility (ListModel shortcuts in Spec), for Spec it's really easy to push that once you review why I had to do that change to KMDispatcher. For the other parts (SmalltalkEditor), it's a matter of replacing some class configs by KMShortcuts. I believe someone with Nautilus knowledge would be nice : it is the heaviest user of shortcuts, and I really don't use shortcuts in the same way. A merge of both is probably necessary. >>> >>> For example, I have this method, called each time the selection changes : >>> >>> updateTextKeymap >>> "Update the text keymap. Change the key dispatcher if needed. Change all dispatchers to force and really force default shortcuts not to be used." >>> >>> | keyMorph | >>> keyMorph := self targetShortcutMorph. >>> (textModel widget kmDispatcher isKindOf: AltKMDispatcher) >>> ifFalse: [ textModel widget setProperty: #kmDispatcher toValue: (AltKMDispatcher target: textModel widget) ]. >>> (keyMorph kmDispatcher isKindOf: AltKMDispatcher) >>> ifFalse: [ keyMorph setProperty: #kmDispatcher toValue: (AltKMDispatcher target: keyMorph) ] >>> ifTrue: [ keyMorph kmDispatcher reset ]. >>> self selectedItem notNil >>> ifTrue: [ self selectedItem item buildTextShortcutsOn: keyMorph with: self ] >>> >>> And, in the select object side : >>> >>> buildTextShortcutsOn: aKMDispatcher with: aRequestor >>> "This is an attempt at handling shortcuts... Which works, with the help of a custom KMDispatcher." >>> >>> (Pragma allNamed: #textAreaCommand from: self class to: ABAbstractNode) >>> do: [ :e | >>> (self perform: e selector) >>> do: [ :c | >>> | command | >>> command := c on: aRequestor textModel for: aRequestor. >>> command buildShortcut: aKMDispatcher ] ] >>> >>> And then the shortcut itself in the Command object. >>> >>> buildShortcut: aKMDispatcher >>> "Add a shortcut to the keymap. Conditions : must have a keystroke, must wantsKeyboard and must be active." >>> >>> (self keystroke isNil or: [ self wantsKeyboard not or: [ self isActive not ] ]) >>> ifTrue: [ ^ self ]. >>> aKMDispatcher >>> on: self keystroke >>> do: [ self execute ] >>> >>> As you see, the use of KMDispatcher is dynamic and very simple, so I need your comments on how that would fit with Nautilus and the global keymaps, that I have disconnected in my case because they interfere in two ways : KMDispatch randomly chooses which will apply, and that disallows instance based overriding of shortcuts, and I don't want to have to mask all pre-existing shortcuts to avoid pass-through effect (a shortcut get applied because a global map has it and me, for my application, I don't want that to happen). >> >> given that I am a total ignorant :P, can you explain again in different words why you need >> the "ugly" code above? >> >> If you remove all the hardcoded shortcuts, is your dynamic KMDispatcher switch still necessary? >> >> I still remember a vague discussion with Guillermo about how to handle local >> overrides of keyboard shortcuts, wish I had made a picture of that draft back then :P >> >> But I think we need a bit more general solution for that problem >> (of course if yours works right now, we should definitely go for it now!) >> >> >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 12, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 341 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 12, 2012