My previous patches have broken E Wayland internal windows, as
the compositor wants to create Server-Side Decorations[1] but
based on some mysterious heuristics, E will decide to show or
not SSD. It seems the surface geometry, window geometry,
input region and maybe opaque region need to all match. There
was a pixel difference in the theme which broke everything,
also CSD shadows must be turned off in that case.
This also fixes inputs as for some reason a mismatching input
region vs window geometry would break pointer move/up/down in
those internal windows.
[1] I believe this is not a great idea and E should never draw
any server-side decorations in Wayland. Wayland was supposed
to mean only CSD, no more SSD.
as soon as we report 'can_read' or 'can_write', stop monitoring the
events until the user executes the operation, which will clear these
flags and we resume monitoring.
Summary:
when scroller page is enabled and key is pressed,
scroller will move in page by page.
Test Plan: elementary_test -> scroller
Reviewers: woohyun, cedric, jaehwan, raster, Hermet
Subscribers: akanad, jpeg
Differential Revision: https://phab.enlightenment.org/D4425
If we let the user know he can read or write, stop monitoring
otherwise fd handler will constanly report of data to read/write until
its actually done, which would clear the kernel flag.
Since we use "can_read" and "can_write" for that, toggle the callback
connection that manages the actual Ecore_Fd_Handler monitor.
instead of always delete and recreate it, modify if it already exists
and only delete if it's not needed anymore.
This results in epoll_ctl() to modify an existing handle, instead of
add one.
Each client (Ecore_Ipc_Client) is very similar to the handle
configured by ecore_ipc_server_connect() (the dialer), except we do
not have events such as "connected" and "error", as well as we don't
delete the socket as it's owned by the server, instead we close it.
The UNIX socket is configured similarly to ecore_con, setting the same
masks and mode for directories.
Instead of adding a job to create the socket and call bind(), do it
straight from the serve() method, this allows the caller to set
umask(), permissions and so on.
Document this behavior in the class, since we can't extend the
method's documentation.
Use the new Efl.Net.Dialer classes to implement
ecore_con_server_connect() scenario.
Note that since Windows still doesn't provide any equivalent to
Efl.Net.Dialer.Unix, we keep the legacy code for it.
Using the ecore_ipc_server_example with -m/--single-message, if we
deleted the client from the callback it would find a dead "cl".
As the "cl" handle is removed from svr->clients before it's deleted,
it's safe to check if we have that handle in the list before
proceeding.
The new efl_net code won't compose any path own its own, allowing the
user to connect to non-EFL systems.
However we need a way to use the same path Ecore_Con_Server does, so
we can reach it. Then export and use ecore_con_local_path_new() to do
exactly that.
This method will force a read-write cycle and returns if it's fully
done or not. It may be used to force data to be written before a
handle is deleted (when one can't wait for the data to be written
asynchronously).
E Wayland internal windows are a special beast. Somehow all their
events are intercepted by a special input_obj... but never get
propagated back to the elm_win.
Major side-effect: you get 2 window decorations. I believe there is
some dark magic inside E that tries to figure out when to show
a decoration and this conflicts with CSD.
But hey, it's late so I want to "fix" this and figure out the details
later.