April 2014 - Pharo-dev - lists.pharo.org

[ANN] RenoirSt 1.3.0 released!

by Gabriel Cotelli

Hi, I'm announcing a new official release of RenoirSt, a DSL enabling programmatic cascading style sheet generation for Pharo. Changelog 1.3.0 - Issue #27 Add missing background and border properties and constants - Issue #31 Added missing Text Decoration properties and constants - Issue #35 Reviewed Code Critics - Issue #39 Support for stand-alone comments (Requested by Maxi Tabacman) - Issue #40 Gradient Support - Updated Tutorial Load it in your Pharo 3 image using the Configuration Browser (RenoirSt y RenoirStPlusSeaside configuratios), or visit the project page<http://gcotelli.github.io/RenoirSt/> and GitHub repository <https://github.com/gcotelli/RenoirSt> for more information on the supported and planned features, and check-out the online tutorial.<https://github.com/gcotelli/RenoirSt/blob/stable/docs/tutorial/Tutorial%20-…> I hope you find it useful. Feel free to ask any questions, suggest ideas and improvements, or report bugs<https://github.com/gcotelli/RenoirSt/issues> .

April 14, 2014

Re: [Pharo-dev] [OT] Pharo-Amber stack screencast

by Esteban A. Maringolo

2014-04-14 15:31 GMT-03:00 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: > Hi, I get > > Internal Error: BITSession>>currentUser Clear Chrome's cache. Or open it in other browser. Esteban A. Maringolo

April 14, 2014

Re: [Pharo-dev] [OT] Pharo-Amber stack screencast

by Javier PimÃ¡s

Hi, I get Internal Error: BITSession>>currentUser for both links. Cheers, Javier On Mon, Apr 14, 2014 at 2:59 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > > > > > On Apr 11, 2014, at 4:47 PM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > I would also have liked more details on the network communications. > 1 websocket per webpage? > home-made protocol? > > > And here it comes some additional details on Part 2 > http://blog.flowingconcept.com/brandIt/a-tour-on-tasks-part-ii > > enjoy > > feel free to ask additional questions, comment and rate! > > > > sebastian <https://about.me/sebastianconcept> > > o/ > > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

April 14, 2014

Re: [Pharo-dev] [OT] Pharo-Amber stack screencast

by Sebastian Sastre

On Apr 11, 2014, at 4:47 PM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > I would also have liked more details on the network communications. > 1 websocket per webpage? > home-made protocol? > And here it comes some additional details on Part 2 http://blog.flowingconcept.com/brandIt/a-tour-on-tasks-part-ii enjoy feel free to ask additional questions, comment and rate! sebastian o/

April 14, 2014

Re: [Pharo-dev] Smalltalkhub & API

by Sean P. DeNigris

philippeback wrote > I just wanted to have my projects repos added to my preferences file. > ... > So, yes, an API would be nice I had the same use case, so I implemented just that one to get the ball rolling. I just wrote my own custom project class but maybe it would be better to reuse the one from sthub itself? Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; configurationOf: 'SmalltalkHubAPI'; loadStable. projects := #SthAPI asClass new projectsFor: 'your sth user/team name here'. projects do: [ :e | Transcript show: 'Adding repo for ', e name, ' to default group'; cr. e addMcRepository ]. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Smalltalkhub-API-tp4751207p4754581.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 14, 2014

[pharo-project/pharo-core] 08a0ea: 30825

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 08a0eacc0b2178c3fb5fd1e3f9c04874a59a017e https://github.com/pharo-project/pharo-core/commit/08a0eacc0b2178c3fb5fd1e3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-04-14 (Mon, 14 Apr 2014) Changed paths: M KernelTests.package/ClassHierarchyTest.class/class/fixing/fixSubclasses.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script478.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30825.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Spec-Examples.package/ImageSpecExample.class/README.md R Spec-Examples.package/ImageSpecExample.class/class/accessing/spec.st R Spec-Examples.package/ImageSpecExample.class/class/instance creation/open.st R Spec-Examples.package/ImageSpecExample.class/definition.st R Spec-Examples.package/ImageSpecExample.class/instance/accessing/imageModel.st R Spec-Examples.package/ImageSpecExample.class/instance/accessing/imageModel_.st R Spec-Examples.package/ImageSpecExample.class/instance/initialization/initializePresenter.st R Spec-Examples.package/ImageSpecExample.class/instance/initialization/initializeWidgets.st Log Message: ----------- 30825 12836 ImageSpecExample throws DNU https://pharo.fogbugz.com/f/cases/12836 http://files.pharo.org/image/30/30825.zip

