Hi Marcus, I think 13102 is a showstopper. Canât explain this to new users. Stephan
Stephan Eggermont wrote
I think 13102 is a showstopper. Canât explain this to new users.
I don't have an opinion on this, but 'showstopper' ~= 'Canât explain this to new users'. Try explaining our Morphic implementation to new users ;-P ----- Cheers, Sean -- View this message in context: http://forum.world.st/13102-tp4754417p4754446.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
This is unfair to Morphic! Le 13 avr. 2014 16:52, "Sean P. DeNigris" <sean@clipperadams.com> a écrit :
Stephan Eggermont wrote
I think 13102 is a showstopper. Can't explain this to new users.
I don't have an opinion on this, but 'showstopper' ~= 'Can't explain this to new users'. Try explaining our Morphic implementation to new users ;-P
----- Cheers, Sean -- View this message in context: http://forum.world.st/13102-tp4754417p4754446.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2014-04-13 15:50 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
Stephan Eggermont wrote
I think 13102 is a showstopper. Can't explain this to new users.
I don't have an opinion on this, but 'showstopper' ~= 'Can't explain this to new users'. Try explaining our Morphic implementation to new users ;-P
I am on the "You create some objects, or not, and send them some messages, and then morphs do stuff sometimes. Or something." stage. Cheers, Sergi
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@stack.nl> wrote:
Hi Marcus,
I think 13102 is a showstopper. Canât explain this to new users.
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
On 14 Apr 2014, at 14:28, Marcus Denker <marcus.denker@inria.fr> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@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
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@lists.pharo.org] de la part de Esteban Lorenzano [estebanlm@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@inria.fr> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@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
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@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@lists.pharo.org] de la part de Esteban Lorenzano [estebanlm@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@inria.fr> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@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"
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@lists.pharo.org] de la part de Tudor Girba [tudor@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@cea.fr<mailto:thierry.goubier@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@lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] de la part de Esteban Lorenzano [estebanlm@gmail.com<mailto:estebanlm@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@inria.fr<mailto:marcus.denker@inria.fr>> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@stack.nl<mailto:stephan@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<http://www.tudorgirba.com> "Every thing has its own flow"
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@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@lists.pharo.org] de la part de Tudor Girba [tudor@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@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@lists.pharo.org] de la part de Esteban Lorenzano [estebanlm@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@inria.fr> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@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"
Ok, I have been carrying around a fix to that for what? More than a year, in my code. It's a very simple fix. It does require agreement on the fact this is a problem and that a solution is needed, that's all :) (i.e. I see two problems: 1) collision between exactly same shortcuts at global and local level, and 2) collision between single key shortcut and start of multikey shortcut. 1), I have, it's two lines in KMDispatcher. 2) is a bit more complex). Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Tudor Girba [tudor@tudorgirba.com] Envoyé : lundi 14 avril 2014 15:31 à : Pharo Development List Objet : Re: [Pharo-dev] 13102 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@cea.fr<mailto:thierry.goubier@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@lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] de la part de Tudor Girba [tudor@tudorgirba.com<mailto:tudor@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@cea.fr<mailto:thierry.goubier@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@lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] de la part de Esteban Lorenzano [estebanlm@gmail.com<mailto:estebanlm@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@inria.fr<mailto:marcus.denker@inria.fr>> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@stack.nl<mailto:stephan@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<http://www.tudorgirba.com> "Every thing has its own flow" -- www.tudorgirba.com<http://www.tudorgirba.com> "Every thing has its own flow"
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@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@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@lists.pharo.org] de la part de Tudor Girba [tudor@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@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@lists.pharo.org] de la part de Esteban Lorenzano [estebanlm@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@inria.fr> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@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"
On Mon, Apr 14, 2014 at 4:18 PM, Guillermo Polito <guillermopolito@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@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@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@lists.pharo.org] de la part de Tudor Girba [tudor@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@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@lists.pharo.org] de la part de Esteban Lorenzano [estebanlm@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@inria.fr> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@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"
On Mon, Apr 14, 2014 at 4:23 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
On Mon, Apr 14, 2014 at 4:18 PM, Guillermo Polito < guillermopolito@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@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@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@lists.pharo.org] de la part de Tudor Girba [tudor@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@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@lists.pharo.org] de la part de Esteban Lorenzano [estebanlm@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@inria.fr> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@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"
Bump :) On Mon, Apr 14, 2014 at 4:30 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
On Mon, Apr 14, 2014 at 4:23 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
On Mon, Apr 14, 2014 at 4:18 PM, Guillermo Polito < guillermopolito@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.
So, any points against or in favor to this?
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).
Do we open a new thread to discuss this? I think it's important to discuss what is available globally through a shortcut and what's not, and what such shortcuts should be. The only thing I need is: - Spotlight - Finder? - Workspace? - The main menu? The browser I don't really need it because I use spotlight. The finder can cover almost all stuff I search normally trough a workspace :). Even if this is not for Pharo3, it's important for Pharo4.
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@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@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@lists.pharo.org] de la part de Tudor Girba [tudor@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@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@lists.pharo.org] de la part de Esteban Lorenzano [estebanlm@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@inria.fr> wrote:
On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan@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"
Ok, my position: 1) local shortcut should not override global shortcuts, but see 2) 2) global shortcuts should be as restricted as they are in a normal desktop (see your OS HIG documentation for that) - Suggestion: create a namespace with a prefix for application triggering global shortcuts, where each app can add his (x ctrl + w for opening a Workspace, x ctrl + etc...) 4) Warn of overlapping when adding shortcuts. 3) Remove that set :) Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Guillermo Polito [guillermopolito@gmail.com] Envoyé : mercredi 16 avril 2014 11:46 à : Pharo Development List Objet : Re: [Pharo-dev] 13102 Bump :) On Mon, Apr 14, 2014 at 4:30 PM, Guillermo Polito <guillermopolito@gmail.com<mailto:guillermopolito@gmail.com>> wrote: On Mon, Apr 14, 2014 at 4:23 PM, Guillermo Polito <guillermopolito@gmail.com<mailto:guillermopolito@gmail.com>> wrote: On Mon, Apr 14, 2014 at 4:18 PM, Guillermo Polito <guillermopolito@gmail.com<mailto:guillermopolito@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. So, any points against or in favor to this? 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). Do we open a new thread to discuss this? I think it's important to discuss what is available globally through a shortcut and what's not, and what such shortcuts should be. The only thing I need is: - Spotlight - Finder? - Workspace? - The main menu? The browser I don't really need it because I use spotlight. The finder can cover almost all stuff I search normally trough a workspace :). Even if this is not for Pharo3, it's important for Pharo4.
participants (9)
-
Esteban Lorenzano -
GOUBIER Thierry -
Guillermo Polito -
Marcus Denker -
phil＠highoctane.be -
Sean P. DeNigris -
Sergi Reyner -
Stephan Eggermont -
Tudor Girba