Needed to do some fairly invasive changes because naming conventions
changed since we checked in the header.
Also, since I'm done converting protocol, change the gitignore to
use wildcards for wayland protocol.
This fixes a long standing bug in text-input binding and restores
previous OSK behaviour.
This became core wayland functionality a long time ago, and we
now depend on wayland new enough to have it, so we should never
need the stale copy we had in tree.
This patch adds a new API function that can be called from
Enlightenment wl_drm module to enable output rotation.
NB: Only works if Atomic support is enabled as it rotates the hardware
plane directly...and we don't support planes without Atomic enabled.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to add an API function which can be used to return the
supported rotations of a given output. This is used inside the
Enlightenment wl_drm module to determine if rotations is supported on
an output.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we will need these values when doing rotation checks inside wl_drm
module (for randr rotation support), let's move them out of the
private header and expose them in Ecore_Drm2.h
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to add a new API function that can be called to determine
if a given drm device prefers the use of shadow buffers. This API
will be used later to provide some optimizations on various platforms.
NB: Requested by Derek
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When we are sending input events, if we have no pointer device then we
should be setting ev->dev to a touch device (as touch events are
treated as pointer events inside EFL).
NB: This allows EFL clients to get touch events in Enlightenment.
There are still some small hiccups here (can't close terminology by
pressing the 'x' in the corner, cannot scroll elm_test srollbar, etc).
Likely EFL needs to change wrt all this...perhaps adding events for
touch that are separate from pointer ?...
ref T5094
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If a user calls elput_input_pointer_xy_get (as is done via
ecore_evas_drm) and a pointer does not exist, we never return any
coordinates for this function.
Enlightenment is using ecore_evas_pointer_xy_get (which when using the
drm ee, ends up calling elput_input_pointer_xy_get). If we have no
pointer device, then no coordinates are ever returned and touch
clicking does not function properly.
To fix that we will check if a touch device exists and supply the
coordinates from that (in the case where there is no pointer device).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Now the size evaluation will query for the native size of the
canvas.text object, and continue with calculations to set the min size
of itself.
This fixes a bug in containers where the widget's size wasn't picked up.
Also, the canvas.text object wasn't reporting 'changed' on text changes.
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Textblock filters support RGBA input which means legacy styles
can be used in conjunction with filtering. Not recommended, but
it works. Note: We may decide to drop this behaviour and use
alpha-only inputs for simplicity.
Still missing: support for filtering strikethrough, underline, or
embedded items
Just because I can. It's the filter code editor after all, deserves
a filter of its own. Plus, it tests that we can embed a filter
in the default style, and edit text with a filter and everything
works as expected. Yay!
Filters can have sources like image proxy, and should trigger
a redraw in case the source has changed. Since we cache the
filter's output, we need to first check whether the sources
have changed before reusing a previous output buffer.
If the line height is different from the text item height (eg.
because there are large embedded items) then we need to add
an extra offset to the draw commands.
Note: items themselves are not filtered (yet, at least).
This is a first step before implementing some form of caching of
those output buffers. At the moment, it very aggressively deletes
any buffer that falls outside the clip of the textblock object.
Note that this is better in terms of memory usage but way worse
in terms of render performance (eg. scrolling). If a textblock
is a proxy source then we keep all the buffers (the entire object
is to be rendered).
+ fix a crash
This will be triggered in the rare case when a textblock's
insets are changed (ie. the padding due to filters or style).
This fixes invalid sizing in the test case in elm (due to a
lack of event after program_set).
@feature
This is the most basic optimization that needs to be done for
filters to be useful: cache the output rgba buffers for each
filtered element. Hopefully this doesn't leak. I'm not making
any promises about that though :)
This is a function that allows passing variables from C or EDC
to the filter's Lua code. Useful in particular for color classes
from EDC.
This data would be the global data but we could eventually add
a markup tag to specify a data value per filter instance. For now
a single data value per tb object should be more than enough though.
This makes gfx filters padding work just like the standard style
padding, which means the tb user must offset the object position
by -l, -t and increase the object size by l+r,t+b.
If a gfx filter was applied to a block of text spanning over
multiple text items, then it would improperly render as the
filter context was stored in the format, rather than the text
item. This is fixed by using a list of contexts in the format
node rather than a single context.
This is only for testing purposes for now. Eventually we need
to fix the following things:
- terrible performance (cache buffers)
- force redraws based on filter padding
- expand textblock padding based on max filter padding
- add sources, data and a filter name/code hash
- test! :)
This should save a bit of memory for all image & text
objects. This exploits the previous patch for the post-render
job queue added to evas, and simplifies this bit of code.
This is a preparation step for (experimental) textblock support.
Textblock objects won't have a single filter, and the buffer's
geometry wouldn't be that of of the object itself. Thus a few
internal APIs need to be reworked first.
I believe this function is not required and should not be
used by applications. If there is a very good use case to
use your own main freeq, then the API could be added again.
For now, removing the set() is probably the safer option.
Note: the API was introduced in the upcoming 1.19
Built on top of the new 'postponed' free queue, the short-lived
strings API allows users to return new strings without caring
about freeing them. EFL main loop will do this automatically for
them you at a later point in time (at the end of an iteration).
The APIs provided will either duplicate (copy) or more generally
steal an existing string (char *, stringshare, tmpstr, strbuf),
taking ownership of it and controling its lifetime. Those strings
can then be safely returned by an API. From a user point of view,
those strings must be considered like simple const char *, ie.
no need to free() them and their validity is limited to the
local scope.
There is no function to remove such a string from the freeq.
The short lived strings API is not thread-safe: do not send a
short-lived object from one thread to another.
@feature
While this reuses the existing (but new) infrastructure of
eina_freeq, the mode of operation and objective is very different
from the default freeq.
By default, any object added to the freeq is basically already
freed from the user point of view, and the freeq itself only adds
a tiny layer of memory safety by deferring the actual call to free
and optionally filling the memory blob with a pattern ('wwwww...').
This is mostly thread-safe (requires thread-safe free functions).
This new type I called postponed is intended to store objects that
will be short lived. This is not thread safe as the life of the
objects added to this queue depends on the thread that adds to
the queue. The main intent is to introduce a new API for short-lived
strings.
@feature
Felipe Magno de Almeida
Derek Foreman
Chris Michael
Daniel Kolesa
Vitalii Vorobiov
Vyacheslav Reutskiy
Andrii Kroitor
Jean-Philippe Andre
Daniel Hirt