the problem here is that when we are using the signals from the object,
then the edje object itself will receive press/unpress events before
any content that is swallowed into the edje object.
This means, that no clickable content, added to a item could be clicked
without selecting / unselecting the item. Which was a problem.
With this commit the theme is sending signals which are then passed to
the efl.input.clickable mixin, this way, the part is stacked below the
added content, which means, clickable content will not select / unselect
the item anymore.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10892
Summary:
"Dragable" is a misspelling:
https://en.wiktionary.org/wiki/dragable
We have it EVERYWHERE in EFL, even with jokes:
./src/lib/efl/interfaces/efl_ui_drag.eo:1
This patch only fixes the theme API so it does not get carved in stone for this release.
Depends on D10217
Test Plan: No functional changes.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10218
Summary:
To make clear the meaning, hbar and vbar are replaced to horizontal_bar
and vertical_bar.
Reviewers: zmike, woohyun, segfaultxavi
Reviewed By: zmike, segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10217
Summary:
this is just output from edje-theme-spec tool. it isn't really enough to
be considered full theme documentation, but it's better than nothing
ref T8231
Depends on D10196
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8231
Differential Revision: https://phab.enlightenment.org/D10197
Summary:
this needs to be provided to verify that the theme corresponds to the
current version of the widget
ref T8231
Depends on D10079
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl_widgets
Maniphest Tasks: T8231
Differential Revision: https://phab.enlightenment.org/D10080
Summary:
legacy full style item is introduced Efl.Ui.ListEmptyItem Class in new Efl Interface,
but using "Empty" name is too ambiguous to present style usage.
Thanks to @cedric and @segfaultxavi,
I found better name for this class, Efl.Ui.ListPlaceHolderItem,
as item hold the place which need to be replaced and relayouted by user generated content.
Depends on D8582
Reviewers: cedric, segfaultxavi, eagleeye
Reviewed By: eagleeye
Subscribers: cedric, #reviewers, segfaultxavi, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9034
Summary:
Most of item-based class will have similar efl.part such as text, icon, end.
creating this efl part per each class will be very hard to maintaining the class
and unnecessary eo generation.
so combine them in efl.parts of efl_ui_item.
sub item classes can use this efl.part by declairing ther own eo definition.
Reviewers: cedric, Jaehyun_Cho, segfaultxavi, eagleeye
Reviewed By: cedric, eagleeye
Subscribers: herb, woohyun, q66, lauromoura, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8582
Summary:
View is not a namespace, but an interface,
So, View_List cannot be under the view namespace for now.
it looks more suite to be end as View than List on this widget name.
Firstly, it follows our common naming rules of class.
Also, List_View is commonly presentable name on most UI frameworks,
so it is very easy to understand what this widget can do for the user.
Test Plan:
Make works.
Example is not works for now til stable model interface.
Reviewers: felipealmeida, woohyun, cedric, Hermet
Reviewed By: Hermet
Subscribers: larryolj, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7234
Summary:
most usage of simple list, items are very limited and loading performance is not serious.
to support those requirement, this efl.ui.list will create scrollable box with efl.pack.
user can create list by packing an pre-loaded item object, Efl.Ui.List.Item class.
Test Plan: tested in efl_ui_list_example_1.c in examples.
Reviewers: cedric, felipealmeida
Subscribers: woohyun, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5861
Summary:
model based list need to be under the namespace of 'Efl.Ui.View".
thus, I renamed 'Efl.Ui.List' to 'Efl.Ui.View.List' properly.
Test Plan: N/A
Reviewers: cedric, felipealmeida
Differential Revision: https://phab.enlightenment.org/D5855
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.
Marcel Hollerbach
Xavi Artigas
Jaehyun Cho
Mike Blumenkrantz
SangHyeon Jade Lee
Amitesh Singh
Carsten Haitzler
Mike Blumenkrantz
Felipe Magno de Almeida