Smalltalk › Pharo › Pharo Smalltalk Users

These beautiful tooltips

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

49 messages Options

123

HilaireFernandes

Re: These beautiful tooltips

Blue is fine too. It was so before.

Le 31/01/2017 à 14:14, Ben Coman a écrit :
> Any opinions from the rest of the community on making one of those two default?

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

stepharong

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by HilaireFernandes

On Tue, 31 Jan 2017 13:52:54 +0100, Hilaire <[hidden email]> wrote:

> I would like to help in both accessibility and implementation detail of
> the theme. In the other hand I fell we are in such flux with the future
> UI in Pharo. What are the grounds we can stand on regarding UI?

Improve now.
Think later.
Bloc/Brick will not be ready before some versions of Pharo.

>
> Hilaire
>
> Le 31/01/2017 à 11:21, [hidden email] a
> écrit :
>> Well there is no subclass of GLMBrickColorThemer so dark themes get
>> hardcoded light colors in places for example.
>>
>

--
Using Opera's mail client: http://www.opera.com/mail/

stepharong

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by Paul DeBruicker

+1 there are colors that I cannot see well in the drak theme and I'm not
disabled or color blind.

> One way to address this going forward is for theme developers to check
> their
> color selections against the e.g. Web Content Accessibility Guidelines
> (https://www.w3.org/TR/WCAG20/)
>
> Using a readily available tool:
>
> https://leaverou.github.io/contrast-ratio/
>
>
> And/or one that makes suggestions of contrasting colors for a palette:
>
> http://colorsafe.co
>
>
> And all themes could be subject to passing at a minimum contrast grade
> (AA
> seems not too hard?) before being added to the core. And in that way we
> have
> a standard of 'good enough' that is more widely accepted than 'works on
> my
> machine, for my eyes, in this physical space, with this ambient lighting'
>
>
> Paul
>
>
>
>
>
>
>
> HilaireFernandes wrote
>> Hi,
>>
>> So in Pharo5 we have these 'beautiful' unreadable tooltips: tiny black
>> font on light gray (ie. take a look to its squeak counter part, it looks
>> so much more pro)
>>
>> Is there a way to programmatically change the backround color?
>>
>> Thanks
>>
>> Hilaire
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/These-beautiful-tooltips-tp4932206p4932319.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

--
Using Opera's mail client: http://www.opera.com/mail/

philippeback

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by stepharong

About colors, I am using these ones for some projects: http://clrs.cc/

Phil

On Thu, Feb 2, 2017 at 7:38 PM, stepharong <[hidden email]> wrote:

On Tue, 31 Jan 2017 13:52:54 +0100, Hilaire <[hidden email]> wrote:

I would like to help in both accessibility and implementation detail of
the theme. In the other hand I fell we are in such flux with the future
UI in Pharo. What are the grounds we can stand on regarding UI?

Improve now.
Think later.
Bloc/Brick will not be ready before some versions of Pharo.

Hilaire

Le 31/01/2017 à 11:21, [hidden email] a
écrit :

Well there is no subclass of GLMBrickColorThemer so dark themes get
hardcoded light colors in places for example.

--
Using Opera's mail client: http://www.opera.com/mail/

philippeback

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by stepharong

And there are useful A11Y (Accessibility combos down the page)

http://clrs.cc/a11y/

Phil

On Thu, Feb 2, 2017 at 7:38 PM, stepharong <[hidden email]> wrote:

On Tue, 31 Jan 2017 13:52:54 +0100, Hilaire <[hidden email]> wrote:

I would like to help in both accessibility and implementation detail of
the theme. In the other hand I fell we are in such flux with the future
UI in Pharo. What are the grounds we can stand on regarding UI?

Improve now.
Think later.
Bloc/Brick will not be ready before some versions of Pharo.

Hilaire

Le 31/01/2017 à 11:21, [hidden email] a
écrit :

Well there is no subclass of GLMBrickColorThemer so dark themes get
hardcoded light colors in places for example.

--
Using Opera's mail client: http://www.opera.com/mail/

HilaireFernandes

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by stepharong

A UI quality team review would be needed before each Pharo release, I
mean with a real constraint to postpone release until a good enough
quality is reached!
In that context I can help.

There are many place where tiny efforts could make the UI so much better
for newcomers.

For example when I saw the debugger tooltips, there are just helpless,
their contents are the same as the button label, not acceptable!!!

I can't understand the difference between 'over' and 'through'. I guess
other may think I don't understand the difference because I am an idiot,
but I guess there are a lot of idiots out there, and these are the ones
we want to come and *to stay* with Pharo!

So any wish to *really* improve the UI quality, or just words?

Hilaire

Le 02/02/2017 à 19:38, stepharong a écrit :

> On Tue, 31 Jan 2017 13:52:54 +0100, Hilaire
> <[hidden email]> wrote:
>
>> I would like to help in both accessibility and implementation detail of
>> the theme. In the other hand I fell we are in such flux with the future
>> UI in Pharo. What are the grounds we can stand on regarding UI?
>
> Improve now.
> Think later.
> Bloc/Brick will not be ready before some versions of Pharo.

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

Marcus Denker-4

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

> On 3 Feb 2017, at 09:21, Hilaire <[hidden email]> 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 enough
> quality is reached!
> In that context I can help.
>
> There are many place where tiny efforts could make the UI so much better
> for newcomers.
>
> For example when I saw the debugger tooltips, there are just helpless,
> their contents are the same as the button label, not acceptable!!!
>
> I can't understand the difference between 'over' and 'through'. I guess
> other may think I don't understand the difference because I am an idiot,
> but I guess there are a lot of idiots out there, and these are the ones
> we want to come and *to stay* with Pharo!
>
> So any wish to *really* improve the UI quality, or just words?
>

Yes, words is the problem: it is *so* easy to know what others have to do.
Trivial. *Doing* is hard… maybe you should be in charge of reviewing
all changes for pharo for one month?

Marcus

CyrilFerlicot

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by philippeback

On 03/02/2017 07:55, [hidden email] wrote:
> About colors, I am using these ones for some projects: http://clrs.cc/
>
> Phil
>

For my part I use these colors:

https://www.materialui.co/colors

500 been the default color and the going higher or lower for contrasts.

In fact these colors are implemented in the class MDLColor loadable via
the group "color" en MaterialDesignLite project.

Here are the guidelines associated with these colors:
https://material.io/guidelines/style/color.html#color-color-palette

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

signature.asc (817 bytes) Download Attachment

HilaireFernandes

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by Marcus Denker-4

Yes, my words as yours are cheap, but life not:

- 6:30am, wake up, speedy breakfast, heading to school

- all days: teaching kid, getting grads, metting other teachers, oh
using DrGeo during class, it is cool, it is super stable, hopefully I
kept it on Pharo 3 to avoid undetected incompatibility issues I faced
otherwise. Wants to use Phratch, but the UI quality not good enough yet,
need a few fixing.

- afternoon and late afternoon: teacher work, coding/consulting/training
ICT for IT department

Some fun with Phratch bugs fixing. I want to remove all this UI bugs
hanging around before producing video courses for teachers.
Oh, what these tools are about, there are no tips (not good for teacher
or kids!). Oh using wrong method to activate tooltip, API changes, why
two methods now, I don't understand the logic, okay got the tips to show
up, oh they look like shit (not pro). Time for dinner.

Later on the evening: try to figure out this tooltips why there are so
awfull, wasting time again on that. Why is it so ugly. I will not
release DrGeo looking like that, why is it happening in pharo. Getting
upset. And then so on with other problems

Complaining on the list about the overall Pharo quality. Oh I appear to
be the bad guy, I should take responsibility, ok may be during my bed
time then.

If you read carefully I proposed to help in my previous, so no need to
reply with this trivial "show me the code". If there is a UI quality
team, I want and I can help a bit, but my plates are already mostly
full. But if Pharo thinks quality is good enough then ok, I will shut up.

Hilaire

Le 03/02/2017 à 09:54, denker a écrit :
> Yes, words is the problem: it is *so* easy to know what others have to do.
> Trivial. *Doing* is hard… maybe you should be in charge of reviewing
> all changes for pharo for one month?

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

SergeStinckwich

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

On Fri, Feb 3, 2017 at 12:00 PM, Hilaire <[hidden email]> wrote:
> Yes, my words as yours are cheap, but life not:

Hi Hilaire,

> - 6:30am, wake up, speedy breakfast, heading to school
>
> - all days: teaching kid, getting grads, metting other teachers, oh
> using DrGeo during class, it is cool, it is super stable, hopefully I
> kept it on Pharo 3 to avoid undetected incompatibility issues I faced
> otherwise. Wants to use Phratch, but the UI quality not good enough yet,
> need a few fixing.
>
> - afternoon and late afternoon: teacher work, coding/consulting/training
> ICT for IT department
>
> Some fun with Phratch bugs fixing. I want to remove all this UI bugs
> hanging around before producing video courses for teachers.
> Oh, what these tools are about, there are no tips (not good for teacher
> or kids!). Oh using wrong method to activate tooltip, API changes, why
> two methods now, I don't understand the logic, okay got the tips to show
> up, oh they look like shit (not pro). Time for dinner.
>
> Later on the evening: try to figure out this tooltips why there are so
> awfull, wasting time again on that. Why is it so ugly. I will not
> release DrGeo looking like that, why is it happening in pharo. Getting
> upset. And then so on with other problems
>
> Complaining on the list about the overall Pharo quality. Oh I appear to
> be the bad guy, I should take responsibility, ok may be during my bed
> time then.

What you describe looks very similar to my experience.
I have lectures at the university (15h nowadays), research papers
to wrote, students to supervise on some Pharo projects,
projects based on Pharo to push and sometimes some annoying bugs related to UI.
Spend sometime to try to fix this problems but I have to stop at one
point because this is my main activity ...

I guess we are all suffering from the same experience and the only
solutions maybe is
to add or fix some issues on the bug tracker. But if you try to fix
some bugs, you realize that is not an easy task, etc ...
Like Markus say during his talk last ESUG, even doing a small step is
already great.

> If you read carefully I proposed to help in my previous, so no need to
> reply with this trivial "show me the code". If there is a UI quality
> team, I want and I can help a bit, but my plates are already mostly
> full. But if Pharo thinks quality is good enough then ok, I will shut up.

I prefer people complaining, than people talking endlessly ;-)

