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

Re: [Pharo-project] Fwd: trying to understand loops in pharo

by StÃ©phane Ducasse

for me the last expression of the block. Stef >>> Which return value would be useful? >> >> That's not the right question. IMO the compiler should answer the same >> result as the non-inlined one when the return value is asked for. Arguably >> the non-inline version needs to be commented to specify that it returns the >> value it does (in this case self), and that the compiler's optimiser >> reflects this. >> > > Agree, but I was wondering what useful object this common answer could be? > >>> >>> Nicolas >>> >>> 2011/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> A friend of mine ask me the following >>>> >>>> |result| >>>> result := String new. >>>> 1 to: 10 do: [:n | result := result, n printString, ' ']. >>>> I am trying to do or print this code. It prints 'nil' instead of a >>>> collection. Its an example from PBE book. >>>> do you know the reason? >>>> although this one's working: >>>> result := String new. >>>> (1 to: 10) do: [:n | result := result, n printString, ' ']. >>>> >>>> I checked the implementation >>>> Interval>>do: aBlock >>>> "Evaluate aBlock for each value of the interval. >>>> Implementation note: instead of repeatedly incrementing the value >>>> aValue := aValue + step. >>>> until stop is reached, >>>> We prefer to recompute value from start >>>> aValue := start + (index * step). >>>> This is better for floating points accuracy, while not degrading Integer >>>> and >>>> Fraction speed too much. >>>> Moreover, this is consistent with methods #at: and #size" >>>> | aValue index size | >>>> index := 0. >>>> size := self size. >>>> [index < size] >>>> whileTrue: [aValue := start + (index * step). >>>> index := index + 1. >>>> aBlock value: aValue] >>>> >>>> Number>>to: stop do: aBlock >>>> "Normally compiled in-line, and therefore not overridable. >>>> Evaluate aBlock for each element of the interval (self to: stop by: 1)." >>>> | nextValue | >>>> nextValue := self. >>>> [nextValue <= stop] >>>> whileTrue: >>>> [aBlock value: nextValue. >>>> nextValue := nextValue + 1] >>>> >>>> any further idea than := value is different from value: >>>> Stef >>> >> >> >> >> -- >> best, >> Eliot >> >

Oct. 16, 2011

Re: [Pharo-project] why doing RPackage is a pain

by StÃ©phane Ducasse

