Small patch to update keyboard led(s) when caps, numlock, etc are
pressed. This patch adds some fields to internal (non-API exposed)
structures inside our private header (of a BETA-API library) and thus
should still be ok during freeze.
Fixes T5655
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we have no data device manager present, we would still like to
receive events when input devices get added or removed so these
handlers should be setup before we return from this function.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we are in the Ecore_Wl2 library, lets use a function name that
reflects this.
NB: No functional changes
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
This is one of the basic examples that introduces Ecore-Evas, so needs
to be more detailed in commentary than other examples. It also points
out the use of the legacy API and directs the reader to the Eo example
where appropriate.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5008
When using the legacy API (and in fact also with the EO API) to
listen to mouse events (move, in, out...) on a window instead
of an actual evas object, some information was missing:
- buttons (bitmask of pressed buttons)
- prev.x/y (previous position)
This is because Evas had not handled the event yet at this
point, it was coming directly from ecore_evas with incomplete
information. This patch involves evas a little bit earlier, and
also fixes evas_events_legacy.c to have consistent values for
cur/prev canvas/ouput coordinates. See also 890a91785 and
484dae76e6. Those commits were making the pointer coord
a seat-based property (instead of canvas-based) but the event
should already have those proper values before converting to
a legacy struct. This patch restores the meaning of the DUP
macros, as I observed 4 different coordinates from the app side
(instead of just 2: prev and cur).
Thanks to Andy for reporting the original issue on the ML!
in x11 the mouse pointer is separate to everything else on the screen,
and so when screensaver kicks in and we fade to/from black or we
suspend/resume and do the same... the mouse pointer stays annoyingly
visible and it just lookes like a bug. this allows that to be fixed by
allowing the pointer to be suspended or resumed... :)
@fix
Summary:
In visuals_set function,
check action_area is NULL, and signal emit action_area,visible/hidden
So, before call visuals_set, action_area should be deleted.
Test Plan: Actually, action area has not min size, so it couldn't be observed.
Reviewers: herb, singh.amitesh, jpeg, cedric, conr2d
Reviewed By: jpeg
Differential Revision: https://phab.enlightenment.org/D5007
Summary:
Summary : String buffer returned by eina_strbuf_new() is not freed in some cases
@Fix
Signed-off-by: Uma Devika <u.bodapati@samsung.com>
Reviewers: cedric, tasn, jpeg, raster, singh.amitesh
Subscribers: tanwar.umesh07, yashu21985, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5000
Summary:
This was causing problems on non-Linux architectures as eina_file_real_close unmapped not mapped data. Added a "copied" flag to Eina_File which is set on eina_file_virtualize (on copied data), and tested for when eina_file_real_close does the unmap. I'm surprised Linux allowed this. Certainly all of the BSDs crashed with the previous behaviour.
@fix T5479
Test Plan: Example inlcude Rage and Enlightenment Thumb on BSD systems which use eina_file_virtualize with emotion to obtain album artwork.
Reviewers: raster, cedric, jpeg
Reviewed By: jpeg
Maniphest Tasks: T5479
Differential Revision: https://phab.enlightenment.org/D5006
so we copy data to an UNALINED memory address (just after whatever
string we packed on the end of the eina file struct header). this is
bad. especially for non-intel architectures. this forces a 16 byte
alignment which should cover us.
@fix
After ab23a53094, evas_object_size_hint_align_set()
has stopped working on elm img and that patch was perfectly right
to do so but we don't change the old behaviour.
This patch is an effort to make evas_object_size_hint_align_set()
to work with elm img again.
make sure not to mix both eo apis and legacy apis.
Thanks to dave for reporting and jpeg to show the right fix.
fixes T4635
This reverts commit 5a0db7cc67.
Reverting this since ab23a53094 breaks the old working behaviour
on image align. subsequent patch in efl.ui.image brings back the old
behaviour.
refer T4635
Inside efl_part() we don't know whether we are dealing with a text
or content API, so we can't actually guess the proper alias.
The legacy API should have already dealt with aliasing at this point.
The EO API should not use those aliases.
This in theory should only affect the EO API usage. In EO
we don't want efl_part() to be used for NULL part. In other
words, there is no "default" part in EO objects. Instead, those
functions like text_set or content_set should simply be
implemented by the object themselves.
The legacy API on the other hand will make sure that the
"part" argument is set to a non-NULL value before reaching
this point.
This is a follow-up to a4b79fdbe1.
efl_part no longer supports NULL parts.
NULL text parts are now aliased in legacy code beforehand.
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Omg this was a pain... The code is complete spaghetti and the
fact that the main menu is now in the framespace doesn't help
either. With this patch and the previous one (about ecore_evas_x)
Edi should be able to open correctly at the proper size and with
a visible menu.
This patch introduces a lot of changes so it'll need testing
before we accept it fully.
Fixes T5482
If the framespace size has changed and by accident (or in fact, by
design) the evas size + framespace size is equal to the size sent
by the X server, ecore_evas_x was skipping the resize event. This
patch adds a tracking of the framespace size so that we redraw the
canvas if it changed.
This will fix issues with the main menu (since it's in the framespace,
23 pixels tall with the default theme & scale).
Note that all this is partly because the ecore evas size is the size
without the framespace, so weird calculations are made during resize...
Ref T5482
This should fix issues when the main menu is wider than the
window content. This assumes that the menu is horizontal and
aligned with the client content.
The theme should probably handle this case better but right
now I am lost in the spaghetti resizes happening between
edje, elm, evas and X...
I am not very happy with this patch, and I think border.edc
needs some love in order to make it more robust and simpler
to read.
Ref T5482