I like the idea of a UI quality team and more dedicated teams should
be built maybe on documentation, CI, etc ...
I guess for an UI quality team, the first step is to propose a process
on how to assess the quality of a release.

Regards,
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Marcus Denker-4

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by HilaireFernandes

>
> Complaining on the list about the overall Pharo quality. Oh I appear to
> be the bad guy, I should take responsibility, ok may be during my bed
> time then.
>
> If you read carefully I proposed to help in my previous, so no need to
> reply with this trivial "show me the code". If there is a UI quality
> team, I want and I can help a bit, but my plates are already mostly
> full. But if Pharo thinks quality is good enough then ok, I will shut up.
>

No, what I say is

1) Even the most trivial thing only gets done because someone does it.
(one could think that there is some smallness and obviousness where things
just “do themselves”… I mean, that problem X is so obvious and trivial! Nope.
Someone has to do it. Physically do that instead of something else.

2) Because something is not done does not mean that it was rejected
(or people think that what we have is perfect).

The problem is that there is just nobody whose fault this is… there
is just nobody who did the obvious, because there is just nobody who did
it. No bad intention, no judging. It just needs to be done.

Teams can be nice to make it more fun, to have more drive.

Marcus

Ben Coman

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by Marcus Denker-4

On Fri, Feb 3, 2017 at 4:54 PM, denker <[hidden email]> wrote:
>
>
> > On 3 Feb 2017, at 09:21, Hilaire <[hidden email]> 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 enough
> > quality is reached!

