learning from errors....
I was looking at the LoadingMorph BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense! And it uses a state pattern, which is ok but there is not needed to create a new state all time. SmallCogInitialState >> nextState ^ SmallCogState2 new nextState ^ SmallCogState3 new We can have a state pattern without creating garbage all the time. Now I wonder who is using this LoadingMorph? Stef
Good catch. At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter. Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important. Uko
On 24 Nov 2015, at 19:51, stepharo <stepharo@free.fr> wrote:
BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense!
Hi Yiruy when do you use it because I could see it in action? We can package the animation out of komitter and fix this ugly state pattern (so naive :)). Stef Le 24/11/15 19:58, Yuriy Tymchuk a écrit :
Good catch.
At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter.
Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important.
Uko
On 24 Nov 2015, at 19:51, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense!
I use it when you switch classes and methods. To avoid interrupting method browsing I set a loading morph and have an async task with a priority lower than UI. When there is no UI interaction the task gets critics and displays them. Usually the âloadingâ morph is there only for a fraction of a second, but if you are on a class with dozens of ivars and even more methods, then it can take a longer time. I donât feel that the spinning cog is important there, but also I think that it would be nice if we have some âin progressâ indicator. Maybe there is already something in Bric though. Cheers. Uko
On 24 Nov 2015, at 20:49, stepharo <stepharo@free.fr> wrote:
Hi Yiruy
when do you use it because I could see it in action? We can package the animation out of komitter and fix this ugly state pattern (so naive :)).
Stef
Le 24/11/15 19:58, Yuriy Tymchuk a écrit :
Good catch.
At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter.
Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important.
Uko
On 24 Nov 2015, at 19:51, stepharo < <mailto:stepharo@free.fr>stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense!
What I think is that if we want to keep it we should make sure: - it does not create garbage all the time. - pckage it well (in a separate package) should be easy. - forms are cached (I checked and they are). Stef Le 24/11/15 20:58, Yuriy Tymchuk a écrit :
I use it when you switch classes and methods.
To avoid interrupting method browsing I set a loading morph and have an async task with a priority lower than UI. When there is no UI interaction the task gets critics and displays them. Usually the âloadingâ morph is there only for a fraction of a second, but if you are on a class with dozens of ivars and even more methods, then it can take a longer time.
I donât feel that the spinning cog is important there, but also I think that it would be nice if we have some âin progressâ indicator. Maybe there is already something in Bric though.
Cheers. Uko
On 24 Nov 2015, at 20:49, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi Yiruy
when do you use it because I could see it in action? We can package the animation out of komitter and fix this ugly state pattern (so naive :)).
Stef
Le 24/11/15 19:58, Yuriy Tymchuk a écrit :
Good catch.
At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter.
Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important.
Uko
On 24 Nov 2015, at 19:51, stepharo <stepharo@free.fr> wrote:
BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense!
I saw when browsing Morph :) Stef Le 24/11/15 19:58, Yuriy Tymchuk a écrit :
Good catch.
At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter.
Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important.
Uko
On 24 Nov 2015, at 19:51, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense!
You could use one of those images and rotate it when drawing, changing the angle by #step. I attached an example. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Yuriy Tymchuk Sent: Tuesday, November 24, 2015 7:58 PM To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] learning from errors.... Good catch. At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter. Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important. Uko On 24 Nov 2015, at 19:51, stepharo <stepharo@free.fr<mailto:stepharo@free.fr>> wrote: BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense!
Hi henrik indeed and no need 4 classes 3 singletons and a garbage collector stresser. Stef Le 25/11/15 00:34, Henrik Nergaard a écrit :
You could use one of those images and rotate it when drawing, changing the angle by #step.
I attached an example.
Best regards,
Henrik
*From:*Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf Of *Yuriy Tymchuk *Sent:* Tuesday, November 24, 2015 7:58 PM *To:* Pharo Development List <pharo-dev@lists.pharo.org> *Subject:* Re: [Pharo-dev] learning from errors....
Good catch.
At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter.
Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important.
Uko
On 24 Nov 2015, at 19:51, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense!
Reading the code once again. I do not think that we need a state pattern. What is needed is just a list of (form time) and iterate over them. May be I'm wrong but it looks like we do not need three classes for that. Le 24/11/15 19:51, stepharo a écrit :
I was looking at the LoadingMorph BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense!
And it uses a state pattern, which is ok but there is not needed to create a new state all time.
SmallCogInitialState >> nextState
^ SmallCogState2 new
nextState
^ SmallCogState3 new
We can have a state pattern without creating garbage all the time.
Now I wonder who is using this LoadingMorph? Stef
participants (3)
-
Henrik Nergaard -
stepharo -
Yuriy Tymchuk