April 14, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30825 Home: https://github.com/pharo-project/pharo-core

April 14, 2014

Re: [Pharo-dev] 13102

by Guillermo Polito

On Mon, Apr 14, 2014 at 4:23 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > > > On Mon, Apr 14, 2014 at 4:18 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi! >> >> Sorry for the late response... I'm covered with stuff to do lately. >> >> To my understanding we are mixing these different issues: >> >> 1) whether the global shortcuts should have or not priority over local >> shortcuts. To my understanding that's what operating systems do. You cannot >> override alt+tab and if you intend, it will just not work. If any >> application can override alt+tab, the system will feel inconsistent for the >> users. So global shortcuts have priority with this intend: Not let the >> tools mess with what Pharo has decided the global shortcuts should be. >> >> 2) which are the actions that should be available globally though a >> shortcut. This deserves for sure a different discussion than 1). Should we >> put all tools in there? The more we put, the more difficult is to put >> shortcuts locally in tools. In any case I think this is orthogonal to 1). >> >> 3) are the shortcuts we chose for the tools the right ones? I think the >> "prefixed" shortcuts chosen for the tools were thought as a kind of >> namespace for the shortcuts. Again, I find this orthogonal to 1). >> >> 4) About the collision issue. First, it is an issue that appeared when >> people started to use keymappings :). The original intent was to let the >> user manage the collisions, because I find there is not a perfect solution. >> - if we make first single, then complex matching only local to a morph, >> then a complex match from a child would override a single match from a >> parent. >> - if we make first single, then complex matching *all over the >> hierarchy*, we may find a single match from a parent overriding a complex >> shortcut of a child. >> > > Just to complete my thoughts and provide my position about this issue. I > would rather go for the first solution: favor local over global resolution > because we will find less bugs. > And here I meant by global resolution = *all over the hierarchy*, silly me, I'm hungry. > > >> >> A second issue, partially related to the resolution strategy, is the Set >> that should not be there because it provides a random ingredient. However, >> at the same time it makes you think about not creating collisions in the >> same morph :). Actually, if you remove the randomness and configure a morph >> with: >> >> cmd+a => do something >> cmd+a, cmd+b => do other something >> >> Either the first or the second will never be executed depending on the >> strategy you choose (first single then complex, or the opposite). So I find >> this a buggy configuration, randomness or not randomness. >> >> >> Cheers, >> Guille >> >> >> >> On Mon, Apr 14, 2014 at 3:31 PM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >> >>> Hi, >>> >>> I agree that the behavior is not ideal, but it only occurs when you have >>> collisions. And of course it would be great to have everything working >>> perfectly, but at this point it is more important to release. That is why, >>> in my book, it is more important to reduce the impact (fast) than it is to >>> solve it properly (slow). >>> >>> The problem was noticed in few cases. I for one only noticed it after >>> the global shortcuts were introduced in the image. Hence, it is very likely >>> to achieve a good enough state with little effort by removing the shortcuts. >>> >>> Of course, if someone else does have a better solution, he can propose >>> it, but it has to be concrete and doubled by the effort that comes with >>> developing and testing it :) >>> >>> Doru >>> >>> >>> On Mon, Apr 14, 2014 at 3:22 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr >>> > wrote: >>> >>>> Tudor, >>>> >>>> an implementation which randomly determines which shortcut will match >>>> is a bug to me, and one worthy of being solved before release. >>>> >>>> Why wouldn't Moose alone desactivate the global shortcuts if that seems >>>> the solution? >>>> >>>> Thierry >>>> >>>> ------------------------------ >>>> *De :* Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de >>>> Tudor Girba [tudor(a)tudorgirba.com] >>>> *EnvoyÃ© :* lundi 14 avril 2014 15:15 >>>> >>>> *Ã :* Pharo Development List >>>> *Objet :* Re: [Pharo-dev] 13102 >>>> >>>> Hi, >>>> >>>> Sorry for not replying before but I was offline. This issue is not to >>>> fix Keymapping at this point. The current solution was designed with intent >>>> to work in the current way. We can certainly discuss about fixing it, but >>>> the solution is not for Pharo 3. >>>> >>>> The current discussion is about disabling the global shortcuts for >>>> opening the Workspace and other tools. In the Moose image, we disable those >>>> shortcuts because with the current implementation of Keymapping having >>>> complicated global keybindings simply leads to problems (for example, we >>>> cannot use Cmd+o for anything). Do not get me wrong: Keymapping is an >>>> excellent contribution that simplified a lot an important area. My >>>> suggestion is to remove the global mappings for Pharo 3.0, and then >>>> continue to work on getting Keymappings to an even better state. >>>> >>>> Doru >>>> >>>> >>>> On Mon, Apr 14, 2014 at 2:49 PM, GOUBIER Thierry < >>>> thierry.goubier(a)cea.fr> wrote: >>>> >>>>> Hi Esteban, Marcus, >>>>> >>>>> in that particular case, I would propose the following simple fix >>>>> which could solve the first impression. >>>>> - Document global shortcuts, ensure that they are single key. >>>>> - Document an overload (or not) effect when your app redefines a >>>>> global shortcut. >>>>> - Change a bit Keymapping so that single key shortcuts match first. >>>>> >>>>> This would solve the immediate problem and let us time to consider a >>>>> more complex solution for Pharo 4. >>>>> >>>>> Thierry >>>>> ________________________________________ >>>>> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de >>>>> Esteban Lorenzano [estebanlm(a)gmail.com] >>>>> EnvoyÃ© : lundi 14 avril 2014 14:39 >>>>> Ã : Pharo Development List >>>>> Objet : Re: [Pharo-dev] 13102 >>>>> >>>>> On 14 Apr 2014, at 14:28, Marcus Denker <marcus.denker(a)inria.fr> >>>>> wrote: >>>>> >>>>> > >>>>> > On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan(a)stack.nl> >>>>> wrote: >>>>> > >>>>> >> Hi Marcus, >>>>> >> >>>>> >> I think 13102 is a showstopper. Canât explain this to new users. >>>>> >> >>>>> >>>>> sorry, but I have to disagreeâ¦ this is an important problem, I agree. >>>>> But fix that will need (AFAIK) a lot of work and probably a revamp of >>>>> the keybindings in system. >>>>> Alsoâ¦ this problem was (again, AFAIK) present since pharo2 and we have >>>>> been able to continue working even with that annoyance. >>>>> >>>>> We will always have problems to fix. And we still have many *really >>>>> important* problem to fix. But if we do not release even with some bugs, we >>>>> will never release. >>>>> >>>>> "Show stopperâ IMO, is a bug that prevents the system to continue >>>>> working. Explain to students an annoyance in the system is bad, but not >>>>> show stopper. >>>>> >>>>> soâ¦ Iâm with Marcus. We can delay this fix. But I also believe this >>>>> kind of problems are a âshoot in the footâ, not good for attract newcomers. >>>>> Thatâs why we are suggesting that Pharo4 should centred on the >>>>> tooling: we have the feeling that out tools are one (or several) step(s) >>>>> behind the power that pharo has. >>>>> >>>>> Esteban >>>>> >>>>> > >>>>> > The question is do we hold up the release for it? >>>>> > That is: is not releasing better than releasing with this? >>>>> > >>>>> > How long do we stop releasing, considering that we will not find >>>>> > anyone to fix it? >>>>> > >>>>> > Marcus >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >

