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

Re: [Pharo-project] SmallLint and Manifest

by Mariano Martinez Peck

Hi Simon. I have just run it in Tanker. It already help me to detect a couple of things :) Some feedback: 1) Is there a way to set the package of the Manifest class? Because I don't like the default package where it goes.... Now it is even worst because it goes to "UndefinedPackage": 2) I have a weird bug rendering some text. (look attached) Thanks! On Tue, Sep 11, 2012 at 7:19 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > I started to use it, and I will have suggestion on the GUI. > > Cheers, > Alexandre > > > On Sep 11, 2012, at 1:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > excellent! > > Simon what about producing a video so that the world can see your nice > tool in action. > > > > Stef > > > > > > On Sep 11, 2012, at 4:21 PM, Simon Allier wrote: > > > >> I have fix the error found by Camillo, now it works with all packages > and rules in the last pharo 2.0 image. > >> > >> On Sep 11, 2012, at 4:13 PM, Mariano Martinez Peck wrote: > >> > >>> > >>> > >>> On Mon, Sep 10, 2012 at 11:53 PM, Simon Allier <simon.allier(a)inria.fr> > wrote: > >>> Hi, > >>> > >>> I have published a new version of the Critics Browser (menuWorld > > Tool > CriticBrowser). > >>> The new version is > >>> - refactoring friendly. Yes we listened to you :). > >>> > >>> hehehe I felt touched by that ;( > >>> Thanks Simon, these are really great news because it doesn't mean we > have to throw the manifiest away after a couple of refactors :) > >>> I will re-run everything with Fuel soon and give you any feedback I > have. > >>> > >>> - the browser has been improved. It works with the latest Spec. > >>> > >>> With the Critics browser you can inspect violations of the SmallLint > rules and mark them as false positive or true positive (ToDo) and see > previous warnings flagged as false positives or toDo. > >>> In addition all the logic of the browser has been developed so that > the manifest can be saved within the package without adding dependencies. > >>> > >>> In this new version the format of the manifest has changed to be > compatible with tools refactoting, the rules are organized in a tree and > itâs possible to adds comment when we mark a false positive or todo. > >>> > >>> We are writing a nice chapter on SmallLint, critics and other for the > new book. Soon we will release it for reviews. > >>> > >>> Gofer > >>> new > >>> url: 'http://www.squeaksource.com/PharoTaskForces'; > >>> package: 'ConfigurationOfManifest'; > >>> load. > >>> ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) > load > >>> > >>> Simon > >>> > >>> > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 11, 2012

[Pharo-project] RE : Keymapping KMShortcut combining

by GOUBIER Thierry

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. 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. 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). Thierry ________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Benjamin [benjamin.vanryseghem.pharo(a)gmail.com] Date d'envoi : mardi 11 septembre 2012 19:59 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] Keymapping KMShortcut combining On Sep 11, 2012, at 7:52 PM, Guillermo Polito wrote: On Sep 11, 2012, at 2:58 PM, Goubier Thierry wrote: > Hi, > > Is it possible in Keymapping to have an alternative as shortcut ? > > I would like to map Tab/Shift Tab and Ctrl Tab/Shift Ctrl Tab to get next/previous focus to work with Spec, and I would like to be able to return a keystroke as Character tab | Character tab ctrl. > Yes, keymapping allows combinations as ctrl tab, ctrl shift tab, and also sequences (cmd a followed by cmd shift c). > For those interested, I'm trying to look at > http://code.google.com/p/pharo/issues/detail?id=6657 > and: > http://code.google.com/p/pharo/issues/detail?id=6656 > > I have solutions for both : code that does 6657, and a way to disable all legacy shortcuts for 6656 for Spec applications on a per instance basis, without overriding or removing any existing code. you mean disabling only in spec? The idea is to move all shortcuts to keymappings but I'm out of time right now :(. +1 :) Sadly, I am out of time too :s Ben > > Thierry > -- > 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. 11, 2012