Its always a question of resources and priorities.

For example, is the tooltip text more important than...
17240 Spur - when saving an image, it never shrinks
18638 Image is growing in size (unnecessary instances of UndoRedoRecords)
19606 Switch SSL Plugin Code for macOS to openssl
19645 Enabling search triggers error in the FastTable renderer for Glamour
18654 Setting are not being loaded
18668 Computer UUID does not change when image is moved to another machine

Maybe yes from your perspective, passion and needs.
Maybe you don't feel you have time, expertise or passion to work on
those listed issues yourself.
But others may consider it more important for themselves to work on
the listed issues,
and that is what they work on with their limited time.
But since the Release can't be dragged out forever,
a cut must be made and perhaps the polish of the UI suffers.

Now its often the case that the person who clearly sees the issues,
and is driven to find them, is best placed to solve them. If you are
willing to volunteer some effort there, I think that would be a great
thing. I don't want to drive it, but I would certainly be willing to
give close support to quickly review your slices and collaborate on
anything gnarly.

cheers -ben

>
> > In that context I can help.
> >
> > There are many place where tiny efforts could make the UI so much better
> > for newcomers.
> >
> > For example when I saw the debugger tooltips, there are just helpless,
> > their contents are the same as the button label, not acceptable!!!
> >
> > I can't understand the difference between 'over' and 'through'. I guess
> > other may think I don't understand the difference because I am an idiot,
> > but I guess there are a lot of idiots out there, and these are the ones
> > we want to come and *to stay* with Pharo!
> >
> > So any wish to *really* improve the UI quality, or just words?
> >
>
> Yes, words is the problem: it is *so* easy to know what others have to do.
> Trivial. *Doing* is hard… maybe you should be in charge of reviewing
> all changes for pharo for one month?
>