April 14, 2014

Re: [Pharo-dev] 13102

by Guillermo Polito

On Mon, Apr 14, 2014 at 4:18 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi! > > Sorry for the late response... I'm covered with stuff to do lately. > > To my understanding we are mixing these different issues: > > 1) whether the global shortcuts should have or not priority over local > shortcuts. To my understanding that's what operating systems do. You cannot > override alt+tab and if you intend, it will just not work. If any > application can override alt+tab, the system will feel inconsistent for the > users. So global shortcuts have priority with this intend: Not let the > tools mess with what Pharo has decided the global shortcuts should be. > > 2) which are the actions that should be available globally though a > shortcut. This deserves for sure a different discussion than 1). Should we > put all tools in there? The more we put, the more difficult is to put > shortcuts locally in tools. In any case I think this is orthogonal to 1). > > 3) are the shortcuts we chose for the tools the right ones? I think the > "prefixed" shortcuts chosen for the tools were thought as a kind of > namespace for the shortcuts. Again, I find this orthogonal to 1). > > 4) About the collision issue. First, it is an issue that appeared when > people started to use keymappings :). The original intent was to let the > user manage the collisions, because I find there is not a perfect solution. > - if we make first single, then complex matching only local to a morph, > then a complex match from a child would override a single match from a > parent. > - if we make first single, then complex matching *all over the > hierarchy*, we may find a single match from a parent overriding a complex > shortcut of a child. > Just to complete my thoughts and provide my position about this issue. I would rather go for the first solution: favor local over global resolution because we will find less bugs. > > A second issue, partially related to the resolution strategy, is the Set > that should not be there because it provides a random ingredient. However, > at the same time it makes you think about not creating collisions in the > same morph :). Actually, if you remove the randomness and configure a morph > with: > > cmd+a => do something > cmd+a, cmd+b => do other something > > Either the first or the second will never be executed depending on the > strategy you choose (first single then complex, or the opposite). So I find > this a buggy configuration, randomness or not randomness. > > > Cheers, > Guille > > > > On Mon, Apr 14, 2014 at 3:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> I agree that the behavior is not ideal, but it only occurs when you have >> collisions. And of course it would be great to have everything working >> perfectly, but at this point it is more important to release. That is why, >> in my book, it is more important to reduce the impact (fast) than it is to >> solve it properly (slow). >> >> The problem was noticed in few cases. I for one only noticed it after the >> global shortcuts were introduced in the image. Hence, it is very likely to >> achieve a good enough state with little effort by removing the shortcuts. >> >> Of course, if someone else does have a better solution, he can propose >> it, but it has to be concrete and doubled by the effort that comes with >> developing and testing it :) >> >> Doru >> >> >> On Mon, Apr 14, 2014 at 3:22 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr>wrote: >> >>> Tudor, >>> >>> an implementation which randomly determines which shortcut will match is >>> a bug to me, and one worthy of being solved before release. >>> >>> Why wouldn't Moose alone desactivate the global shortcuts if that seems >>> the solution? >>> >>> Thierry >>> >>> ------------------------------ >>> *De :* Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de >>> Tudor Girba [tudor(a)tudorgirba.com] >>> *EnvoyÃ© :* lundi 14 avril 2014 15:15 >>> >>> *Ã :* Pharo Development List >>> *Objet :* Re: [Pharo-dev] 13102 >>> >>> Hi, >>> >>> Sorry for not replying before but I was offline. This issue is not to >>> fix Keymapping at this point. The current solution was designed with intent >>> to work in the current way. We can certainly discuss about fixing it, but >>> the solution is not for Pharo 3. >>> >>> The current discussion is about disabling the global shortcuts for >>> opening the Workspace and other tools. In the Moose image, we disable those >>> shortcuts because with the current implementation of Keymapping having >>> complicated global keybindings simply leads to problems (for example, we >>> cannot use Cmd+o for anything). Do not get me wrong: Keymapping is an >>> excellent contribution that simplified a lot an important area. My >>> suggestion is to remove the global mappings for Pharo 3.0, and then >>> continue to work on getting Keymappings to an even better state. >>> >>> Doru >>> >>> >>> On Mon, Apr 14, 2014 at 2:49 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr >>> > wrote: >>> >>>> Hi Esteban, Marcus, >>>> >>>> in that particular case, I would propose the following simple fix which >>>> could solve the first impression. >>>> - Document global shortcuts, ensure that they are single key. >>>> - Document an overload (or not) effect when your app redefines a >>>> global shortcut. >>>> - Change a bit Keymapping so that single key shortcuts match first. >>>> >>>> This would solve the immediate problem and let us time to consider a >>>> more complex solution for Pharo 4. >>>> >>>> Thierry >>>> ________________________________________ >>>> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de >>>> Esteban Lorenzano [estebanlm(a)gmail.com] >>>> EnvoyÃ© : lundi 14 avril 2014 14:39 >>>> Ã : Pharo Development List >>>> Objet : Re: [Pharo-dev] 13102 >>>> >>>> On 14 Apr 2014, at 14:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> >>>> > >>>> > On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> > >>>> >> Hi Marcus, >>>> >> >>>> >> I think 13102 is a showstopper. Canât explain this to new users. >>>> >> >>>> >>>> sorry, but I have to disagreeâ¦ this is an important problem, I agree. >>>> But fix that will need (AFAIK) a lot of work and probably a revamp of >>>> the keybindings in system. >>>> Alsoâ¦ this problem was (again, AFAIK) present since pharo2 and we have >>>> been able to continue working even with that annoyance. >>>> >>>> We will always have problems to fix. And we still have many *really >>>> important* problem to fix. But if we do not release even with some bugs, we >>>> will never release. >>>> >>>> "Show stopperâ IMO, is a bug that prevents the system to continue >>>> working. Explain to students an annoyance in the system is bad, but not >>>> show stopper. >>>> >>>> soâ¦ Iâm with Marcus. We can delay this fix. But I also believe this >>>> kind of problems are a âshoot in the footâ, not good for attract newcomers. >>>> Thatâs why we are suggesting that Pharo4 should centred on the tooling: >>>> we have the feeling that out tools are one (or several) step(s) behind the >>>> power that pharo has. >>>> >>>> Esteban >>>> >>>> > >>>> > The question is do we hold up the release for it? >>>> > That is: is not releasing better than releasing with this? >>>> > >>>> > How long do we stop releasing, considering that we will not find >>>> > anyone to fix it? >>>> > >>>> > Marcus >>>> > >>>> > >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

