Page MenuHomePhabricator

E/EFL Flat Theme
Open, TODOPublic

Description

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.

Help needed

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://git@git.enlightenment.org/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:

./bt.sh

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)
    • Check
    • Radio
    • Toolbar (seems to have a bug)
    • Scrollframe
    • Dialog base
    • Button (legacy not done)
    • Preview/Livethumb
    • Ilist
    • Color
    • Colorslider
    • Colorwell
    • Spectrum
    • Fontpreview
    • Frame
    • Slider
    • Entry
    • Edge Bindings
    • Deskpreview
    • Deskmirror
    • Label
    • Randr (old dialog)
    • Textblock
  • E old gadgets like Music Controller for example (partly done)
    • Gadman move/resize controls
    • Appmenu
    • Pager
    • Start
    • Ibox
    • Battery
    • Ibar
    • Xkb
    • Connman
    • Bluez5
    • Bluez4
    • Systray
    • Tasks
    • Cpufreq
    • Clock
    • Packagekit
    • Temprature
    • Backlight
    • Settings
    • Everything Launcher
    • Tiling
    • Syscon
    • Music Control
    • Mixer
    • 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:

ELM_SCALE=2.0 elementary_test

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.

Art

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.

Team Work

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.).

raster created this task.Feb 24 2018, 6:31 AM
raster triaged this task as TODO priority.
conr2d added a subscriber: conr2d.Feb 24 2018, 7:02 AM

I'm on board and working on the theme now. THIS is what we were missing. Great plan. I only have a few comments.

A. A lot of time could be saved here if we just included an already existing icon theme that matches well, and most icon themes come with light and dark versions. We just have to make sure we follow licensing correctly.

B. Your screenshot is missing Ephoto :)

C. It's possible that using a fully namespaced colorclass system is overkill, though I do like that your idea is for inheritance to exist. Alternatively we could just come up with a few colorclass definitions that are needed to recolor the theme. COLORCLASS_DARK COLORCLASS_MEDIUM COLORCLASS_LIGHT COLORCLASS_TEXT_DARK COLORCLASS_TEXT_MEDIUM COLORCLASS_TEXT_LIGHT COLORCLASS_SHADOW_DARK COLORCLASS_SHADOW_LIGHT COLORCLASS_HIGHLIGHT etc... and end up with just 15 or 20 or so color class defines that can be changed very easily via a file colorclass.edc or whatever to completely recolor the theme. Either way I think will be fine - just a discussion of which way will the be the easiest, most flexible, best going forward, and the least intimidating, etc...

Again this is a step in the right direction and I am already working on the theme. Let's get this done in a soonish manner!

A. A lot of time could be saved here if we just included an already existing icon theme that matches well, and most icon themes come with light and dark versions. We just have to make sure we follow licensing correctly.

For now that's why i suggested the flat remix theme. i've used it with the flat theme and it seems to work together well. unfortunately colroclasses don't solve the "dark vs light" when it comes to icons... well icons that are not mono-colored.

but reality is that i'd PREFER to have our own icons. at least for the major things. it's kind of pride in your work. just re-using some other theme is kind of being lazy. it's a "will do for now" but needs to be worked on. i am actually just replacing some of the most visible efm icons on the desktop right now... :) but ... as above. flat remix is probably a good "drop in for now". i'd resort to copying it into our tree as a LAST stage before release for any icons we have not already replaced ourselves. does that sound reasonable? until then just grab the external icon theme and select it at least for your app icons etc.

B. Your screenshot is missing Ephoto :)

you are right. i failed on that! :)

C. It's possible that using a fully namespaced colorclass system is overkill...

while you are right in one respect (keep it simple and save time), once we formalize color classes, there is no "well we need to improve it now and break compatibility". formalizing color class, text class etc. names is IMHO a key part to the whole recoloring thing working out. people shouldn't make new THEMES just for different colors. there should be a nice eet file that holds a color scheme (really a list of color names and color values). maybe edje can load it or elm loads it and uses edje api's to apply it).

but ... once we make this something to be used it can't break... this api needs to be designed to work well in future, and that's why i think we may need a hierarchy, and that requires some thought and a big picture to plan it for and understanding of the trade-offs taken to achieve the result. same for text and size classes.

