Terry is focused on flexibility. That's a good thing. I am focused on 
simple css. That's also a good thing.

This post summarizes the points on which we agree, and issues an edict 
about what I am willing to do.

*Useful settings*

Terry and I agree that *some* settings should appear in the css.  Imo, all 
the *agreed settings* have one or more of the following properties.

1. They are settings that users will want to change first.  Like font size 
and font family.

2. They are settings that are largely independent on themes.  Users may 
want different fonts for different themes, but themes should "just work" 
(to the first approximation) regardless of font size or family.

3. They are settings that are easily understood. Seeing this in the css for 
the body pane will cause absolutely no confusion:

QTextEdit {
  font-family: @font-family-body;
  font-size: @font-size-body;
}

4. They are settings that are necessary for compatibility with the theme:

- The new @color log_red/blue/etc_color settings.
- The existing syntax-coloring settings.

To this list I would add the following property.  I'm not sure Terry would 
agree:

5. They are settings that do not conflict with the theme's primary purpose. 
In particular, they do not alter the theme's basic colors.

I have always approved of *partially *parameterized css. Points 1 through 5 
above describe the settings I am willing to incorporate into css.

*An edict*

My aversion to *fully *parameterized css won't change. I can criticize 
fully parameterized css harshly because I was its first champion. It was a 
big mistake on my part. I am *not *going back down that road.

I shall not approve using css settings that:

A. can not easily be understood or explained.
B. modify the fundamental colors of a theme.

Treat this as an edict if you like. I am doing *all* the work on this 
project. I'm refuse to torture myself.

Naturally, anyone is free to ignore my edict by developing their own 
stylesheets. That's not my problem ;-) Just don't expect me to put it into 
leoSettings.leo.  Which reminds me: leoSettings.leo contains old, buggy, 
outdated and overly-complex themes.  Imo they should be replaced by cleaner 
themes.  This should not discomfort existing users, who will continue to 
use their existing themes.

*Summary*

The themes I am developing will be partially parameterized.

Anyone is free to develop other themes, but I will not add horror shows to 
leoSettings.leo.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to