This patch add tooltip and mouse cursor support for items of genlist
and gengrid and extends the elementary tests for tooltips and
cursor
By: Thiago Ribeiro Masaki <masaki@profusion.mobi>
SVN revision: 52805
yeah, i should do the tooltips one as well, but it's boring so I'll
leave the implementation as the exercise for someone else :-)
and yeah, we should have that inside edje, like a nice description {
cursor: "xterm"; }, but that's not going to happen in Edje 1.0.
SVN revision: 52793
If you have problem seeing stuff due theme misses, then use:
export EINA_LOG_LEVELS=elementary:4
and you should see some reports of missing groups with files. This
helps a lot for genlist and its complex way of naming items :-)
SVN revision: 52791
instead of refetching and revalidating Widget_Data everytime, just
handle it. Although this will save some instructions, the goal is to
make code shorter and less error prone.
SVN revision: 52790
With this commit is now possible to not use theme's cursor (default behevior)
that could be overriding cursors defined by the engine.
SVN revision: 52761
Basically, get the group from widget theme, using the string passed to
elm_object_cursor_set, get hot spots x and y from the theme (keeps the object
and these two integers on cursor struct).
Cursor is set with ecore_evas_object_cursor_set()
Some functions to change style were added to the api.
SVN revision: 52760
Raster, if possible give it a try as it seems that most of the focus
steal and clear is your code and maybe you have a clue of what is
happening. For instance I have no clue why that global focus_order
counter that always grows.
This test is now exposing various problems, some of them is what bug
us in Editje, some is what eve's url bar, etc:
- press "Give focus to scrolled entry", then press it again. See
that the scrolled entry looses its focus, although we're giving it
focus? This is related to the object loosing focus but not
detecting it, thus the next elm_widget_focus_steal() will just
ignore it and say "you already have focus, do nothing!"
- start pressing "TAB", after a full iteration, the next iteration
just goes up to the last item. If you keep doing that, at some
point the TAB will just not work anymore. If you change PARENT
from "bx" to "win", then it does not happen. But adding to "bx"
would be the correct thing to do (more logical structure)
SVN revision: 52709
Most of the errors referred to the cast from int to void* in x86_64.
This need conversion to long, as intermediate.
Some calls to elm_widget not exposed API were changed to their similar
at elm_object API.
Elm_Photo never call "drop" smart callback, but i leave the callback
in tests.
And others API methods are included in Elementary.h
Now elementary build with -Wall -Werror in x86_64.
SVN revision: 52691
it's simple. only allows 1 level of theme. would need an advanced
dialog to allow:
theme1:theme2:theme3:theme4... etc.
also no browsing for themes - just whats instaleld n system and user
dirs atm.
SVN revision: 52667
This defines a new theme group for elm_scrolled_entry:
"elm/scroller/entry/$THEME". Themes that wants to support the icon/end
feature in scrolled entry should implement parts "elm.swallow.icon" and
"elm.swallow.end". Black&White theme has been changed, Effeniht changes
to come on a later commit.
SVN revision: 52657
These two functions mimic what is already done in gengrid object.
* elm_gengrid_item_show : scroll immediatly to the item
* elm_gengrid_item_bring : scroll with an animation to the item
SVN revision: 52620
Subject: Re: [E-devel] Transition Layout for elm_box
There are 2 simple problems with the committed code. First, it would
be better to locate the struct _Elm_Box_Transition in elm_box.c
instead of Elementary.h.in, because users should create it with
elm_box_transition_new and changing its contents can be dangerous. And
second, in struct _Transition_Animation_Data, I declared 4 coordinate
variables as int, instead of using Evas_Coords.
I am sending both patches attached.
SVN revision: 52560
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
Subject: patch for indentation and using enum in elementary
I send the patch for elementary.
In this patch, I fixed the indentation of Elementary.h.in.
In addition, I use EINA_TRUE or EINA_FALSE instead of 1 or 0.
EVAS_HINT_EXPAND and EVA_HINT_FILL is used instead of 1.0 and -1.0.
Thanks.
SVN revision: 52447
Calling resize_object_del() when a resize_object died calls
elm_widget_sub_object_del(), which sets the parent of the (now dead)
widget to NULL. The problem is that this breaks some of the
stuff done in the smart_del() method in the smart class for widgets,
like reverting focus to whoever held it previously.
SVN revision: 52387
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
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
The els_scroller.c:_smart_add() as disabling event propagation on
itself, that way an owner object (ie: elm_scroller,
elm_scrolled_entry, elm_list, ...) was not getting the mouse events it
gets, thus any evas_object_event_callback_add(..., EVAS_CALLBACK_MOUSE_*...)
were not working (effectively breaking tooltips).
Seems that the reason to do so was double-event reporting. It could
happen as the elm_smart_scroller has an event_obj that repeats event,
thus the object behind it, the edje_object, could get and possibly
repeat them as well.
As we are sure event_obj always get the events, but not sure of the
edje, as it depend on user contents, the logic is now changed to stop
propagation of the edje instead (it still processes the events! just
not propagates to elm_smart_scroller).
I hope this patch does not break anything, but please check your software!
SVN revision: 52350
It was elm_panes_horizontal_is, but grep shows no matches.
So I'm guessing horiztonal_get.
Seems was originally comited by watchwolf when the file was added.
SVN revision: 52287