On Oct 16, 2011, at 9:21 PM, StÃ©phane Ducasse wrote: > RPackage is nice simple fast and robust now the integration within categories crap and packageInfo and PackageOrganizer and MCWorkingCopies.... > are a pain. > > Examples: > > MCWorkingCopy allManagers size 177 > PackageOrganizer default packages size 422 > > Stef :( I imagine that I could only look at MCWorkingCopies. Now I have not why wrong time to time I get a new package in Monticello-Browser that is not a package but just the left most part of a package name I get RPackage () RPackage-Core (StephaneDucasse.107) but I never mentioned that RPackage was a package (since it is not). :( Stef

Oct. 16, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by Guillermo Polito

On Sun, Oct 16, 2011 at 4:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > > > > I think it has not ugly bugs. Esteban (another early adopter :D) found > some little issues I fixed in the last weeks. Also, most issues (like the > ones of this email) usually appear from inconsistent shortcut definitions, > not from a bug in the framework. > > good > > > I don't know how other users (if any) feel it, but I feel it stable > enough. > > > > But, on the other way, until I make experience integrating it with OB, > task manager, etc.. I don't know if it fits every usage in the image, so I > don't know if it needs to be changed in some way :). > > we could push it inside and hook it and learn. > > > But it is difficult to make it evolve right now... > why? > No time, no feedback :). > > > > Guille > > > > Like that we could remove the hardcoded way. > > Stef > > > > > > > > > On Sat, Oct 15, 2011 at 9:47 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > > Hi guys. I was trying to use TWM in Pharo 1.3 release. TWM brings with > keymappings, which breaks the shortcuts of my image. > > > > > > The main problem here is that it's not integrated with current tools > (i.e. OB). If you just load Keymapping you will have an image where: > > > - lots of shortcuts are hardcoded > > > - some shortcuts like OB's are handled with it's own and specific > way/framework > > > > > > Having keymapping living with those, introduces a third way of handling > shortcuts (yeap, it's not good enough, but It's not easy to remove all the > old code in a row ). So, the following problems happens: > > > > > > - first of all, there are shortcuts collisions. If a morph handles cmd > + a and its owner handles cmd + a, cmd + b, the owner morph will never > handle the shortcut because it was handled by it's child first. > > > - second. It's hard to keep track and find every hardcoded shortcut > :). And furthermore, this leads in the fact that I cannot easily analyse > shortcuts collisions between keymapping and hardcoded shortcuts. > > > > > > So, how does Keymapping live with that by now? > > > 1) a keyEvent reaches a morph > > > 2) the morph delegates the handling in keymapping (bubbling until the > world instance). > > > 3) if keymapping does not handle the shortcut, It is delegated to the > old-hardcoded shortcuts (so the original behavior is still there yet) > > > > > > All this is just to understand what is happening and where the errors > come from :P > > > > > > For example, after installing keymappings I cannot close windows > anymore with cmd + w or I cannot run tests from the browser using cmd + t. > > > > > > So far, I've found those two collisions in keymapping 1.9 and one more > in keymapping+TWM: > > > > > > 1) Cmd+w was defined for TextEditor for delete backword. > > > > > > Esteban already complained about this, so I've changed it in 2.0 for > Cmd + Backspace > > > This shortcut was taken from SimpleEditor, in > #initializeCmdKeyShortcuts. I don't know if it should be there or not. > > > > > > 2) Cmd+t from omnibrowser was colliding with some global shortcuts I > defined in the initial versions of keymapping to play opening a test runner, > a browser, a monticello browser. > > > > > > I've fixed it removing the global shortcuts by now (because I'm not > conviced the key combinations are nice). > > > > > > 3) When loading TWM + Keymapping, I realized the cmd+w was not working > again. Wandering, I found that the TWM shortcuts were defined for a lot of > morphs, in this way, causing a little of trouble: > > > > > > {PasteUpMorph. SystemWindow. SmalltalkEditor. TextEditor. > PluggableTextMorph} do: [:aClass| > > > aBuilder > > > attachShortcutCategory: self shortcutCategory > > > to: aClass. > > > ]. > > > > > > But replacing it by > > > > > > aBuilder > > > attachShortcutCategory: self shortcutCategory > > > to: PasteUpMorph. > > > > > > should be working the same way :/. > > > Laurent, did you have any problems when not attaching the categories in > this way?. > > > > > > Also: TWM by default has a lot of (cmd+w, ...) mappings colliding with > the window cmd+w shortcut. So the window shortcut or the TWM ones are to be > sacrificed :P. > > > > > > > > > So i installed TWM without keybinding but now I cannot open the > settings window because keymappings is not load. > > > > > > Any solution? (install TWM without keymappings or fixing keymappings) > > > > > > I've done some fixes and improvements to keymapping, and I've created a > 2.0 version where: > > > > > > - the collisions below are fixed > > > - keymaps can be configured per morph instance too (not only per class, > as the former version) > > > - some little improvements and code cleaning > > > > > > But those things I remarked of TWM should be reviewed :) > > > > > > Or you can Use twm without keymappings and I'll have no more feedback > :( > > > > > > > > > thanks! > > > > > > Thank you :) > > > > > > Guille > > > > > > > > >

Oct. 16, 2011

Re: [Pharo-project] Fwd: trying to understand loops in pharo

by Nicolas Cellier