Tudor Girba-2

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

Hi Hilaire,

Thanks for caring about the UI.

Unfortunately, your message sounded like an angry complaint and this often has the tendency to stifle collaboration. As I am sure this was not your intention, let’s try to take that energy and transform it into something positive that can lead to action.

Concretely: You complained about the text in the tooltips. I understand that you do not have time to fix the code, but here is what you can easily do: propose the concrete pieces of text that would work for you and we can take it from there.

What do you say?

Cheers,
Doru

> On Feb 3, 2017, at 3:38 PM, Ben Coman <[hidden email]> wrote:
>
> On Fri, Feb 3, 2017 at 4:54 PM, denker <[hidden email]> wrote:
>>
>>
>>> On 3 Feb 2017, at 09:21, Hilaire <[hidden email]> 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 enough
>>> quality is reached!
>
> Its always a question of resources and priorities.
>
> For example, is the tooltip text more important than...
> 17240 Spur - when saving an image, it never shrinks
> 18638 Image is growing in size (unnecessary instances of UndoRedoRecords)
> 19606 Switch SSL Plugin Code for macOS to openssl
> 19645 Enabling search triggers error in the FastTable renderer for Glamour
> 18654 Setting are not being loaded
> 18668 Computer UUID does not change when image is moved to another machine
>
> Maybe yes from your perspective, passion and needs.
> Maybe you don't feel you have time, expertise or passion to work on
> those listed issues yourself.
> But others may consider it more important for themselves to work on
> the listed issues,
> and that is what they work on with their limited time.
> But since the Release can't be dragged out forever,
> a cut must be made and perhaps the polish of the UI suffers.
>
> Now its often the case that the person who clearly sees the issues,
> and is driven to find them, is best placed to solve them. If you are
> willing to volunteer some effort there, I think that would be a great
> thing. I don't want to drive it, but I would certainly be willing to
> give close support to quickly review your slices and collaborate on
> anything gnarly.
>
> cheers -ben
>
>>
>>> In that context I can help.
>>>
>>> There are many place where tiny efforts could make the UI so much better
>>> for newcomers.
>>>
>>> For example when I saw the debugger tooltips, there are just helpless,
>>> their contents are the same as the button label, not acceptable!!!
>>>
>>> I can't understand the difference between 'over' and 'through'. I guess
>>> other may think I don't understand the difference because I am an idiot,
>>> but I guess there are a lot of idiots out there, and these are the ones
>>> we want to come and *to stay* with Pharo!
>>>
>>> So any wish to *really* improve the UI quality, or just words?
>>>
>>
>> Yes, words is the problem: it is *so* easy to know what others have to do.
>> Trivial. *Doing* is hard… maybe you should be in charge of reviewing
>> all changes for pharo for one month?
>>
>

--
www.tudorgirba.com
www.feenk.com

"No matter how many recipes we know, we still value a chef."

HilaireFernandes

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by SergeStinckwich

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 to fix it, if no consensus, the team
could ask to the whole community @devel.

- should the team discuss on a dedicated mailing list? May be to avoid
too much noise on @devel...

- the team will look mostly at non blocking bugs, ones in the sphere of
"First impression count", so it can be clarity of the UI (message, tips,
color, etc) or some annoying bugs regarding usability

- the team should be able to fix itself most of these issues.

How does it sound?

Hilaire

Le 03/02/2017 à 12:25, Serge Stinckwich a écrit :
> I like the idea of a UI quality team and more dedicated teams should
> be built maybe on documentation, CI, etc ...
> I guess for an UI quality team, the first step is to propose a process
> on how to assess the quality of a release.

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

HilaireFernandes

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by Tudor Girba-2

Le 03/02/2017 à 17:12, Tudor Girba a écrit :
> Unfortunately, your message sounded like an angry complaint and this often has the tendency to stifle collaboration. As I am sure this was not your intention, let’s try to take that energy and transform it into something positive that can lead to action.
>
> Concretely: You complained about the text in the tooltips. I understand that you do not have time to fix the code, but here is what you can easily do: propose the concrete pieces of text that would work for you and we can take it from there.
>
> What do you say?

