I believe all of those APIs are in fact meant for widgets to use
themselves:
- on_focus
- on_show_region_hook
- focus_region
- focus_register
- focus_manager_factory
Ref T5363
I was told that the scrollable interface is being redesigned for EO.
This API definitely does not belong to the base Widget class, as it's
quite specific to item-based scrollable widgets, such as lists and
grids. Since Elm.Interface_Scrollable is itself being revamped, it is a
good place to move that EO API for now.
Ref T5363
1. Uniformize the API, which is now for internal use:
This uses the same enum as scroller "movement_block" instead
of 2 separate properties. Less APIs, more consistence.
2. Remove scroll_lock x/y from EO widget. I was told it is not going to
exist in the upcoming scrollable interface.
3. Remove scroll hold/freeze getters.
scroll hold/freeze push/pop are still there but it remains to be seen
how the EO scrollable interface will exploit them. Right now they are
full of bugs.
Ref T5363
This also includes the drag_child_lock APIs. This had nothing to do with
dragging beyond maybe the case where scrolling is done by thumbscroll
(ie. finger drag).
Note that the EAPI were called already scroll_lock, not drag_lock.
Ref T5363
restrict mapping /dev/zero to only eina files having a sigbus
reported. the mmap was before all our file access used eina_file i
think thus the raw mmap of it. now walk all eina files and find the
candidate and only then if it exists flag is as having a faulty i/o
backing and map the zerto pages then return, otherwise call abort.
more restricted mapping and perhaps a fix for not trapping non-efl
issues.
@fix
since we have a sigbusd handler that flags an eina file with io errors
it has to walk the file cache and every file... taking locks. if those
locks were taking already in the current thread the sighandler was
called in... we'd deadlock. since this basicallly never happens (when
do we see i/o errors really? not much)... we never saw this as it'd
also reauire this race condition to happen too. but it is a problem
waiting to happen. this fixes that by moving to recrusive locks.
@fix
Summary:
This is a very informative document but is much longer than it needs to
be. Tighten it up by condensing redundant information and expressing
the ideas more efficiently. Focus more on Evas and what it is than what
it isn't. Avoid explaining general graphics concepts like immediate
vs. retained, replacing with synopses. Switch from 2nd person to 3rd
person (i.e. don't say You/Your) to be less awkward, since we don't
really know why the reader is reading it. Simplify the compilation
directions; these are pretty standard, and most people won't be manually
linking to Evas anyway.
While this shortens the document considerably, it retains the
important key points, and makes it far more readable.
Reviewers: cedric
Reviewed By: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5130
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
evas_textgrid_cellrow_get() is supposed to return NULL if the row index
fed to the function is outside of the textgrid's range. It was instead
returning garbage pointer.
@fix
When running elementary_test with ELM_ENGINE='buffer', we got a crash.
The removal of PS3 backend patch didn't remove ELM_SOFTWARE_PSL1GHT and
didn't shift the _elm_engines indexes.
ELM_SOFTWARE_DDRAW stayed at the index 13 (value NULL) instead of moving
to index 12.
A strcmp with NULL occurred, leading to the crash.
@Cedric, I excuse you to not have run Exactness your code before pushing
:P
Text on path (textpath) allows application to make text follow a path.
The path can be a efl_gfx_path or a circle.
Thank hermet for initializing this work.
@feature
This function is meant to be used by the widgets themselves, or internal
features such as elm_access.
Also remove const tag: this function call is definitely modifying the
widget (panning around and all that).
Ref T5363
This fixes a case where an object is hidden before the first render.
When called from elementary. the visible intercept code would be called
before evas object's visible_set, bypassing the line setting visible_set
to true.
As a consequence the object would be visible even when explicitly
requested as hidden.
Thanks @JackDanielZ for the report!
This is also another protected and beta API. Meant to be overridden by
subclasses, but belongs to a still unstable API.
The difference between the internal legacy and the EO API is really bad.
Same as with activate (previous commit).
Ref T5363
Renamed to on_disabled_update.
Also passed in the new state of disabled. It's more convenient this way,
than having the subclasses call disabled_get.
Also simplify some code...
Ref T5363
Renamed to on_orientation_update
This internal / virtual function is in fact not overridden anywhere. Not
sure it is necessary to expose it in EO API?
Ref T5363
a nested compositor will have a mismatch between canvas seat id and
compositor seat id, so this attempts to perform matching based on the
order that they are listed, which should be identical
@fix
For now, do not use Evas_Canvas3D in multi output context, it won't work.
The update code for Evas_Canvas3D_Node might trigger rendering logic, which
is opposite to what the scene graph logic should do. It require to much
reshuffle around to handle that case at the moment. So I am just adding a
warning.
This backend has received no patch and maintenance from anyone who could
actually test it over the last few years. After talking with KaKaRoTo it
is best to remove it. If anyone want to take over its maintenance, you
are welcome to revert this patch.
Summary:
Widgets that don't have content like as genlist, gengrid.
They don't have geometry of content also.
So position of pan will be used when calculating postion to scroll.
Test Plan:
tested in elementary_test and check working properly.
this may be the problem when extern pan set on scrollable interface.
Reviewers: SanghyeonLee, cedric, felipealmeida, larry, bu5hm4n
Reviewed By: SanghyeonLee
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5127
Small patch to allow setting pointer acceleration profile (for
wayland) from within Enlightenment.
ref T4736
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to add a new API function which can be called from
Enlightenment in order to allow setting pointer acceleration speed.
ref T4736
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to add an API which can be called to set pointer
acceleration speed under Wayland.
ref T4736
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
The 'c->w' field gets manipulated for querying cutoffs of text with its
boundaries. Better to keep it a read-only field, to reduce confusion.
Also updated querying internal functions for better readability.
Summary: I had added some information about texture size limitations to Elm image API reference.
Test Plan: Doxygen Revision
Reviewers: raster, cedric, stefan, jpeg, Jaehyun_Cho
Reviewed By: raster
Differential Revision: https://phab.enlightenment.org/D5106
These helpers are similar to eina_value_X_new(), however do not
allocate the Eina_Value, rather return it.
These are useful when the value struct storage was already there but
needs to be initialized in a single line, like as stack variables or
when returning a value.
these utilities are very useful, but names became too long. Since they
do not conflict with anything else, shorten them.
Since they were available before as inline function, provide a macro
to rename them for old source that's compiled against newer library.