Re: [Pharo-project] Keymapping KMShortcut combining

by Benjamin

On Sep 11, 2012, at 7:52 PM, Guillermo Polito wrote: > > > On Sep 11, 2012, at 2:58 PM, Goubier Thierry wrote: > > > Hi, > > > > Is it possible in Keymapping to have an alternative as shortcut ? > > > > I would like to map Tab/Shift Tab and Ctrl Tab/Shift Ctrl Tab to get next/previous focus to work with Spec, and I would like to be able to return a keystroke as Character tab | Character tab ctrl. > > > > Yes, keymapping allows combinations as ctrl tab, ctrl shift tab, and also sequences (cmd a followed by cmd shift c). > > > For those interested, I'm trying to look at > > http://code.google.com/p/pharo/issues/detail?id=6657 > > and: > > http://code.google.com/p/pharo/issues/detail?id=6656 > > > > I have solutions for both : code that does 6657, and a way to disable all legacy shortcuts for 6656 for Spec applications on a per instance basis, without overriding or removing any existing code. > > > you mean disabling only in spec? The idea is to move all shortcuts to keymappings but I'm out of time right now :(. +1 :) Sadly, I am out of time too :s Ben > > > > > Thierry > > -- > > 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. 11, 2012

Re: [Pharo-project] Keymapping KMShortcut combining

by Guillermo Polito

> > On Sep 11, 2012, at 2:58 PM, Goubier Thierry wrote: > > > Hi, > > > > Is it possible in Keymapping to have an alternative as shortcut ? > > > > I would like to map Tab/Shift Tab and Ctrl Tab/Shift Ctrl Tab to get > next/previous focus to work with Spec, and I would like to be able to > return a keystroke as Character tab | Character tab ctrl. > > > Yes, keymapping allows combinations as ctrl tab, ctrl shift tab, and also sequences (cmd a followed by cmd shift c). > > For those interested, I'm trying to look at > > http://code.google.com/p/pharo/issues/detail?id=6657 > > and: > > http://code.google.com/p/pharo/issues/detail?id=6656 > > > > I have solutions for both : code that does 6657, and a way to disable > all legacy shortcuts for 6656 for Spec applications on a per instance > basis, without overriding or removing any existing code. > > you mean disabling only in spec? The idea is to move all shortcuts to keymappings but I'm out of time right now :(. > > > > Thierry > > -- > > 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. 11, 2012

Re: [Pharo-project] Event smell...

by StÃ©phane Ducasse

> > I think it's just because I wasn't aware that this class existed :) > > I should fix that Thanks ben I like your positive thinking and attitude. Stef

Sept. 11, 2012

Re: [Pharo-project] Keymapping KMShortcut combining

by StÃ©phane Ducasse

On Sep 11, 2012, at 2:58 PM, Goubier Thierry wrote: > Hi, > > Is it possible in Keymapping to have an alternative as shortcut ? > > I would like to map Tab/Shift Tab and Ctrl Tab/Shift Ctrl Tab to get next/previous focus to work with Spec, and I would like to be able to return a keystroke as Character tab | Character tab ctrl. > > For those interested, I'm trying to look at > http://code.google.com/p/pharo/issues/detail?id=6657 > and: > http://code.google.com/p/pharo/issues/detail?id=6656 > > I have solutions for both : code that does 6657, and a way to disable all legacy shortcuts for 6656 for Spec applications on a per instance basis, without overriding or removing any existing code. ok thanks for the info I do not know if this is realistic but my goal is to kill any harcoded key shortcut so that we can plug what we want. Now I need time. > > Thierry > -- > 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. 11, 2012

Re: [Pharo-project] SmallLint and Manifest

by Alexandre Bergel

