If there is a released legacy API (ie. the theme is in edc/elm/ in the tree) then the namespace should be 'elm'. If it is only an eo API (ie. the theme is in edc/efl/ in the tree) then the namespace should be 'efl'.
The tree location should relate to the C implementation; if the widget has a released legacy API (ie. elm_$widget_add) then it must have an 'elm' theme component.
It seems that this widget has not been released as a legacy widget, which means that it should only have 'efl' namespace. I'm going to abandon this patch, but I think it can be used as a reference when someone makes a better attempt at fixing the issues than I have.
I have some questions.
- uiclock has never been released as legacy, so what was the previous clock widget? elm/clock?
- There's elm/uiclock.edc and efl/uiclock.edc. Does this mean that we are going to release this new widget both as efl and legacy?
- If yes (we are going to release the new widget both as elm and efl), should the parts in each edc file have its own prefix (elm. and efl.) ?
- If yes (we are going to release the new widget both as elm and efl), should we create a new src/lib/elementary/elm_ui_clock.c?
- What is wrong with @zmike's diff above?
@Hermet or @Jaehyun_Cho can confirm, but it seems that there is no legacy API for this widget and it is only to be used with interfaces? In this case, I'm not sure why there is any "elm" code or theme groups in the codebase, as it seems like this should only use "efl" and have no legacy checks. This means that it should be possible to safely remove the edc/elm/uiclock.edc file entirely.