Summary:
It turns out elm/uiclock (which was removed in 89675c3219) is actually used,
at least by the datetime legacy widget. Removing this widget broke the
datetime_example test.
This commit reverts 89675c3219 and fixes the elm/uiclock part names:
- Part names are prefixed with 'elm.'
- efl_ui_clock.c (which is used for both the new efl and the legacy elm widgets)
now looks for part names with 'efl.' and 'elm.' prefixes, and without any
prefix, for compatibility with older themes.
Fixes T6928
Test Plan: the Datetime elementary_test (and all other clock-related tests) now work.
Reviewers: zmike, jsuya, CHAN, devilhorns, Jaehyun_Cho
Reviewed By: zmike, jsuya, CHAN
Subscribers: #reviewers, Jaehyun, Hermet, cedric, #committers
Tags: #efl
Maniphest Tasks: T6928
Differential Revision: https://phab.enlightenment.org/D6577
Summary:
Legacy widget is elm/clock, and the new one is efl/uiclock.
There does not exist a legacy elm/uiclock.
This also reverts commit 20404d79d4
(elm_datetime, efl_ui_clock : Add check 'legacy widget' for layout signal emission)
Since there is no need to check for legacy versions of uiclock.
Ref T6965
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T6965
Differential Revision: https://phab.enlightenment.org/D6450
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.