There's currently in Elementary a way for widgets that die to revert
focus to whoever had it first, but it was broken in some cases.
SVN revision: 52550
The Elm Widgets aren't disposed exactly as trees of Evas Objects, so
need store widget parents separated from Evas Smart Object parents.
The Evas propagation events don't satisfy all use cases. Like managing
events in elm_win or try if one parent manage the event before manage
it.
In this, I add hook to each widget manage their interested events or
from their child.
SVN revision: 52527
There's still work to do here, particularly in the theme, but it has
something nice and fun to see the code working.
The idea behind this:
Window tracks focused object and sends the highlight object(s) to it. These
are simple edje objects, one on top, one below the focused widget for nice
effects. Widgets can choose to ignore the highlight and this will be sent to
the parent object, if it doesn't ignore it as well.
About the bottom object, it doesn't work now. For the most part, focused
widget will always be a member of some smart object, so stacking won't work
and the desired effect is nowhere to be seen. This will be worked out later.
To be done now:
- Let the theme for a widget define its own highlight, disabling if needed
the standard one for those objects.
- Needed base in code to allow animations when switching focus. All in theme.
- Properly test all widgets and fix some things that will most likely work
in weird ways, given the nature of Evas/Edje and how Elementary makes use
of them.
- Forgot the rest, stay tuned, test, report, give ideas, plant a tree.
Work started by glima, continued with some refactors by me when he
decided he needed vacations.
SVN revision: 52524
Widgets can have customized cursors setting it with elm_object_cursor_set.
Widget's item can use elm_X_item_cursor_set to set a different cursor
for each item.
It will work only if HAVE_ELEMENTARY_X for now, but support for themeable
cursors is planned.
SVN revision: 52382
Now owner widget (elm_widget) is just used to listen for theme changes
and create/destroy the tooltip data. The actual mouse events operates
on all Evas_Object and is the one where tooltip data is actually
stored.
The public API is basically the same, just the event_info is now NULL
to avoid confusion.
The internal API introduces elm_object_sub_tooltip_content_cb_set()
and as the first parameter the eventarea. While this may be confusing,
as the second parameter is the actual elementary object, it is the one
that all other calls receive, like elm_object_tooltip_hide() or
elm_object_tooltip_unset(), thus it does make sense to have such order.
Also internal API, elm_widget_item_tooltip_* functions were
added. They are a variation of the widget API to handle its items, as
such the func() gets one more parameter: item, and the del_cb() gets
the item as event_info (that's why the public widget version got
event_info always NULL, to not confuse with this one!)
Widgets with items that makes sense to have tooltips got extra API:
* toolbar
* list
* gengrid
* genlist
SVN revision: 52173
Tooltips are set using elm_object_tooltip_content_cb_set(), that
returns the desired Evas_Object to use as contents, or using the
helper function elm_object_tooltip_text_set() that uses that
underneath.
The behavior is controlled part on elm_config, theme and user
application. In elm_config one defines the tooltip timeout. The theme
defines the padding around cursor x/y and window border x/y, as well
as the look and feel. Last but not least, the user application may
want to change the tooltip style with elm_object_tooltip_style_set().
Have fun!
This code was initially written by Tiago Falcao and Fabiano Fidencio,
I did some API review and changed some bits.
TODO: elm widget item support, like with toolbar items.
SVN revision: 52150
Lots of widgets have items that are not Evas_Object of type elm_widget
per se, like Elm_List_Item or Elm_Toolbar_Item. They all have, or
should have, some common attributes and functions such as data,
del_cb, a view object and a parent/owner widget. Thus this is being
provided and will be later used in future patches.
Right now I opted to hide elm_widget_item_del_cb_set(),
elm_widget_item_data_get(), elm_widget_item_data_set() inside
elm_priv.h and keep the old functions as wrappers to the new. But
maybe in future we can remove them and have the user to call the
common function.
Future extensions will use this base, such as tooltip support.
SVN revision: 52116
elm_object_signal_listen add callback(s) for edje object(s) of the widget.
elm_object_signal_unlisten delete this callback.
They're general functions, and every widget should set hooks for these.
It will improve elm extension flexibility. We have already
elm_object_signal_emit to send signals for the widgets theme, adding callbacks
is an expected step.
It provides a way to support sound on widgets. For example, in the elm extension
we could emit "file_to_play", "play", and add a callback with
elm_object_signal_listen for "*", "play". The callback function could use
the signal received to request the file to be played by the backend
sound system.
Certainly we should look for a better way to provide support for sound
on edje, but for now, it does the work. And anyway, it's only a use case
for these new functions.
SVN revision: 49868
This function sends a signal to the edje object of the obj.
It's a general function, and every widget should set a hook for this.
I'm setting a hook only for the spinner now, but soon I will work on other widgets.
SVN revision: 49681
is parent of an Evas_Object.
With these in place, one can check if the given object is an elmentary
widget and query for the first widget that is parent, so we can add
them and keep focus chain correct, useful for Edje externals, patch to
follow.
SVN revision: 47374
This plays well with edje's own deferred calculations. Usually size
hints are set on children and edje will flag itself as dirty, but real
calculations are deferred to "calculate" phase before rendering.
For now this unbreaks elm_layout with contents... but other types such
as GROUP, BOX and TABLE remain broken: when they change their internal
state (ie: child object is packed into box or table), this will not
trigger elm_layout.
That said, we need a better solution. Maybe ask edje to emit signals
when one of its children change hints (it already listen to this
anyway), in this case elm_layout should listen to those instead of
connecting directly to objects given through elm_layout_content_set().
SVN revision: 43752
Tiago Rezende Campos Falcao
Iván Briano
Gustavo Lima Chaves
Bruno Dilly
Carsten Haitzler
이명재
Gustavo Sverzut Barbieri
Lucas De Marchi
Fabiano Fidêncio
Vincent Torri
Boris Faure
Jonathan Atton
Christopher Michael