On 21/04/17 15:22, Dimitris Chloupis wrote:
its ironic you say this Stephan
and the irony is that you claim that Dark Theme is inappropriate because
Pharo uses so many hard coded colours when it was Esteban's effort to
have a dark theme that decreased the amount of hard coded methods and
modified them to support themes. The very reason you use that Dark
Theme should not be used as default is the very reason to use it because
it will forces us to detect those methods and convert them to support
our Theme classes. This will not only improve the Dark Themes but ANY
future theme.
No. That is just an indicator that we are far from finished, and that is
one good reason not to switch to it close to release. The other reasons are:
- it breaks our own feature freeze rule;
- giving us not enough time to test;
- the number of hard-coded colors suggests that our practical
(non-automated) test coverage is low and the actual users of dark theme
have usage patterns that miss parts of the system;
- it focuses attention on a part of the system that should be irrelevant
so close to release;
- it forces projects that depend on pharo to make changes now;
- making it more difficult for them to release close after pharo releases;
- and thus makes pharo release management look amateurish;
- it is a bad default for the majority of users;
- who will mostly not do any testing but only switch to light theme as
fast as possible, especially when confronted with a decision made like this;
- and is thus bad marketing;
- it is taking a lot of time from the people who should be doing more
productive things.
Stephan