I started to use it, and I will have suggestion on the GUI. Cheers, Alexandre On Sep 11, 2012, at 1:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > excellent! > Simon what about producing a video so that the world can see your nice tool in action. > > Stef > > > On Sep 11, 2012, at 4:21 PM, Simon Allier wrote: > >> I have fix the error found by Camillo, now it works with all packages and rules in the last pharo 2.0 image. >> >> On Sep 11, 2012, at 4:13 PM, Mariano Martinez Peck wrote: >> >>> >>> >>> On Mon, Sep 10, 2012 at 11:53 PM, Simon Allier <simon.allier(a)inria.fr> wrote: >>> Hi, >>> >>> I have published a new version of the Critics Browser (menuWorld > Tool > CriticBrowser). >>> The new version is >>> - refactoring friendly. Yes we listened to you :). >>> >>> hehehe I felt touched by that ;( >>> Thanks Simon, these are really great news because it doesn't mean we have to throw the manifiest away after a couple of refactors :) >>> I will re-run everything with Fuel soon and give you any feedback I have. >>> >>> - the browser has been improved. It works with the latest Spec. >>> >>> With the Critics browser you can inspect violations of the SmallLint rules and mark them as false positive or true positive (ToDo) and see previous warnings flagged as false positives or toDo. >>> In addition all the logic of the browser has been developed so that the manifest can be saved within the package without adding dependencies. >>> >>> In this new version the format of the manifest has changed to be compatible with tools refactoting, the rules are organized in a tree and itâs possible to adds comment when we mark a false positive or todo. >>> >>> We are writing a nice chapter on SmallLint, critics and other for the new book. Soon we will release it for reviews. >>> >>> Gofer >>> new >>> url: 'http://www.squeaksource.com/PharoTaskForces'; >>> package: 'ConfigurationOfManifest'; >>> load. >>> ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load >>> >>> Simon >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2012

[Pharo-project] RE : [update 2.0] #20279

by GOUBIER Thierry

Cool. So far the only strange thing I see is with RPackage RPackages (:)). The RPackage package duplicates all extensions listed in RPackage-* packages. But this may be a problem with MC, not with RPackage in itself. I'll try a few extensions additions to check. 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 : mardi 11 septembre 2012 17:26 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] [update 2.0] #20279 yes it is :) On Sep 11, 2012, at 5:14 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 11/09/2012 16:18, Esteban Lorenzano a Ã©crit : >> 20279 >> ----- >> >> Issue 6654: Make one RPackage maps one PackageInfo >> http://code.google.com/p/pharo/issues/detail?id=6654 >> >> (pass 1) >> >> - Rollback Nautilus to a pre-tags version >> - initialize RPackageOrganizer from PackageInfos as before >> >> WARNING: This does not restores 2.0 stability, but it makes it a bit more usable... I'm working on the other issues. >> >> > Works for me. > > I see one RPackage for each system categories, not one RPackage per PackageInfo, and no RPackageSet yet. > > Is that what we should expect? > > Thierry > -- > 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. 11, 2012

Re: [Pharo-project] SmallLint and Manifest

by StÃ©phane Ducasse

