E/EFL Flat Theme
A sample screenshot of the flat theme
What is this?
There has been work going on for a while on this in some spare time here and there. Above is a screenshot sample of what it looks like. It's called a "Flat" theme because it is mostly flat made out of rectangles. Some elements get shadows still. Windows, menus, The edges of a scroller region to indicate there is a boundary there to scroll past, and frames. Not everything has been done yet. Just many "very visible" elements.
Why do some things still have shadows in what is meant to be a "flat" theme? Because it just doesn't visually work well without them. They help indicate a boundary where otherwise no boundary at all would make things hard to distinguish. The idea is to not use shadows too much. Only where visually needed.
Not everything is final either. Like any artwork, you have to put it together and adjust as you go to make things "visually work together", but consider what is there as a design direction and overall look and feel. For example the buttons in the above are probably not final, but are awaiting the rest of the theme to come together.
Why do this?
This would make EFL look more "modern" and yet still have a unique look and feel of its own. While documents like the material design one are not bad for inspiration, it would probably be bad to lose uniqueness and just blindly follow it. But at the same time making EFL more "flat" would be a good thing and make a lot of people very happy. It also come with the bonus of making the theme far easier to "re-color". In addition it's more "programmer-friendly" for design.
So redoing the entire E/EFL theme is a huge undertaking. I have re-started a flat theme twice before. The First time was as a stand-alone theme tree, but it went out of sync with changes and additions to the default theme so quickly that it soon had to be abandoned. I switched to modifying the default theme in-place with a separate git clone that I could keep in parallel to the regular EFL tree, but this soon accrued so many conflicts (because it wasn't regularly rebased) that it had to be tossed again. The third time I did it as a branch and actually rebased regularly. This worked. So my advice is to do the following:
git clone -b feature/themes/flat ssh://email@example.com/core/efl.git efl-flat cd efl-flat git branch --track master origin/master
That will get you a separate efl-flat tree with the flat theme branch that has remotes set up correctly to rebase from remote branch and master. You don't really want to build efl from this tree in addition to the normal master branch, because that would be a waste. As a temporary solution, just compile and install the theme by hand. I have a script that would work by placing it in the toplevel efl-flat directory. copy and paste the below for example into bt.sh then edit as needed (change the P variable to your install prefix if it is not /usr/local), then chmod u+x ./bt.sh.
#!/bin/sh -e P=/usr/local echo "........ Build EFL Theme" cd ./data/elementary/themes/ edje_cc -id ./img -id ./fdo -fd ./fnt -sd ./snd \ -l ../../../COPYING -a ../../../AUTHORS \ -fastcomp default.edc echo "... Installing" sudo install default.edj $P/share/elementary/themes/default.edj
From now on, if yoou make any edits to this theme, just run:
in the toplevel. Do this after you do any make install on your normal master branch efl tree too.
What needs doing?
You should find out pretty quickly. If you run enlightenment and elementary_test or any efl apps. You will see elements that are still "the old default" theme. They will stand out like a sore thumb. Just browse through the widgets in elementary_test and see. Go through enlightenment and it's menus, dialogs, file manager and gadgets. It's not at the stage where "things to do" are hidden or hard to find. A short list of things needing doing:
- Icons (really need a full FDO Icon theme - some are done and look good, some not - have a look at Flat Remix: https://github.com/daniruiz/flat-remix)
- Elm Genlist (look at simple list for inspiration)
- Elm Gengrid
- Elm Menus
- Elm Focus display box
- Elm Mouse cursors beyond default and some resize cursors
- Elm Map
- Elm Photo
- Elm Video
- Elm Entry Emoji items
- Elm Naviframe
- Elm Toolbar (partly done)
- Elm Calendar
- Elm Segmentcontrol
- Elm Inwin
- Elm Popup
- Elm Index
- Elm Combobox
- Elm Tooltips
- Elm Entry magnifier
- Elm Actionslider
- Elm Day Selector
- Elm Disk Selector
- Elm Flip Selector
- Elm Clock
- Elm Panel
- Elm Multibutton Entry
- Elm Slideshow
- Elm Thumb
- Elm Datetime
- Elm Spinner
- Elm Panes
- Elm Progress (look at Ibar busy animation for busy inspiration)
- Elm Code (probably just needs to be color synced)
- Elm Slider
- E Bryce
- E New gadgets
- Efl Widgets
- Lots of these - list them later
- E legacy widgets (a wide range)
- Toolbar (seems to have a bug)
- Dialog base
- Button (legacy not done)
- Edge Bindings
- Randr (old dialog)
- E old gadgets like Music Controller for example (partly done)
- Gadman move/resize controls
- Everything Launcher
- Music Control
- Pager Plain/Pager16
- E icons/efm (efm, settings, menus etc.)
- E - Everything popup/dialog
- E - Winlist (alt+tab popup)
- E - Wallpaper (wallpaper2?)
- E - Remove old Illume as it has been dropped from E many years ago
- Color classes (need to actually come up with a proper naming scheme with a hierarchy)
- Text classes (same naming scheme as color classes needed)
- Size classes (same naming scheme as color and text classes)
- Cleaning/refactoring of edc files to be simple and re-use
- Documentation on swallows, signals, messages etc. needed for elements
- Ensure theme scales well (test it on range of scale values from maybe 0.8 or so up to 8.0)
Complete: 53 / 99
This is not a final list, but just a starting point of what is left to be done.
To test scaling, either change thee scale factor in enlightenment's Settings -> Look -> Scaling settings and/or run apps like elementary_test like:
Note that the most common scale factors will be from about 1.0 up to about 2.0 or maybe even 3.0.
To test enlightenment, simple modify the theme, compile and install like above, then restart enlightenment with ctrl+alt+end and see the changes you made. To test elementary, use elementary_test and just run it again after making changes and test the changes you made with the appropriate tests and widgets. Remember you can shortcut to a specific test with elementary_test -to "main menu" for example, or whatever the name of the test is on its normal launch button. It probably is also wise to test existing EFL applications you can find in git too.
I don't like the colors
Whatever arguments for or against the color scheme, this is the scheme used, so please be consistent with it. The point ultimately is to have all colors defined in color classes (shadows might be the exception except for defining alpha so depth of shadow, as a shadow by definition is not a COLOR but an absence of colors thus pushing something to be closer to black than it would be without a shadow). the idea is that eventually we can have multiple color class schemes that can be configured by end users and just selected from a list, then applied (or also custom created or modified). This would work in theory for any theme that is properly designed to re-color via color classes. The default theme should be a prime example of how to do this. So stick to the color scheme that's there, and at a later stage custom variants can be made to be light, beige, pink, purple, green or fully rainbow madness if people like. This should apply to everything, so icons that are "monochrome shapes" should be drawn white then use colors to define the real color in the UI that multiplies the original white color.
A color scheme editor, chooser and applier have yet to be written, so it is a piece of work that needs to be done at some point before all of this settles. Then EFL can ship with a set of color schemes for users to choose from by default. The same way arguing over "it's too small" or "too big" gets solved by just setting a scale value that works well for you, and font preferences can be set with text classes, as well as sizing/padding preferences can be set by size classes. One idea is to also have a color scheme generator that can create a color class set from some existing image/photo. Scan the image pixels and look for "contrasting colors with a reasonable population of pixels" to choose a few base colors then create variations of them for background and foreground elements to ensure they are visible, and perhaps choose lighter or darker colors for specific use cases based on user input etc.
The reason color classes have not been done yet is that it is easier to mess with the colors of an element while designing and putting everything together when the color of that element doesn't affect other elements too. Also the color classes need to be cleanly chosen with a proper hierarchy. For example "ui/background/window/default" so we can in future define "ui/background" and everything under "ui/background/*" will use this color UNLESS it overrides it like "ui/background/window/default" would override "ui/background/window" which overrides "ui/background" which overrides "ui". But this is not perfect because we might also want to define "ui/*/default" as a fallback for anything that matches that glob. This is an undefined and unexplored color scheme naming setup, but it needs to be done, because once we make color classes (and size and text classes) a formally supported "API" in themes, we can't break it. To date this hasn't been formally supported yet. Due to not knowing just how to make this all work, holding off on throwing classes at everything is probably a good idea until patterns become clear across all of the theme.
Might need new edje features
I already added the offscale tag to Edje to enable the relative offsets to be multiplied by scale factors. This seriously simplified making elements scaleable. We may need more features like for the color classes above, as well as maybe a tag and flags to multiply or SET offsets to the value stored in a size class (size classes define a single value for a named class, with the idea that elements can be set to the size or affected by the size stored in a size class, allowing a user for example to adjust the spacing/padding between elements). Most of these features are small and simple, but do not hesitate to notice a feature is probably needed to make things work or be "saner to do", and then add it, or discuss adding it.
Keep in mind a theme is a piece of art work that lives. Decisions are not always made because of some statistic or number, but because "it feels nice" or "looks good". That makes it subjective by nature. A theme works if it is consistent within itself, so everyone throwing in their preferences wherever they like will ultimately lead to something even worse. Consistency is good. If there is to be a change to some design direction it needs to change globally, so keep that in min d when wanting to change something in a way that doesn't "fit". Changes could be far wider reaching that you may think if they are to be done properly.
Also pay attention to details. Zoom in. Use tools like xmag or Eruler: https://git.enlightenment.org/apps/eruler.git/ and zoom in to make sure you got things right. Look for off-by-ones and proper centering. Measure pixels to be sure. Quality is an important thing and these little details make a big difference to apparent quality at the end of the day.
If this can be done by more than 1 person over a period of time, then we stand a chance of getting this theme into a new release of EFL fairly soon. If not, then it'll move along very slowly. So just devoting a little bit of time here and there is useful if a group of people do it regularly. Sharing your ideas with screenshots would be good. Mess with an idea and pop up a screenshot here on this ticket with "does it look good?". This would be good to get some feedback before you are sure about something.
If you draw something, please keep the original xcf layer files from gimp or svg files from inkscape. There is a data/elementary/themes/orig directory to place original images into. It is important to keep and publish originals in their expanded form as much as source code is important for binaries. It is what allows people to work on top.
If you have commit access, then just doing git commit/push like any source code should do. If you don't using arcanist to raise patches like any source code will also work. This may be an arty project, but it can be done like any normal source code. Make sure you remember to git add dependencies (new edc files, added image files etc.).