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