This is where flat is now good enough to get to master, so ... in it
goes. it needs a lot of cleaning. lots of images no longer used in the
tree. needs wortk on colorclasses and what not. needs polishing for
scaling (much better than old default though). probably needs a
once-over yto ensure things have not been missed.
@feat
Summary:
this was a little bit weird. There was a script that did what we already
do in C and pass it on via signals, however, there was also somewhere a
bug in this script, the arrow was not getting enabled, even if the
position is not completly max and not completly min, the problem here
was that the numbers that are passed to edje are not 100% correct (I
think they got somehwere on the way casted to an int).
With this commit we just use the signals from c in the theme and replace
the theme, this should also make everything a bit easier on the
mainloop, as a single movement of the scroller does not schedule 10
timers anymore.
ref T4918
Reviewers: zmike, eagleeye, woohyun
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T4918
Differential Revision: https://phab.enlightenment.org/D9906
This reverts commit d764e0b279.
The whole idea of renaming the default theme is an "api break" even if
config is changed. and symlinks don't work on windows as a solution.
(well on ntfs only as only as administrator, so they don't exist).
modifying config for switch from default to dark also will break the
case where someone put ~/.elementary/themes/default.edj there and it just
is different to the system one and how their theme changes on them as
it switches to dark.
basically we can't rename a theme like this mid-flight in efl. default is
default and has to stay that name. it can change the look, but not the
name.
i think the apparent reasoning behind this is not a good one. the work on
flat is temporary. i don't think we will ever maintain multiple "default
themes" as its just far too much work.
we can maintain color SCHEMES which are just a list of colorclasses and
colors for them - that's separate to a theme and would override. right now
these things don't exist. we are not going to create a dark.edj and a
light.edj just to store differing default colorclass values. we should be
doing the above with colorclass "color palette/scheme/whatever" files
that override those named colorclasses globally on init.
so reverting because this is an api break and we shouldn't break api
unless there is really absolutely no other choice.
here the choice is to just temporarily work in a branch and modify
default and then merge the branch when done.