perhaps what we need is something else than a hierarchy? a mapping table where we can map different versions of the color class api (name set) to/from old or new names so that allows us to change in future as long as a mapping table exists from an old color scheme file to a new color class api version, or vice-versa? maybe it's as simple as a version in the edje file and a version in the color class scheme file, and if they don't match it won't use it, BUT there are upgrade/downgrade binaries/tools that can take a color scheme file and convert it to a new version? this of course requires work to make these conversion tools every time a change is made, and it'd be a good idea to spend some advance time to minimize such future work if this is the way to go.

i'm very cautious of taking shortcuts to save N days or weeks only to regret them in 6, 12 or 24 months and have no way out without breaking everyone's color schemes and/or themes. i want to minimize the possibility of this event happening. either way this is an important thing to discuss and agree on because this direction will be set in stone once done.

Again this is a step in the right direction and I am already working on the theme. Let's get this done in a soonish manner!

:) it took me a bit to get to writing all of the above up as it wasn't going to be short, but it's probably the best start for now. it could have become an expansive document detailing precisely the color scheme colors that must be used (for now to be consistent) and precisely the padding to use and how to make things scale, etc. etc. but that'd just be an insane amount of work where most of this information is visible in the theme and on screen. i hope this should do and otherwise discussion can resolve differences.

Hi all there.
I have some experience on theme building. So I can help with genlist widget for beginning.

stephenmhouston updated the task description. (Show Details)

I do have a concern with shelves and gadget bars (formerly bryce) ... the 6 pixel indicator on pager/ibar/ibox/luncher is a bit large... looks quite good at 4 pix or so for me. Thoughts?

umm i count them at 5 pixels. also scrollbars are 5, the bar on the right side of hoversels is 5. probably some other places i've forgotten about? just saying - it should be consistent.

i also at least tried to make some scale, so if your scale factor is > 1 then that may explain why its > 5 pixels.

also i think i made it thicker because it animates. it slides in when it appears and slides out to disappear. if it has very few pixels to do that over, the animation looks "less smooth". keep that in mind.

so one way or another changing this means changing lots of other places to keep things consistent.

yup. you made your shelves/bryces 32 pixels, not the default 40. that's why they may seem a bit big for you... :)

zmike added a comment.Feb 28 2018, 1:09 PM

I've created a flat dev branch which accomplishes the following:

  • rebases the flat theme onto master and resolves conflicts from theme changes
  • moves the flat theme to data/elementary/themes/flat in the repo
  • renames the resulting .edj file to flat.edj

Current users of flat will likely be reset to the default theme after updating, but there should be no issues. This branch should be pushed to overwrite the current feature branch for flat, and all work should be done based on my dev branch until that time.

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:56 AM
segfaultxavi edited projects, added efl: widgets; removed Restricted Project.Jun 11 2018, 9:09 AM
raster updated the task description. (Show Details)Jul 19 2018, 2:18 AM
akanad added a subscriber: akanad.Nov 6 2018, 9:07 PM
stephenmhouston updated the task description. (Show Details)

@raster can you update the work you've done here so I can see what's left? Thanks.

raster updated the task description. (Show Details)Jan 24 2019, 2:07 AM
raster updated the task description. (Show Details)Feb 13 2019, 6:32 AM
raster updated the task description. (Show Details)Feb 13 2019, 7:23 AM
raster updated the task description. (Show Details)
raster updated the task description. (Show Details)Feb 13 2019, 7:31 AM
raster updated the task description. (Show Details)
raster updated the task description. (Show Details)Feb 13 2019, 7:37 AM
raster updated the task description. (Show Details)Apr 26 2019, 5:46 AM
raster updated the task description. (Show Details)May 9 2019, 10:07 AM
raster updated the task description. (Show Details)May 9 2019, 10:13 AM
raster updated the task description. (Show Details)May 9 2019, 10:23 AM
raster updated the task description. (Show Details)May 10 2019, 3:19 AM
raster updated the task description. (Show Details)
raster updated the task description. (Show Details)May 10 2019, 3:58 AM
raster updated the task description. (Show Details)May 16 2019, 9:08 AM
raster updated the task description. (Show Details)
raster updated the task description. (Show Details)May 16 2019, 9:30 AM
raster edited projects, added Restricted Project; removed Restricted Project.Fri, Jun 7, 5:57 AM