now if applying the orientation style is failed, it tries to apply the original style. if it fails again then default theme.
also it fixed a logic error when theme changed is happened.
It will try to apply the original style if the orientation style is invalid on theme changing.
SVN revision: 84082
First things first, I'm not sure I'm setting the right variable on
the setlocale() call, so someone more knowledgeable can look at it and fix it.
How this works, you say? Just like elm_object_text_part_set(), except now it
will pass the string given through dgettext() with the given domain (NULL
means it uses whatever the app set with textdomain()), and when changing
language with elm_language_set(), it will re-set the strings with a new
translation.
SVN revision: 64179
these bad boys are so big and pixelthirsty they can't be constrained by a regular canvas or window, they use OVERRIDE REDIRECT WINDOWS. not only that, they totally exceed the boundaries of what a reasonable function name length could be. 50 character function name limit? puh-leeze. these guys don't care what side of the screen they're even on so long as they get to wade into the thick of the action and block out each and every crappy non-efl application behind them. and that's when they're in good moods. you don't even want to know what happens when you piss these guys off.
SVN revision: 61735
don't connect twice to the same object (happened whenever not using
sub-items), then the callback was being called twice.
also set the dead object pointer to NULL, so we avoid operating on it
any further.
SVN revision: 52354
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
Whenever object starts hiding Elementary sends "elm,action,hide", so
when it aborts such action it must always emit "elm,action,show" and
the best place to do this is at _elm_tooltip_hide_anim_stop().
Note: _elm_tooltip_hide() calls _elm_tooltip_hide_anim_stop() and thus
would show the object, but this is void as right after that the
tooltip object is deleted and thus the signal is never processed and
as we don't go back to main loop, nothing changes on screen.
SVN revision: 52167