I say we have an important misunderstanding, it would have been better
you re-read my previous post than trying to interpret my intention.

The only way to respond to you is to ask you to explain me, if you know,
what are the differences between 'over' and 'through' buttons in the
debugger.
Then I may be able to word tooltips for these two buttons, but you will
have already word it in your explanation I guess.
Ok we are just making round circle here ;)

I guess a UI quality team could see that sort of tiny itches and ask to
the community, then fix it.

Hilaire

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

John Pfersich

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

The over button means step over the message highlighted, the through button means step into the message highlighted and single step through the statements in the message.

Sent from my iPhone

> On Feb 3, 2017, at 13:29, Hilaire <[hidden email]> wrote:
>
>
>
>> Le 03/02/2017 à 17:12, Tudor Girba a écrit :
>> Unfortunately, your message sounded like an angry complaint and this often has the tendency to stifle collaboration. As I am sure this was not your intention, let’s try to take that energy and transform it into something positive that can lead to action.
>>
>> Concretely: You complained about the text in the tooltips. I understand that you do not have time to fix the code, but here is what you can easily do: propose the concrete pieces of text that would work for you and we can take it from there.
>>
>> What do you say?
>
> I say we have an important misunderstanding, it would have been better
> you re-read my previous post than trying to interpret my intention.
>
> The only way to respond to you is to ask you to explain me, if you know,
> what are the differences between 'over' and 'through' buttons in the
> debugger.
> Then I may be able to word tooltips for these two buttons, but you will
> have already word it in your explanation I guess.
> Ok we are just making round circle here ;)
>
> I guess a UI quality team could see that sort of tiny itches and ask to
> the community, then fix it.
>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
>
>

Tudor Girba-2

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by HilaireFernandes

Hi Hilaire,

I did not reinterpret your intention. I gave you feedback. You can take it into account or not.

But, I actually do not understand where the original problem comes from. I probably miss something and that is why please allow me to describe what I see and then you can indicate more concretely where the issue comes from.

This whole discussion was spawned on the premise that things are degrading going forward from Pharo 3.0 to 6.0, and the debugger actions was one issue. Here is a screenshot of a Pharo 3 debugger:

Now, let’s look at the debugger from 6.0.

The main actions that exist in Pharo 6 also exist in Pharo 3 including Over and Through. These actions exist also in Pharo 1. Furthermore, in the Pharo 3 debugger (which is also available in Pharo 6), there are no tooltips. The main goal of the tooltip from GTDebugger is to offer the shortcuts associated with the buttons. There were shortcuts associated to the debugger actions in Pharo 3, but when looking at the buttons this information was not offered directly.

Could you point me to where the interface has degraded and how the tooltips decrease value?

Cheers,

Doru

On Feb 3, 2017, at 10:29 PM, Hilaire <[hidden email]> wrote:

Le 03/02/2017 à 17:12, Tudor Girba a écrit :
Unfortunately, your message sounded like an angry complaint and this often has the tendency to stifle collaboration. As I am sure this was not your intention, let’s try to take that energy and transform it into something positive that can lead to action.

Concretely: You complained about the text in the tooltips. I understand that you do not have time to fix the code, but here is what you can easily do: propose the concrete pieces of text that would work for you and we can take it from there.

What do you say?

I say we have an important misunderstanding, it would have been better
you re-read my previous post than trying to interpret my intention.

The only way to respond to you is to ask you to explain me, if you know,
what are the differences between 'over' and 'through' buttons in the
debugger.
Then I may be able to word tooltips for these two buttons, but you will
have already word it in your explanation I guess.
Ok we are just making round circle here ;)

I guess a UI quality team could see that sort of tiny itches and ask to
the community, then fix it.

Hilaire

--
Dr. Geo
http://drgeo.eu

--
www.tudorgirba.com
www.feenk.com

"Every now and then stop and ask yourself if the war you're fighting is the right one."

Ben Coman

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by John Pfersich

> > On Feb 3, 2017, at 13:29, Hilaire <[hidden email]> wrote:
> >
> > what are the differences between 'over' and 'through' buttons in the
> > debugger.

On Sat, Feb 4, 2017 at 8:09 AM, John Pfersich <[hidden email]> wrote:
>
> The over button means step over the message highlighted, the through button means step into the message highlighted and single step through the statements in the message.

