kilon.alios wrote
> The initial intention was to not make it a singleton to allow for multiple
> instances of timers.
I could see some use cases there. My intention was just not to have to set
time/break limits on every open. Another option would be to lazily
initialize those defaults into class v
Le 05/02/2017 à 01:08, Dimitris Chloupis a écrit :
> The initial intention was to not make it a singleton to allow for
> multiple instances of timers. Hence why it's wiped out. But making it a
> singleton is something Phil asked for too, I just forgot to turn it into
> a singleton. I will update it
The initial intention was to not make it a singleton to allow for multiple
instances of timers. Hence why it's wiped out. But making it a singleton is
something Phil asked for too, I just forgot to turn it into a singleton. I
will update it tomorrow. I use only a single instance myself as well too.
Shouldn't the following be lazily initialized?
ChronosManager class>>#open
ChronosInstance := self new.
^ChronosInstance
Right now the singleton gets wiped out every time "open" is clicked in the
world menu, and one has to recustomize e.g. time and break limits...
-
Cheers,
Sean
--
Vie
I guess we can find better qualified people about UI quality than me ;-)
Doru or Johan are examples.
Envoyé de mon iPhone
> Le 4 févr. 2017 à 21:07, Cyril Ferlicot D. a écrit
> :
>
>> Le 04/02/2017 à 20:46, Hilaire a écrit :
>> Will Serge, Dimitris willing to join in with me?
>>
>> Hilaire
>>
Le 04/02/2017 à 20:46, Hilaire a écrit :
> Will Serge, Dimitris willing to join in with me?
>
> Hilaire
>
> Le 04/02/2017 à 18:26, stepharong a écrit :
>>> How does it sound?
>>
>> good but will we find these people?
>
If you create a mailing list I would be interested to subscribe.
I would li
Will Serge, Dimitris willing to join in with me?
Hilaire
Le 04/02/2017 à 18:26, stepharong a écrit :
>> How does it sound?
>
> good but will we find these people?
--
Dr. Geo
http://drgeo.eu
Damned you are inferring a lot on my writing, but I understand now.
In my previous post I had no argument against the *new* debugger, nor I
wrote its interface degraded. I just made an absolute remark regarding
lack of information on non obvious function, in the debugger in my
example, which apply
On Fri, 03 Feb 2017 22:20:28 +0100, Hilaire wrote:
UI quality team could be fun.
Here are some ideas how it could be organised:
- at least 3/5/7 persons looking at issues and reporting it. Why three?
Easier to decide and UI may for some part be very opinionated
These persons could discuss how
It would be nice to have a palette class with some nice defaults.
Cyril could you package what you have in MDL out of MDL so that we can add
it to Pharo?
Stef
And there are useful A11Y (Accessibility combos down the page)
http://clrs.cc/a11y/
Phil
On Thu, Feb 2, 2017 at 7:38 PM, stephar
Hilaire
can you create bug entry to little usability glitches. Esteban told me
that he will do a pass.
Stef
On Fri, 03 Feb 2017 09:21:18 +0100, Hilaire wrote:
A UI quality team review would be needed before each Pharo release, I
mean with a real constraint to postpone release until a good
Well, we got a real Debugger Model which says:
DebugSession>>#stepInto: aContext
"Send the selected message in selectedContext, and take control in
the method invoked to allow further step or send."
DebugSession>>#stepOver: aContext
"Send the selected message in selectedC
> > On Feb 3, 2017, at 13:29, Hilaire wrote:
> >
> > what are the differences between 'over' and 'through' buttons in the
> > debugger.
On Sat, Feb 4, 2017 at 8:09 AM, John Pfersich wrote:
>
> The over button means step over the message highlighted, the through button
> means step into the mess
13 matches
Mail list logo