2011/10/16 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Sun, Oct 16, 2011 at 10:09 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Well, the inlined to:do: doesn't behave the same as non inlined one: >> >> |result| >> result := String new. >> 1 to: 10 do: [:n | result := result, n printString, ' '] yourself. >> >> --> 1 >> >> The inlined byte code is explicitely returning nil (at byte 60) >> >> (Compiler new >> Â Â Â Â compileNoPattern: '|result| >> result := String new. >> 1 to: 10 do: [:n | result := result, n printString, '' '']' >> Â Â Â Â in: Object context: nil notifying: nil >> Â Â Â Â ifFail: nil) generateWithTempNames. >> >> >> 37 <40> pushLit: String >> 38 <CC> send: new >> 39 <68> popIntoTemp: 0 >> 40 <76> pushConstant: 1 >> 41 <69> popIntoTemp: 1 >> 42 <11> pushTemp: 1 >> 43 <24> pushConstant: 10 >> 44 <B4> send: <= >> 45 <AC 0D> jumpFalse: 60 >> 47 <10> pushTemp: 0 >> 48 <11> pushTemp: 1 >> 49 <D2> send: printString >> 50 <E1> send: , >> 51 <23> pushConstant: ' ' >> 52 <E1> send: , >> 53 <68> popIntoTemp: 0 >> 54 <11> pushTemp: 1 >> 55 <76> pushConstant: 1 >> 56 <B0> send: + >> 57 <69> popIntoTemp: 1 >> 58 <A3 EE> jumpTo: 42 >> 60 <73> pushConstant: nil >> 61 <7C> returnTop >> >> Which return value would be useful? > > That's not the right question. Â IMO the compiler should answer the same > result as the non-inlined one when the return value is asked for. Â Arguably > the non-inline version needs to be commented to specify that it returns the > value it does (in this case self), and that the compiler's optimiser > reflects this. > Agree, but I was wondering what useful object this common answer could be? >> >> Nicolas >> >> 2011/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> > A friend of mine ask me the following >> > >> > |result| >> > result := String new. >> > 1 to: 10 do: [:n | result := result, n printString, ' ']. >> > I am trying to do or print this code. It prints 'nil' instead of a >> > collection. Its an example from PBE book. >> > do you know the reason? >> > although this one's working: >> > result := String new. >> > (1 to: 10) do: [:n | result := result, n printString, ' ']. >> > >> > I checked the implementation >> > Interval>>do: aBlock >> > "Evaluate aBlock for each value of the interval. >> > Implementation note: instead of repeatedly incrementing the value >> > aValue := aValue + step. >> > until stop is reached, >> > We prefer to recompute value from start >> > aValue := start + (index * step). >> > This is better for floating points accuracy, while not degrading Integer >> > and >> > Fraction speed too much. >> > Moreover, this is consistent with methods #at: and #size" >> > | aValue index size | >> > index := 0. >> > size := self size. >> > [index < size] >> > whileTrue: [aValue := start + (index * step). >> > index := index + 1. >> > aBlock value: aValue] >> > >> > Number>>to: stop do: aBlock >> > "Normally compiled in-line, and therefore not overridable. >> > Evaluate aBlock for each element of the interval (self to: stop by: 1)." >> > | nextValue | >> > nextValue := self. >> > [nextValue <= stop] >> > whileTrue: >> > [aBlock value: nextValue. >> > nextValue := nextValue + 1] >> > >> > any further idea than := value is different from value: >> > Stef >> > > > > -- > best, > Eliot >

Oct. 16, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by StÃ©phane Ducasse