I'm not sure if I am correct, but more than stepping over/through messages,
I normally think about it as how blocks are handled.

Over is step over a block.
Through is step through a block.

Try debugging this, purely with Over and then purely with Through...
self inform: '1'.
#(2 3 4) do: [:n| self inform: n printString ].
self inform: '5'.

However its not completely about blocks, since Over versus Through
has little difference on debugging this...
self inform: '1'.
2 to: 4 do: [:n| self inform: n printString ].
self inform: '5'.

So it seems it affects a certain subset of messages,
which is at least the usual enumeration messages...
#do: #collect: #select: #detect:
but I don't know what the comprehensive list is.

So maybe that it another way to define the difference
Over steps over enumeration of a block
Through step through enumeration of a block

or...
Over steps of iteration of a block
Through step through iteration of a block

I'm not sure which is more correct.
cheers -ben

Sven Van Caekenberghe-2

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

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 selectedContext, and regain control
after the invoked method returns."

DebugSession>>#stepThrough: aContext
"Send messages until you return to selectedContext.
Used to step into a block in the method."

I must admit that Over vs Through confuses the hell out of me, but playing with it, this is one feature I should have learned to use much earlier!

My interpretation now is: Through is just like Over but it will stop again whenever the context becomes the current one while doing the Over.

And you are right: it is very useful when dealing with iteration blocks, since each time inside one of the blocks used as arguments, the debugger will stop, and you can trace the execution.

Try Debug It on the following expression:

#(1 2 3 4 5) sum.

Start by stepping Into the #sum, next step Over the first assignment (sample := self anyOne) and then use Through for the #inject:into: iteration and observe how you get control back each time through (aha) the block [:accum :each | accum + each].

Pretty cool actually.

> On 4 Feb 2017, at 17:10, Ben Coman <[hidden email]> wrote:
>
>>> On Feb 3, 2017, at 13:29, Hilaire <[hidden email]> wrote:
>>>
>>> what are the differences between 'over' and 'through' buttons in the
>>> debugger.
>
> On Sat, Feb 4, 2017 at 8:09 AM, John Pfersich <[hidden email]> wrote:
>>
>> The over button means step over the message highlighted, the through button means step into the message highlighted and single step through the statements in the message.
>
> I'm not sure if I am correct, but more than stepping over/through messages,
> I normally think about it as how blocks are handled.
>
> Over is step over a block.
> Through is step through a block.
>
> Try debugging this, purely with Over and then purely with Through...
> self inform: '1'.
> #(2 3 4) do: [:n| self inform: n printString ].
> self inform: '5'.
>
> However its not completely about blocks, since Over versus Through
> has little difference on debugging this...
> self inform: '1'.
> 2 to: 4 do: [:n| self inform: n printString ].
> self inform: '5'.
>
> So it seems it affects a certain subset of messages,
> which is at least the usual enumeration messages...
> #do: #collect: #select: #detect:
> but I don't know what the comprehensive list is.
>
> So maybe that it another way to define the difference
> Over steps over enumeration of a block
> Through step through enumeration of a block
>
> or...
> Over steps of iteration of a block
> Through step through iteration of a block
>
> I'm not sure which is more correct.
> cheers -ben
>

stepharong

Re: WCAG color contrast rules - was: Re: These beautiful tooltips

In reply to this post by HilaireFernandes

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 <[hidden email]> 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 enough
> quality is reached!
> In that context I can help.
>
> There are many place where tiny efforts could make the UI so much better
> for newcomers.
>
> For example when I saw the debugger tooltips, there are just helpless,
> their contents are the same as the button label, not acceptable!!!
>
> I can't understand the difference between 'over' and 'through'. I guess
> other may think I don't understand the difference because I am an idiot,
> but I guess there are a lot of idiots out there, and these are the ones
> we want to come and *to stay* with Pharo!
>
> So any wish to *really* improve the UI quality, or just words?
>
> Hilaire
>
>
> Le 02/02/2017 à 19:38, stepharong a écrit :
>> On Tue, 31 Jan 2017 13:52:54 +0100, Hilaire
>> <[hidden email]> wrote:
>>
>>> I would like to help in both accessibility and implementation detail of
>>> the theme. In the other hand I fell we are in such flux with the future
>>> UI in Pharo. What are the grounds we can stand on regarding UI?
>>
>> Improve now.
>> Think later.
>> Bloc/Brick will not be ready before some versions of Pharo.
>

--
Using Opera's mail client: http://www.opera.com/mail/

123