Summary: this backend code was for selecting XCB over Xlib. Now XCB is removed, this code is useless
Reviewers: raster
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12299
Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
EAPI is the only solution that worked for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Reviewers: vtorri, jptiz, woohyun, lucas, SPAM-smith78899
Reviewed By: vtorri, SPAM-smith78899
Subscribers: SPAM-smith78899, raster, SPAM-cabanacatalogs, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12228
Summary:
since the existance of seleciton manager, the converter callbacks from
ecore_x are expecting custom struct pointers. However, enlightenment
never updated to use the elm dnd API for client side usages. Which
results in the fact that sometimes, when a client sents Notify, and
e_dnd is active, that this converter is executed with the wrong data.
With this commit the data passed in is ensured to have the correct magic
number. The proper solution for this would either be registering the
correct converters in enlightenment, or update to elm_drag. However,
since the continues cried river over the last 5 days has raised enough
hydro power to add these changes. This leaves us with just one question:
How was it possible to generate so many messages about a problem that
can be solved in a fraction of charaters that have been written?
fixes <a-issue-that-was-never-created>
Depends on D11700
Reviewers: zmike, stefan_schmidt, raster
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11701
Summary:
this is needed in order to tell the API user that this is not going to
be completed.
Depends on D11699
Reviewers: zmike, raster, stefan_schmidt
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11700
Summary:
ecore_x_dnd_send_status can be used to indicate if a item can be dropped
on a client or not. However, we should only indicate that this can be
dropped, if there is a object we signaled that a drop is in.
Long story short: there is no assertion that after indicating that
things can be dropped, that a notify for the data is sent. A drag
implementation should always listen to a mouse up event, and abort the
drag if no further operations are sent.
Depends on D11698
Reviewers: zmike, stefan_schmidt, raster
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11699
Summary:
this is needed in order to return the data the same way the legacy impl
did. This however has the annoying sideeffect that ecore_evas_x now
depends on efreet, and we had to change the build order.
Depends on D11696
Reviewers: zmike, stefan_schmidt, raster
Reviewed By: zmike
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11697
the structure "!strcmp(X, "foo", strlen("foo"))" is equal to
"eina_has_prefix(X, "foo")", and the later is nicer to read, hence this
replaces it.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11620
I thought that i explicitly tested this. However, it seems i was wrong,
this way now this is handled correctly, and the image is stored and
coverted to a path.
With this you can now copy images from chromium and firefox to elm apps.
The change in elm_entry reverts parts of the rewrite of the elm
handling, as initially every path came *without* "file://" in front, so
we have to maintain that.
fixes T8625
enlightenment does not use the elm dnd operation implementations.
Therefore we have to ensure that we only handle these operations here,
when ecore_evas dnd API is used.
Some methods were missing the "Drag" or "Selection" namespaces or the _Cb suffix.
Depends on D11219
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11426
Including Eina.Content
And a typo/bugfix in ecore_evas_x.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11204
Seats are not implemented, if there is a type mismatch promises are
going to be rejected. Most of this code is copied over from
selection_manager.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11195
The idea of copy and paste here is:
- The user specifies the content he wants to have in the selection
buffer with a Eina_Content, these content pointer ownerships are
passed to the called. Internally ecore_evas code will memorieze the
pointer, and pass on function callbacks to the modules, which then do
not have to deal with the ownership.
- In case the module does not specify these APIs, the callback
implementation will be called, which only works for cnp *not* dnd.
- Action and mime types are handled as strings, which allows way better
custom organisations.
(The docs needs improvement)
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11192
Summary:
this attempts to monitor the _NET_SUPPORTING_WM_CHECK atom to verify whether
a wm exists, and bypasses waiting for a configure event from a nonexistent wm
if the screen is not currently managed
fix T7838
Depends on D10014
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: devilhorns, thierry1970, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7838
Differential Revision: https://phab.enlightenment.org/D9900
this has been optional and unused by e for a very long time ot try
sync front-buffered software rendering with the wm/compositor. we may
as well remove the bloat that is here that is unused... it's been
inactive for many years anyway.
Coverity reports, and reading the code confirms, that the variable
'out' has already been freed (or is NULL) when reaching this line of
execution.
Fixes CID1382851
@fix
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
Summary:
this is more or less a dead project, having not been actively developed
in over 2 years and instead forcing people to expend more time and energy
to keep it compiling across refactors
fix T7227
Reviewers: stefan_schmidt, Hermet, ManMower, devilhorns
Reviewed By: Hermet, devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7227
Differential Revision: https://phab.enlightenment.org/D6878
Summary:
draw_block should only be unset if the event is triggered by the wm
or the window is an override, otherwise it prematurely begins rendering
the window at a size which may or may not be accurate
ref T7008
Reviewers: devilhorns, ManMower
Reviewed By: ManMower
Subscribers: ManMower, cedric, #reviewers, #committers
Tags: #efl_display_system
Maniphest Tasks: T7008
Differential Revision: https://phab.enlightenment.org/D6793
Summary:
drawing a non-override window before receiving a configure event results
in an unsized window, breaking spec. it also prevents ecore-evas resize
callbacks from triggering, yielding undefined returns from functions which
attempt to get the geometry of the ecore-evas
this patch improves upon the previous version by handling the case of windows
which are created with the correct initial size, bypassing an initial configure
event
there is still a lot of work to be done in this engine to improve/consolidate
resize-related code and ensure protocol correctness
ref T7008
fix T6907
Reviewers: devilhorns, ManMower
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7008, T6907
Differential Revision: https://phab.enlightenment.org/D6275
This reverts commit 7b80038fa7.
JackDanielz asked nicely, but this hasn't been reverted. As this
totally breaks enlightenment (it's black) and this happens on
everythng I've tested (1 laptop, desktop and Xephyr) I'm calling this
patch a dud.
Now... what kind of review is going on here? This hasn't been tested.
What kind of review doesn't build + run things?
for the reasons of poor review and massive horribler fully complete
desktop like breakage ... this gets reverted as master should not be
broken like this.
Summary:
drawing a non-override window before receiving a configure event results
in an unsized window, breaking spec. it also prevents ecore-evas resize
callbacks from triggering, yielding undefined returns from functions which
attempt to get the geometry of the ecore-evas
fix T6907
Reviewers: cedric, raster
Reviewed By: cedric
Subscribers: #committers, vtorri
Tags: #efl
Maniphest Tasks: T6907
Differential Revision: https://phab.enlightenment.org/D6019
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>
I want to use this in other engines, but no other engine initializes this
properly, so draw_ok would be EINA_FALSE everywhere. This way draw_block
is EINA_FALSE after calloc in all engines that don't know about it.
ref T6834
Engines that provide their own tickers may need to be able to provide the
time of the last tick even if they weren't sending ticks to EFL at the
time.
This is a feature added during freeze as it's necessary to resolve a bug.
ref T5462
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
1. The word "class" is a pain point with many languages where
it's a keyword. Type is a little better. Also, the property
was already named "device_type" and not "device_class".
2. Remove Efl.Input.Device.Sub_Class
It's not used inside EFL upstream codebase, and unlikely to
be used anywhere else (even in Tizen).
Hopefully no one used the Efl_ enum types. So far only the Evas_
types should be in used.
Ref T5540
Marcel Hollerbach
Carsten Haitzler
Vincent Torri
Felipe Magno de Almeida
Xavi Artigas
Mike Blumenkrantz
Christopher Michael
Mike Blumenkrantz
Mike Blumenkrantz
Cedric Bail
Andy Williams
Derek Foreman
Jean-Philippe Andre
Jean Guyomarc'h