> > > I think it has not ugly bugs. Esteban (another early adopter :D) found some little issues I fixed in the last weeks. Also, most issues (like the ones of this email) usually appear from inconsistent shortcut definitions, not from a bug in the framework. good > I don't know how other users (if any) feel it, but I feel it stable enough. > > But, on the other way, until I make experience integrating it with OB, task manager, etc.. I don't know if it fits every usage in the image, so I don't know if it needs to be changed in some way :). we could push it inside and hook it and learn. > But it is difficult to make it evolve right now... why? > > Guille > > Like that we could remove the hardcoded way. > Stef > > > > > > On Sat, Oct 15, 2011 at 9:47 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi guys. I was trying to use TWM in Pharo 1.3 release. TWM brings with keymappings, which breaks the shortcuts of my image. > > > > The main problem here is that it's not integrated with current tools (i.e. OB). If you just load Keymapping you will have an image where: > > - lots of shortcuts are hardcoded > > - some shortcuts like OB's are handled with it's own and specific way/framework > > > > Having keymapping living with those, introduces a third way of handling shortcuts (yeap, it's not good enough, but It's not easy to remove all the old code in a row ). So, the following problems happens: > > > > - first of all, there are shortcuts collisions. If a morph handles cmd + a and its owner handles cmd + a, cmd + b, the owner morph will never handle the shortcut because it was handled by it's child first. > > - second. It's hard to keep track and find every hardcoded shortcut :). And furthermore, this leads in the fact that I cannot easily analyse shortcuts collisions between keymapping and hardcoded shortcuts. > > > > So, how does Keymapping live with that by now? > > 1) a keyEvent reaches a morph > > 2) the morph delegates the handling in keymapping (bubbling until the world instance). > > 3) if keymapping does not handle the shortcut, It is delegated to the old-hardcoded shortcuts (so the original behavior is still there yet) > > > > All this is just to understand what is happening and where the errors come from :P > > > > For example, after installing keymappings I cannot close windows anymore with cmd + w or I cannot run tests from the browser using cmd + t. > > > > So far, I've found those two collisions in keymapping 1.9 and one more in keymapping+TWM: > > > > 1) Cmd+w was defined for TextEditor for delete backword. > > > > Esteban already complained about this, so I've changed it in 2.0 for Cmd + Backspace > > This shortcut was taken from SimpleEditor, in #initializeCmdKeyShortcuts. I don't know if it should be there or not. > > > > 2) Cmd+t from omnibrowser was colliding with some global shortcuts I defined in the initial versions of keymapping to play opening a test runner, a browser, a monticello browser. > > > > I've fixed it removing the global shortcuts by now (because I'm not conviced the key combinations are nice). > > > > 3) When loading TWM + Keymapping, I realized the cmd+w was not working again. Wandering, I found that the TWM shortcuts were defined for a lot of morphs, in this way, causing a little of trouble: > > > > {PasteUpMorph. SystemWindow. SmalltalkEditor. TextEditor. PluggableTextMorph} do: [:aClass| > > aBuilder > > attachShortcutCategory: self shortcutCategory > > to: aClass. > > ]. > > > > But replacing it by > > > > aBuilder > > attachShortcutCategory: self shortcutCategory > > to: PasteUpMorph. > > > > should be working the same way :/. > > Laurent, did you have any problems when not attaching the categories in this way?. > > > > Also: TWM by default has a lot of (cmd+w, ...) mappings colliding with the window cmd+w shortcut. So the window shortcut or the TWM ones are to be sacrificed :P. > > > > > > So i installed TWM without keybinding but now I cannot open the settings window because keymappings is not load. > > > > Any solution? (install TWM without keymappings or fixing keymappings) > > > > I've done some fixes and improvements to keymapping, and I've created a 2.0 version where: > > > > - the collisions below are fixed > > - keymaps can be configured per morph instance too (not only per class, as the former version) > > - some little improvements and code cleaning > > > > But those things I remarked of TWM should be reviewed :) > > > > Or you can Use twm without keymappings and I'll have no more feedback :( > > > > > > thanks! > > > > Thank you :) > > > > Guille > > >

Oct. 16, 2011

[Pharo-project] why doing RPackage is a pain

by StÃ©phane Ducasse

