On Sat, 10 Mar 2018 06:58:42 -0800 (PST)
Thomas Passin <[email protected]> wrote:

> I just went through a really painful experience when I adopted a dark 
> theme.  

I think this is good feedback.  Although I wonder if you're talking
about one of the old themes or one of the new ones, for which I assume
the default syntax colors are visible - not quite sure how far out the
door the new themes are to be honest.

Regardless, I'd point out that we have a mechanism that's *supposed* to
help with the "find the lever that adjusts X" problem.  The 

  Settings -> Edit Settings

menu tree is supposed to do exactly that.  Right now I would guess it's
not tuned for the new themes, and was never fully fleshed out for the
old themes, but I think it can help with these issues.  We should also
make invoking a color picker on a @color node, and a font picker on a
@font node, easier - there are some button scripts or something
somewhere that do that, but nothing the leaps out and offers to be
helpful.

So I guess I think it will be worth seeing how helpful the Settings ->
Edit Settings menu can be with the new themes.  I think it will be
possible to tune it to the specific settings used by a specific theme,
although of course the more themes share common settings names for
things, like @color body-text-foreground and so on, the less tuning
will be required.

To be clear, I don't think Settings -> Edit Settings can be fairly
evaluated right now, but once the dust settles on the new themes, let's
see what it can do.

Cheers -Terry

> The existing ones that are in leoSettings were unusable,
> because too many of the syntax colors were unreadable against the
> dark background. I've gotten it working more or less to my
> satisfaction (there's one color that's still too dark, but it's too
> painful for me to find and change).
> 
> I spend many hours trying to figure it out and track down the colors
> and what they affected.  For every change, I had to restart Leo
> because reloading the styles and settings didn't seem to do a
> complete job.
> 
> My main problems were these:
> 
> 1. I couldn't always tell what color on the display corresponded to
> which color name.  For example, what syntax color is used for
> triple-quoted text?  And is there a difference between triple quoted
> with double or single quotation marks?
> 
> 2. I had trouble threading through from @color-name to the color 
> specification, because they wren't linked in some easy-to-find way.
> 
> 3.  I found it hard to know which settings affected the display pane
> colors and which affected the syntax coloring colors.
> 
> It's possible that I might get very familiar with these things and
> get more efficient at it.  But most of us will only do this once or
> twice ever, so even if we get good at it, we'll forget how before we
> do it again.  I think this might be something that people like Ed
> don't appreciate enough:  most of us aren't familiar with the details
> of this machinery, and it doesn't seem to be explained well anywhere
> findable when we want it.
> 
> Contrast this with my experience in going through the same process - 
> tweaking a dark theme - with PyScripter.  It was still painful, but
> there is a good color picker, a dialog with symbolic color roles and
> names, and the colors take effect right away.  There is still have
> some ambiguity between a theme and specific syntax colors, but it was
> way easier and far less painful than with Leo.
> 
> On Tuesday, March 6, 2018 at 9:27:16 AM UTC-5, Terry Brown wrote:
> >
> > On Tue, 6 Mar 2018 07:58:33 -0600 
> > "Edward K. Ream" <[email protected] <javascript:>> wrote: 
> >  
> > > ​status_bg_color.  I don't remember exactly.  But the name,
> > > whatever it is, tells us exactly *nothing* about what the actual
> > > color is, and that, and only that, is what is important in the
> > > css.   
> >
> > I think what matters is the color's role, not the actual color
> > itself. Themes are usually built from a relatively small palette of
> > carefully picked colors that play well with each other.  Each color
> > has a specific role withing that palette.  solarized makes the set
> > seem bigger than usual because it's really two palettes, one dark
> > and one light, combined. 
> >
> > It's better to define the css in terms of semantic names like
> > error_fg and info_fg than to have to remember you're using
> > solarized-red (or was it solarized-magenta) for errors and
> > solarized-yellow (or was it solarized-green) for info. items. 
> >
> >
> >  
> 

-- 
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 [email protected].
To post to this group, send email to [email protected].
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