Gcc 6 was spitting a nasty little compiler warning here:
src/bin/e_fm.c: In function ‘e_fm2_icon_geometry_get’:
src/bin/e_fm.c:2354:4: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
if (x) *x = 0; if (y) *y = 0; if (w) *w = 0; if (h) *h = 0;
^~
src/bin/e_fm.c:2354:19: note: ...this statement, but the
latter is misleadingly indented as if it is guarded by the ‘if’
if (x) *x = 0; if (y) *y = 0; if (w) *w = 0; if (h) *h = 0;
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
This adds compositor handling of DMABuf buffers. DMAbuf capabilities
are advertised for the drm back-ends, and DMAbuf buffers are handled
as native surfaces.
When running as a wayland compositor connected to another wayland
compositor, we don't want to advertise dmabuf capabilities if the
parent compositor doesn't support them.
If it does, we'll want to proxy dmabuf requests to it instead of handling
them ourselves.
Expose this as new bools in e_comp_wl.
This test has been pushed into e_comp_object_native_surface_set() and
will be done as appropriate.
Upcoming wayland DMAbuf buffers need native surfaces even if GL isn't
present.
This is supposed to be functionally equivalent, but is a little tricky to
prove.
The benefit of this is a simplification to the callers, which no longer
have to consider gl capabilities in the call, as that is now tested for
internally.
Until now it's been reasonable to consider these together as the
criteria have been similar. With the upcoming introduction of wayland
DMAbuf buffers, they diverge.
We don't need to test for GL in the wayland case because we don't
advertise GL capabilities to clients when we don't support it, so they
can't create GL buffers unless we can display them.
DMAbuf for wayland will complicate determining whether a pixmap can use
a native surface or not, so we add an API here to check this.
Note that this doesn't take compositor capabilities into account - for
example, X pixmaps need GL enabled to use native surfaces. This is
already tested elsewhere.
this function was adding the same client multiple times, failing to cleanup
windows effectively, and misusing the skiplist functionality of e_place functions
fix T3654
this guarantees a crash any time the default sink gets removed since it will
always re-set the about-to-be-deleted default sink as the default sink
fix T3277 probably
this means only lid/screen status affects intelligent suspending. it's
not what people expect and doesnt rely on ecore getting mains power
stuff right too.
no. perhaps you should see the
execvp("dbus-launch", dbus_argv);
code that auto re-launches using dbus-launch if a dbus session bus etc.
is not "found" (env vars). if your issue is that its mis-detecting the
fix the detection, but this coe went into e_start like a decade ago or
so... and it's worked every since in x11 mode and gave us a dbus
session. it SHOULD work for wayland too. don't make instructions
change and become more complex if not absoultely needed. :)
When in the config dialog a new set of layouts is created, this set has
to be told to the displayserver. Like at the startup of e, so calling
e_xkb_reconfig().
fix T3072
Add support for systemd detection/inclusion. Update file lists.
Update/remove outdated build dependencies. Remove unnecessary .la
files from final packages.
activating the window_move action doesn't require the client to successfully
be shown, and failing this check would cause the window_move action to be
deleted until the next restart
this was breaking internal windows when more than one was open, and
especially if any were open which had a parent-child relationship, by
using the same id for all internal window pixmaps
Mike Blumenkrantz
Chris Michael
maxerba
Davide Andreoli
Derek Foreman
Carsten Haitzler
Marcel Hollerbach
Michael Jennings