April 14, 2014

Re: [Pharo-dev] 13102

by Guillermo Polito

Hi! Sorry for the late response... I'm covered with stuff to do lately. To my understanding we are mixing these different issues: 1) whether the global shortcuts should have or not priority over local shortcuts. To my understanding that's what operating systems do. You cannot override alt+tab and if you intend, it will just not work. If any application can override alt+tab, the system will feel inconsistent for the users. So global shortcuts have priority with this intend: Not let the tools mess with what Pharo has decided the global shortcuts should be. 2) which are the actions that should be available globally though a shortcut. This deserves for sure a different discussion than 1). Should we put all tools in there? The more we put, the more difficult is to put shortcuts locally in tools. In any case I think this is orthogonal to 1). 3) are the shortcuts we chose for the tools the right ones? I think the "prefixed" shortcuts chosen for the tools were thought as a kind of namespace for the shortcuts. Again, I find this orthogonal to 1). 4) About the collision issue. First, it is an issue that appeared when people started to use keymappings :). The original intent was to let the user manage the collisions, because I find there is not a perfect solution. - if we make first single, then complex matching only local to a morph, then a complex match from a child would override a single match from a parent. - if we make first single, then complex matching *all over the hierarchy*, we may find a single match from a parent overriding a complex shortcut of a child. A second issue, partially related to the resolution strategy, is the Set that should not be there because it provides a random ingredient. However, at the same time it makes you think about not creating collisions in the same morph :). Actually, if you remove the randomness and configure a morph with: cmd+a => do something cmd+a, cmd+b => do other something Either the first or the second will never be executed depending on the strategy you choose (first single then complex, or the opposite). So I find this a buggy configuration, randomness or not randomness. Cheers, Guille On Mon, Apr 14, 2014 at 3:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I agree that the behavior is not ideal, but it only occurs when you have > collisions. And of course it would be great to have everything working > perfectly, but at this point it is more important to release. That is why, > in my book, it is more important to reduce the impact (fast) than it is to > solve it properly (slow). > > The problem was noticed in few cases. I for one only noticed it after the > global shortcuts were introduced in the image. Hence, it is very likely to > achieve a good enough state with little effort by removing the shortcuts. > > Of course, if someone else does have a better solution, he can propose it, > but it has to be concrete and doubled by the effort that comes with > developing and testing it :) > > Doru > > > On Mon, Apr 14, 2014 at 3:22 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr>wrote: > >> Tudor, >> >> an implementation which randomly determines which shortcut will match is >> a bug to me, and one worthy of being solved before release. >> >> Why wouldn't Moose alone desactivate the global shortcuts if that seems >> the solution? >> >> Thierry >> >> ------------------------------ >> *De :* Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Tudor >> Girba [tudor(a)tudorgirba.com] >> *EnvoyÃ© :* lundi 14 avril 2014 15:15 >> >> *Ã :* Pharo Development List >> *Objet :* Re: [Pharo-dev] 13102 >> >> Hi, >> >> Sorry for not replying before but I was offline. This issue is not to >> fix Keymapping at this point. The current solution was designed with intent >> to work in the current way. We can certainly discuss about fixing it, but >> the solution is not for Pharo 3. >> >> The current discussion is about disabling the global shortcuts for >> opening the Workspace and other tools. In the Moose image, we disable those >> shortcuts because with the current implementation of Keymapping having >> complicated global keybindings simply leads to problems (for example, we >> cannot use Cmd+o for anything). Do not get me wrong: Keymapping is an >> excellent contribution that simplified a lot an important area. My >> suggestion is to remove the global mappings for Pharo 3.0, and then >> continue to work on getting Keymappings to an even better state. >> >> Doru >> >> >> On Mon, Apr 14, 2014 at 2:49 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr>wrote: >> >>> Hi Esteban, Marcus, >>> >>> in that particular case, I would propose the following simple fix which >>> could solve the first impression. >>> - Document global shortcuts, ensure that they are single key. >>> - Document an overload (or not) effect when your app redefines a >>> global shortcut. >>> - Change a bit Keymapping so that single key shortcuts match first. >>> >>> This would solve the immediate problem and let us time to consider a >>> more complex solution for Pharo 4. >>> >>> Thierry >>> ________________________________________ >>> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de >>> Esteban Lorenzano [estebanlm(a)gmail.com] >>> EnvoyÃ© : lundi 14 avril 2014 14:39 >>> Ã : Pharo Development List >>> Objet : Re: [Pharo-dev] 13102 >>> >>> On 14 Apr 2014, at 14:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> > >>> > On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> > >>> >> Hi Marcus, >>> >> >>> >> I think 13102 is a showstopper. Canât explain this to new users. >>> >> >>> >>> sorry, but I have to disagreeâ¦ this is an important problem, I agree. >>> But fix that will need (AFAIK) a lot of work and probably a revamp of >>> the keybindings in system. >>> Alsoâ¦ this problem was (again, AFAIK) present since pharo2 and we have >>> been able to continue working even with that annoyance. >>> >>> We will always have problems to fix. And we still have many *really >>> important* problem to fix. But if we do not release even with some bugs, we >>> will never release. >>> >>> "Show stopperâ IMO, is a bug that prevents the system to continue >>> working. Explain to students an annoyance in the system is bad, but not >>> show stopper. >>> >>> soâ¦ Iâm with Marcus. We can delay this fix. But I also believe this kind >>> of problems are a âshoot in the footâ, not good for attract newcomers. >>> Thatâs why we are suggesting that Pharo4 should centred on the tooling: >>> we have the feeling that out tools are one (or several) step(s) behind the >>> power that pharo has. >>> >>> Esteban >>> >>> > >>> > The question is do we hold up the release for it? >>> > That is: is not releasing better than releasing with this? >>> > >>> > How long do we stop releasing, considering that we will not find >>> > anyone to fix it? >>> > >>> > Marcus >>> > >>> > >>> >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

April 14, 2014