Actually my point was the creation of themes, thats what a theme manager does. No its not easy, its not easy to have to go to the System Browser find Dark Theme class, try to guess which method is responsible for the background color and then go the usual Pharo rabbit hole of senders and implementors so that I dont brake anything. It kills my inner child. Slowly. Painfully.��

Plus if it was that easy we would be overwhelmed by Themes right now . A year has passed since the Dark Theme appeared and all I hear is crickets and frogs. I have not seen anyone announce a theme as third party either. Also my experience with it for an hour I spent on it rates "extremely hard".��

About moving away from static values and replace them with references I agree 100% with you but you also mention the very important that its something we have to agree on and I dont want to go through the pain of asking permission each time I want to do something like that. My goals is not to improve Theme support , its more to leverage the power of Dark Theme and make it easy for people, I mean really easy, to create their own themes without having to write a line code.��

Because writing code to create a theme , makes no sense to me whatsoever.��

Nothing spectacular just a simple, easy to use, fun theme manager. I just started the thread so people can share their wisdom on the subject, maybe even make request that I may find cool enough to implement.��

On Mon, Nov 10, 2014 at 5:08 PM, Stephan Eggermont <stephan@stack.nl> wrote:

The point is not the creation of a theme. That is easy. And editing is too.
The problem is that you need to check the whole system and get rid of
all the constants and replace them by references to symbolic values in
the application theme. There is the value.

For example
CheckBoxExample>>defaultSpec

�� ^ { #ContainerModel.
�� #add:.�� { self topSpec. #layout:.�� #(#SpecLayoutFrame
�� bottomFraction: 0
�� bottomOffset: 20) }.
�� #add:.�� {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) }
�� }

the values 20 and 22 need to be replaced. They are dependent on at least the font size.

There are lots of these, e.g.
CredentialEditor class >>defaultSpec
�� <sepc: #default>

�� ^ SpecLayout composed
�� newColumn: [ :col |
�� col
�� newRow: [ :r | r add: #usernameLabel width: 80; add: #username ] height: self inputTextHeight;
�� newRow: [ :r | r add: #passwordLabel width: 80; add: #password ] height: self inputTextHeight + 4;
�� newRow: [ :r | r add: #showPasswordWidget width: 120; newColumn: [ :c | ] ] height: self inputTextHeight + 4;
�� newRow: [ :r | ]
�� ];
�� yourself

That <sepc: #default> looks like a typo btw.

These values are often composites, something like textSize+2*textLineVerticalSeparation.
Coming up with good symbolic names is not trivial either.

��Stephan