RPackage is nice simple fast and robust now the integration within categories crap and packageInfo and PackageOrganizer and MCWorkingCopies.... are a pain. Examples: MCWorkingCopy allManagers size 177 PackageOrganizer default packages size 422 Stef :(

Oct. 16, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by Guillermo Polito

Hi! On Sun, Oct 16, 2011 at 4:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guillermo > > I would like to push Keymapping in the core. > Do you think that it is ready? > I think it has not ugly bugs. Esteban (another early adopter :D) found some little issues I fixed in the last weeks. Also, most issues (like the ones of this email) usually appear from inconsistent shortcut definitions, not from a bug in the framework. I don't know how other users (if any) feel it, but I feel it stable enough. But, on the other way, until I make experience integrating it with OB, task manager, etc.. I don't know if it fits every usage in the image, so I don't know if it needs to be changed in some way :). But it is difficult to make it evolve right now... Guille > Like that we could remove the hardcoded way. > Stef > > > > > > On Sat, Oct 15, 2011 at 9:47 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > Hi guys. I was trying to use TWM in Pharo 1.3 release. TWM brings with > keymappings, which breaks the shortcuts of my image. > > > > The main problem here is that it's not integrated with current tools > (i.e. OB). If you just load Keymapping you will have an image where: > > - lots of shortcuts are hardcoded > > - some shortcuts like OB's are handled with it's own and specific > way/framework > > > > Having keymapping living with those, introduces a third way of handling > shortcuts (yeap, it's not good enough, but It's not easy to remove all the > old code in a row ). So, the following problems happens: > > > > - first of all, there are shortcuts collisions. If a morph handles cmd + > a and its owner handles cmd + a, cmd + b, the owner morph will never handle > the shortcut because it was handled by it's child first. > > - second. It's hard to keep track and find every hardcoded shortcut :). > And furthermore, this leads in the fact that I cannot easily analyse > shortcuts collisions between keymapping and hardcoded shortcuts. > > > > So, how does Keymapping live with that by now? > > 1) a keyEvent reaches a morph > > 2) the morph delegates the handling in keymapping (bubbling until the > world instance). > > 3) if keymapping does not handle the shortcut, It is delegated to the > old-hardcoded shortcuts (so the original behavior is still there yet) > > > > All this is just to understand what is happening and where the errors > come from :P > > > > For example, after installing keymappings I cannot close windows anymore > with cmd + w or I cannot run tests from the browser using cmd + t. > > > > So far, I've found those two collisions in keymapping 1.9 and one more in > keymapping+TWM: > > > > 1) Cmd+w was defined for TextEditor for delete backword. > > > > Esteban already complained about this, so I've changed it in 2.0 for Cmd > + Backspace > > This shortcut was taken from SimpleEditor, in #initializeCmdKeyShortcuts. > I don't know if it should be there or not. > > > > 2) Cmd+t from omnibrowser was colliding with some global shortcuts I > defined in the initial versions of keymapping to play opening a test runner, > a browser, a monticello browser. > > > > I've fixed it removing the global shortcuts by now (because I'm not > conviced the key combinations are nice). > > > > 3) When loading TWM + Keymapping, I realized the cmd+w was not working > again. Wandering, I found that the TWM shortcuts were defined for a lot of > morphs, in this way, causing a little of trouble: > > > > {PasteUpMorph. SystemWindow. SmalltalkEditor. TextEditor. > PluggableTextMorph} do: [:aClass| > > aBuilder > > attachShortcutCategory: self shortcutCategory > > to: aClass. > > ]. > > > > But replacing it by > > > > aBuilder > > attachShortcutCategory: self shortcutCategory > > to: PasteUpMorph. > > > > should be working the same way :/. > > Laurent, did you have any problems when not attaching the categories in > this way?. > > > > Also: TWM by default has a lot of (cmd+w, ...) mappings colliding with > the window cmd+w shortcut. So the window shortcut or the TWM ones are to be > sacrificed :P. > > > > > > So i installed TWM without keybinding but now I cannot open the settings > window because keymappings is not load. > > > > Any solution? (install TWM without keymappings or fixing keymappings) > > > > I've done some fixes and improvements to keymapping, and I've created a > 2.0 version where: > > > > - the collisions below are fixed > > - keymaps can be configured per morph instance too (not only per class, > as the former version) > > - some little improvements and code cleaning > > > > But those things I remarked of TWM should be reviewed :) > > > > Or you can Use twm without keymappings and I'll have no more feedback :( > > > > > > thanks! > > > > Thank you :) > > > > Guille > > >

Oct. 16, 2011

[Pharo-project] KeyMapping bug: set to default

by laurent laffont

Hi Guillermo, with KeyMapping loaded, open Settings Browser, select a shortcut, right-click, set to default => Message not understood ex. for Move cursor end: KMSettings class(Object)>>doesNotUnderstand: #cursorEnd: Laurent.

Oct. 16, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by Guillermo Polito

