Color themes

[Ezibenroc]

Related to #55.
A good beamer theme should provide several color themes, to fit the needs of its users.

This PR allow one to easily write a new color theme, thanks to code factorization: just set the four colors mDarkTeal, mDark, mMedium and mLight.

As an example, two color themes are provided: metropolis (the original theme), and blue.
Fill free to modify the colors I set for the blue theme, as my tastes are maybe not so good.

It would be great to provide other color themes, based on this idea. At least one theme per main color.

[benjamin-weiss]

I'm sorry, but I do not get the point of this pull request. You already can easily create a custom color theme, where you just have to redefine the four used colors. Or you can even use the color themes provided by the beamer class itself. So why do you think it is useful to divide the color theme into more different files?

On the other hand I think it is totally sufficient to provide only one color theme, as the requirements regarding color are probably very individual. But that's discussible. Maybe it does make sense to provide some more carefully chosen color themes, as the color themes provided from beamer itself look imho mostly awful.

[matze]

While I like the idea of easy color customization I think it should be done in a more semantic way (i.e. darkTeal doesn't make much sense). I also have to agree with @benjamin-weiss that the "common" color theme is unnecessary.

[Ezibenroc]

I think it does make sense to provide several color themes. Beamer color themes look awful, and it may be difficult for someone to find good colors.
For instance, I spent a significant time to find the colors for the blue theme, and I am not even sure that it looks good. Providing color themes on this repository can help to discuss about the choice of the colors.

The "common" color theme is for code factorization. Without it, we would have to copy-paste its whole content in each color theme (and thus modify every copy each time you want to do a global modification of the color themes).
I do not understand why it would be better to have several copies of the same code. Or maybe you have an alternative without code copy?

About darkTeal, I thought that "teal" meant something else. Of course it does not make sense to keep darkTeal, sorry for that. Do you have any proposition?

[benjamin-weiss]

@matze Yes, to think about more universal names makes probably sense. Something like mPrimaryDark and mSecondaryDark`? Or are there any better ideas?

@Ezibenroc The thing is, you already do not need to copy-paste the whole color definition. So for example you can load the theme, redefine the colors and it just works.

\usetheme{m}
\definecolor{mDarkTeal}{HTML}{001C58}
\definecolor{mDark}{HTML}{002678}
\definecolor{mMedium}{HTML}{006E6A}
\definecolor{mLight}{HTML}{00B6AF}

Or you can obviously outsource the color redefinitions into a separate color theme file and just load that.

\usetheme{m}
\usecolortheme{blue}

Stil there is no need to redefine everything.

[Ezibenroc]

Ok, I did not think it could work like this. I applied your suggestion for the code and the color names.

[benjamin-weiss]

Yeah, sometimes TeX is easier than you think. ;)

[ChipmunkMath]

I think having some alternative color themes to the default one would be nice. While I like the current color theme, my main attraction to using metropolis was its minimalist design and use of a beautiful font. Being able to easily swap to a different color scheme would be a handy feature.

I see there being three separate issues for integrating that:

1. More semantic naming of what the different colors do. I think mPrimaryDark and mSecondaryDark are good (but probably more descriptive as mDarkPrimary, etc.), but that still leaves us with mLight and mMedium. I think mLight could become mAlertColor (that's all it does, right?), but I'm not really sure where mMedium shows up. In any case, having sensible color names makes it a lot easier for later color theme changes to be made.
2. Clear documentation on this in the ReadMe file. That way, if someone wants to make changes to their color scheme, they don't have to look through the style files. They'll know right from the bat what they need to redefine and that they can just place a block of color redefinitions after they call the theme (like @benjamin-weiss did above).
3. Predefined color themes. Like both @Ezibenroc and @benjamin-weiss have indicated, choosing a good looking color scheme can be tough. Having some carefully picked color schemes that can just be used "out of the box" would probably be the best thing for most users. Note that including this feature should also necessitate some sort of documentation that gives a listing of all the themes with images showing how they look.

Finally, if this feature moves forward and optional color themes are added, might I suggest extending to a naming system of fictional cities? For example, if we want to continue with comic books, gotham, megacityone, neotokyo, etc. Or if it's preferred to break away from comics, avalon, camelot, eldorado, etc.

[benjamin-weiss]

Another remark. In the file beamercolorthemeblue.sty you write

\ProvidesPackage{beamercolorthememetropolis}

This should either be

\ProvidesPackage{beamercolorthemeblue}

or be removed completely. I personally think it is not really needed. There is no harm to load it twice, respectively it can even make sense to load it multiple times. If – for example – you want to change the color theme for one specific section and then revert that change for the next section, then it would be necessary to load the theme twice. The same is true for the beamercolorthememetropolis.sty file. But there we have to be careful with the theme options. I do not know by heart if it there is any part which would cause a problem when loaded twice.

[matze]

Clear documentation on this in the ReadMe file.

I think an image with a sample frame and arrows pointing to the different colored elements could be an easy cheat sheet for the lazy ones.

Note that including this feature should also necessitate some sort of documentation that gives a listing of all the themes with images showing how they look.

I just checked and it's easily possible to redefine colors between frames, so we could either supply a themes.pdf or update the demo.pdf to showcase the different color themes.

Finally, if this feature moves forward and optional color themes are added, might I suggest extending to a naming system of fictional cities?

That sounds like a great idea!

Now, the question: is this going to be fleshed out in this PR or a separate one?

[benjamin-weiss]

I think mLight could become mAlertColor (that's all it does, right?), but I'm not really sure where mMedium shows up.

Yes, mLight is only used as alert. So mAlertColor or maybe just mAlert makes sense. Just went through the code again. And as far as I can see mMedium is really not used anywhere. I would propose we use it as the Example color (and hence rename it to mExample), which is by the way only overwritten if the blockbg option is chosen. Otherwise it is still the standard green.

EDIT: Forgot to check the progress bar. mLight is also used as the highlight color of the progress bar, but while referring to the alert color alerted text.fg, so it is maybe nevertheless not a bad idea to use mAlert as a name?

Clear documentation on this in the ReadMe file.

I think an image with a sample frame and arrows pointing to the different colored elements could be an easy cheat sheet for the lazy ones.

Very good idea.

... might I suggest extending to a naming system of fictional cities?

Although I like the idea using fictional cities as a naming system, it has its drawbacks, as you have no idea how the color theme looks like.

[rchurchley]

I would recommend against using semantic colour names, because those semantics are already encapsulated by \setbeamercolor. The current codebase has

\definecolor{mLightBrown}{HTML}{EB811B}
\setbeamercolor{alerted text}{fg=mLightBrown}

which a user can override with

\setbeamercolor{alerted text}{fg=blue}

I think this is clearer than renaming each colour to something unrelated to its appearance and asking users to redefine the colour.

If the concern is about duplication of code, it may be possible to set all (or most) of the colours in terms of palette primary, palette secondary, palette tertiary, and palette quaternary. If so, users would only have to invoke four \setbeamercolors to change their theme.

[ChipmunkMath]

@rchurchley: Good point. As long as there's some sort of semantic hook for people to define, that should be pretty easy to use. What happens for something like this, though?
\setbeamercolor{section title}{parent=palette primary}
In that case, we have a previous definition of \setbeamercolor{palette primary}{fg=mPrimaryDark, bg=black!2}. I don't know enough about TeX or Beamer to answer this, but what happens if a user sets only a single color for {section title}? Will that cause issues? If so, that seems like the downside to working things in this method.

@benjamin-weiss: And as far as I can see mMedium is really not used anywhere. I would propose we use it as the Example color (and hence rename it to mExample), which is by the way only overwritten if the blockbg option is chosen. Otherwise it is still the standard green.

I currently use blockbg and would like to keep the standard green. If I understand you correctly, so long as I keep using blockbg, it would continue to overwrite the example color and keep it as green, right? I think that's what you said, but it would cause trouble for me if otherwise, so please let me know if I misunderstood.

Although I like the idea using fictional cities as a naming system, it has its drawbacks, as you have no idea how the color theme looks like.

While that's true, I don't think a title of darkred or similar would be enough information to choose a color scheme. Fully describing a color scheme in a title would be too long, so we'll need some sort of color theme showcase regardless. Since people will decide their choices off of that rather than the name, having a descriptive title isn't terribly important. I agree, using fictional city names is just a bit of cute fluff, but I think it's a bit of fun that can be afforded.

[benjamin-weiss]

@rchurchley I understand your reasoning. But the two approaches do not exclude each other. So maybe we should start with redefining everything using the palette primary, palette secondary ... beamer colors and provide on top of that an easier alternative way to redefine the colors via \definecolor{∙} and semantic color names?

@ChipmunkMath Ok I'm sorry. I have not tested the example block environment and just looked at the code. There I have seen, that there are some redefinitions of the color regarding the example block and I assumed, that the block title text color is redefined – which it isn't. But imho it should be. The mDarkTeal and the standard green for the examples are a bad match. @matze Was this intended or did you forget to redefine the standard green example color?

Regrading the color theme names: Ok lets have a bit of fun. Why not. ;) But then we can maybe think about providing color theme sample frames inside the README file to make it easy for the user to chose a color theme.

[benjamin-weiss]

Some further thoughts: I just played around a little bit trying to make all the code dependent on the four palette beamer colors. In my opinion this would produce too much awful to read code like our definition of the blockbg title

\setbeamercolor{block title alerted}{use={palette primary,alerted text},parent=palette primary,fg=alerted text.fg,bg=palette primary.bg!80!fg}

Strictly using semantic color names (and a little bit of cleaning) the code would look like this

\setbeamercolor{block title alerted}{fg=mAlerted, bg=black!21}

Much cleaner and easy to understand for everybody.

I would recommend against using semantic colour names, because those semantics are already encapsulated by \setbeamercolor.

A beamer color always consists of a foreground and a background. Hence in my opinion the \setbeamercolor covers an other level of the semantic. I think for our purpose the semantic color names make sense and contrary to what I wrote before, I don't think anymore we should make all the code dependent on the four palette beamer colors.

[Ezibenroc]

@benjamin-weiss I applied your remark about the \ProvidePackage command in color themes.

Replacing mLight by something else is a good idea, since this color could not be a light color anymore in some other color themes.
Do you have any idea for the name we should give to the other colors? For the same reason, we should not keep mPrimaryDark, mSecondaryDark and mMedium.
mMedium and mSecondaryDark do not seem to be used, so I don't know how we should name them. By the way, is there some good reason to keep them?
mPrimaryDark is mostly used as a background for frame title and plain frames and as a forground for the other titles, captions and enumerations. We can consider that this the main color of the theme. Maybe we could name it mMain?

[rchurchley]

@benjamin-weiss : It's possible to write much more readable and flexible code than the current blockbg definition:

\setbeamercolor{block title alerted}{%
    use={block title, alerted text}, 
    bg=block title.bg,
    fg=alerted text.fg
}

In response to

A beamer color always consists of a foreground and a background. Hence in my opinion the \setbeamercolor covers an other level of the semantic.

A beamer colour can have a foreground and a background, but doesn't have to have both (see the beamer manual at page 27). Thus the following is possible:

\setbeamercolor{alerted text}{fg=mLightBrown}
\setbeamercolor{frametitle}{fg=white, bg=mDarkTeal}

and \alert{...} will work equally well against any background.

I still prefer using descriptive names with \definecolor and relying on \setbeamercolor for the semantic names. After doing a bit of research into beamercolorthemedefault.sty, though, I'll modify my proposal — I think we should drop the four palettes and define all the styles we need in terms of the beamer colours normal text, alerted text, structure, and block title, which is more in line with what the built-in beamer styles do.

This is all a bit abstract in theory, so I've implemented my suggestion as #66.

[Ezibenroc]

I like the proposition of @rchurchley: it allows to easily change the background. This is not possible in this PR if we only modify the four top colors.

[benjamin-weiss]

A beamer colour can have a foreground and a background, but doesn't have to have both.

Ok, you are right. There seemed to be some misunderstanding on my side.

It's possible to write much more readable and flexible code than the current blockbg definition.

That is more readable. Yet still I think beamer colors are somewhat annoying complicated.

I think we should drop the four palettes and define all the styles we need in terms of the beamer colours normal text, alerted text, structure, and block title, which is more in line with what the built-in beamer styles do.

Probably that was the original idea to define the color themes. Nevertheless even some of the build in color themes rely more on \definecolor{∙}. But as @matze and @Ezibenroc seem to be on board with your proposal I will drop my arguing for semantic color names.

So we dismiss this PR and continue discussion on @rchurchley s PR #66?

[matze]

So we dismiss this PR and continue discussion on @rchurchley s PR #66?

Yep.