excellent! Simon what about producing a video so that the world can see your nice tool in action. Stef On Sep 11, 2012, at 4:21 PM, Simon Allier wrote: > I have fix the error found by Camillo, now it works with all packages and rules in the last pharo 2.0 image. > > On Sep 11, 2012, at 4:13 PM, Mariano Martinez Peck wrote: > >> >> >> On Mon, Sep 10, 2012 at 11:53 PM, Simon Allier <simon.allier(a)inria.fr> wrote: >> Hi, >> >> I have published a new version of the Critics Browser (menuWorld > Tool > CriticBrowser). >> The new version is >> - refactoring friendly. Yes we listened to you :). >> >> hehehe I felt touched by that ;( >> Thanks Simon, these are really great news because it doesn't mean we have to throw the manifiest away after a couple of refactors :) >> I will re-run everything with Fuel soon and give you any feedback I have. >> >> - the browser has been improved. It works with the latest Spec. >> >> With the Critics browser you can inspect violations of the SmallLint rules and mark them as false positive or true positive (ToDo) and see previous warnings flagged as false positives or toDo. >> In addition all the logic of the browser has been developed so that the manifest can be saved within the package without adding dependencies. >> >> In this new version the format of the manifest has changed to be compatible with tools refactoting, the rules are organized in a tree and itâs possible to adds comment when we mark a false positive or todo. >> >> We are writing a nice chapter on SmallLint, critics and other for the new book. Soon we will release it for reviews. >> >> Gofer >> new >> url: 'http://www.squeaksource.com/PharoTaskForces'; >> package: 'ConfigurationOfManifest'; >> load. >> ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load >> >> Simon >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Sept. 11, 2012

Re: [Pharo-project] Event smell...

by Benjamin

On Sep 11, 2012, at 4:23 PM, Henrik Sperre Johansen wrote: > On 11.09.2012 15:41, Igor Stasenko wrote: >> On 11 September 2012 15:27, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> On 11.09.2012 14:35, StÃ©phane Ducasse wrote: >>>> Hi igor >>>> >>>> I started to reread again the code of EventModel that we started and I >>>> browse the rest of the systemâ¦. >>>> gloopsâ¦ >>>> >>>> DropEvent>>sentTo: anObject >>>> "Dispatch the receiver into anObject" >>>> self type == #dropEvent ifTrue:[^anObject handleDropMorph: self]. >>>> >>>> DropFilesEvent>>sentTo: anObject >>>> "Dispatch the receiver into anObject" >>>> self type == #dropFilesEvent ifTrue:[^anObject handleDropFiles: >>>> self]. >>>> >>>> it seems to me that sentTo: is a kind of double dispatch but not yet >>>> there. >>>> I do not see here the added value of the check except if this is to cancel >>>> event. >>>> >>>> Stef >>> I guess it's to be consistent with other types of events, and/or make it >>> easy to add a type instvar in the future... >>> Right now all three combinations of type instvar checks (KeyboardEvent), >>> subclassing (DropXEvents), or a mix of the two (MouseEvents) are in use >>> during the double dispatching of input events. >>> You might think subclassing was only used if additional state was needed, >>> but that's only true of MouseEvents, and not DropXEvents... >>> (So yeah, your observation that the type check in DropEvent is unneccesary >>> is correct) >>> >>> It might be nice with a rewrite to rely on subclassing alone, albeit >>> increaseing the number of event classes. (KeyUp, KeyDown, KeyPressed, >>> MouseOver, MouseEnter and MouseLeave for sure, potentially more depending on >>> what action in WindowEvent means) >>> >>> A benefit is you could rewrite processEvents loop to essentially read >>> event := MorphicEvent forBuffer: evtBuf. >>> self handleEvent: event >>> >> yes, that's the idea. but we didn't went further than passing events >> to HandMorph. >> At first stage we want to make sure a lower-level event handling >> (Sensor->World->HandMorph) >> can be replaced with new model, and then we can enter the morphic and >> clean it up more seriously. > Mmmmhmm, isn't it more accurate to say that events flow Sensor -> HandMorph -> World? > (Though, they get pulled in by the consuming world in a polling loop, rather than getting pushed from the flow source) > > Anyways, a proper input event modelling is really independent of Morphic, analogous to the WindowClosed/MorphicWindowClosed naming discussion. > (which also gives a third alternative to double dispatch/case, in that in use registering to them tend to look like case statements, but loosely coupled) > > Cheers, > Henry > > PS: Looking up an example WindowAnnouncement and ran across it; WTF does Nautilus need special NautilusWindowAnnouncement classes for? > As long as your announcer is a Nautilus-specific one rather than the default announcer, that's all the separation that's needed... > In other words; favour application-distinct announcers over duplicate Announcement types. I think it's just because I wasn't aware that this class existed :) I should fix that Ben

Sept. 11, 2012