On Sun, Oct 16, 2011 at 5:11 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > >>> >> OK so cmd+w is definitely not a good prefix for TWM shortcuts. Is cmd+m >> better ? >> >> > oups Cmd+m not a good idea :) I struggle to find a good prefix..... > Haha! If you do that you'll lose the implementors shortcut :P. BTW, I think the whole shortcuts are to be rethought. Maybe the UI centered team can make some suggestion :). I can only think right now in the shortcut sets of eclipse or jetbrains tools... > > Laurent. > > > > > >> >> >>> So i installed TWM without keybinding but now I cannot open the settings >>>> window because keymappings is not load. >>>> >>>> Any solution? (install TWM without keymappings or fixing keymappings) >>>> >>> >>> I've done some fixes and improvements to keymapping, and I've created a >>> 2.0 version where: >>> >>> - the collisions below are fixed >>> - keymaps can be configured per morph instance too (not only per class, >>> as the former version) >>> - some little improvements and code cleaning >>> >> >> >> Thanks ! >> >> >> But those things I remarked of TWM should be reviewed :) >>> >>> Or you can Use twm without keymappings and I'll have no more feedback :( >>> >> >> >> TWM without Keymapping is not really interesting. I will produce new >> versions of TWM. >> >> Laurent >> >> >> >>> >>> >>>> >>>> thanks! >>>> >>> >>> Thank you :) >>> >>> Guille >>> >> >> >

Oct. 16, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by laurent laffont

On Sun, Oct 16, 2011 at 8:37 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Thanks Laurent. It is working. Maybe you can show the shortcuts lists from > some menu or somewhere from TWM? otherwise none user will ever see it ... > Open the Settings Browser, all KeyMapping shortcuts under Keymappings and you can change them :) Laurent > > thanks! > > > On Sun, Oct 16, 2011 at 2:49 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> On Sun, Oct 16, 2011 at 12:32 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Thanks Guille for the whole work :) >>> >>> Laurent: let me know when I can use TWM properly with this latest version >>> of keymappings. >>> >> >> >> There's a new (development) version: >> - package TWM split into several packages >> - KeyMapping 2.0 >> - TWM shortcut prefix is now Cmd+r (see TWMKeymapping class>>#shortcuts >> for default shortcuts. Feel free to adapt and suggests better ones). >> - You can load TWM without KeyMapping >> using: ConfigurationOfTilingWindowManager loadDevelopmentWithoutKeyMapping. >> >> As a side note, this is the configuration I use in my Pharo images: >> >> Gofer it >> squeaksource: 'TilingWindowManager'; >> package: 'ConfigurationOfTilingWindowManager'; >> load. >> (Smalltalk at:#ConfigurationOfTilingWindowManager) loadDevelopment. >> (Smalltalk at:#TWMUITheme) beCurrent. >> TaskbarMorph showTaskbar: false. >> TasklistMorph keepOpen: true. >> (Smalltalk at:#TWMBar) perform: #showTWMBar: with: true. >> >> >> Cheers, >> >> Laurent Laffont >> >> >>> >>> Thanks guys >>> >>> >>> On Sun, Oct 16, 2011 at 10:11 AM, laurent laffont < >>> laurent.laffont(a)gmail.com> wrote: >>> >>>> >>>>>> >>>>> OK so cmd+w is definitely not a good prefix for TWM shortcuts. Is cmd+m >>>>> better ? >>>>> >>>>> >>>> oups Cmd+m not a good idea :) I struggle to find a good prefix..... >>>> >>>> Laurent. >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>>> So i installed TWM without keybinding but now I cannot open the >>>>>>> settings window because keymappings is not load. >>>>>>> >>>>>>> Any solution? (install TWM without keymappings or fixing keymappings) >>>>>>> >>>>>> >>>>>> I've done some fixes and improvements to keymapping, and I've created >>>>>> a 2.0 version where: >>>>>> >>>>>> - the collisions below are fixed >>>>>> - keymaps can be configured per morph instance too (not only per >>>>>> class, as the former version) >>>>>> - some little improvements and code cleaning >>>>>> >>>>> >>>>> >>>>> Thanks ! >>>>> >>>>> >>>>> But those things I remarked of TWM should be reviewed :) >>>>>> >>>>>> Or you can Use twm without keymappings and I'll have no more feedback >>>>>> :( >>>>>> >>>>> >>>>> >>>>> TWM without Keymapping is not really interesting. I will produce new >>>>> versions of TWM. >>>>> >>>>> Laurent >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> thanks! >>>>>>> >>>>>> >>>>>> Thank you :) >>>>>> >>>>>> Guille >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 16, 2011