Summary:
elocation should be included before elementary otherwise 'make install'
will fail on clean instalation
Test Plan: make uninstall && make install
Reviewers: raster, tasn, stefan_schmidt, cedric
Reviewed By: cedric
Subscribers: reutskiy.v.v, jpeg
Differential Revision: https://phab.enlightenment.org/D3832
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Slider can have two indicators if enabled and user can select
range values.
phab: https://phab.enlightenment.org/D3822
Test Plan: elementary_test -to slider
@feature
Change-Id: If4ca74de6f5a94531ebd21750d52704b2b02afee
The vlc vout display module adds key and mouse event support. It improves
performances since a video filter is not needed anymore to scale the image, and
direct rendering with vlc avcodec module is now possible (less memcpy).
This:
1. opens a file
2. maps its data and vaguely verifies it
3. writes data to it
4. writes data to it with a GRY8 map
5. verifies that the final image has all the proper pixels
1. unsigned char* as a return type was not even compatible
with the default colorspace (ARGB: 32 bits).
2. Change all unsigned to int for... uh... simplicity
unsigned is more correct than int for things like width,
size or stride, but in fact having both ints (x,y) and unsigned
ints makes the code more complex.
This is a matter of personal taste.
Those and many more will be required for proper map/unmap support.
There will be problems with planar formats:
YUV, RGB565_A5P, ETC1_ALPHA
The quick solution to this problem is to not support region
conversions, only full-image (so we can assume the location of
the various planes in memory).
This will be properly implemented by the subclasses. In particular,
map/unmap will be used where it makes sense, and data_get/set will
be limited to Efl.Canvas.Image and Surface.
A small hack to the toolchain allows us to generate enums with eolian
for use by Eet and Emile (internal or otherwise non-eo libraries).
Thanks to how BUILT_SOURCES works, the eo.h files required by Emile
will be generated before they are used.
This adds a partial dependency on eo for eet and emile:
- package dependency
- include dependency
There is no library link dependency.
An otherwise good looking macro triggers a warning with clang,
because of self comparison of constants (always true or always
false). Let's just silence the warning in this specific spot
with a pragma.
Summary:
Support hexadecimal color code in EDC.
Four types of color code are acceptable.
All values below mean 'Red'. (255 0 0 255)
color: "#F00";
color: "#F00F";
color: "#FF0000";
color: "#FF0000FF";
Color code tables are usually provided with hexadecimal numbers.
Supporting hexadecimal color code will allow developers to skip
manual conversion hex to decimal.
Test Plan: Test case will provided with seperated commit.
Reviewers: cedric, jpeg, raster
Reviewed By: raster
Subscribers: raster
Differential Revision: https://phab.enlightenment.org/D3831
several draw funcs keep a static Cutout_Rect *rects = NULL; variable
to cache cutout rects to avoid re-allocating them a lot etc. this is
fast and handy but we may use these from multiple threads. thats bad
.... mmmkay. so this fixes it the dirty way - makes them thread local.
:)
this fixes T3348 - the crash mentioned by @zmike
@fix
so there was/is a case where when an elm window is resized from
outside, it will happen to use the last known size (maybe old) and end
up requesting a resize to that size again itself. it basically
triggers its own resize request as a result of resize events. this
fixes that and stops the loop
@fix
so i had a separate flat theme i was working on but i just can't keep
up with changes so i'm just putting in some of the nicest bits here
slowly like nicer shadows.
@feat
after elm merge build broke with things like this enabled. this fixes
that.
i'd like to bring up one issue here. ecore_drm is not a good
abstractionlayer. it requires libdrm and other headers from system and
it should have abstracted things so the system libdrm is hidden/not
needed for build (or even perhaps at runtime and this could be rolled
into ecore_drm). this is how ecore_x is... and ecore_fb etc.
This make elementary break the modularity of the underlying layer. I haven't looked
at what is going on here, but basically if you have a wayland, a drm, whatever backend
turned on. You need elementary to be link against that ecore_* directly. This means
we are lacking in abstraction in Ecore_Evas and are dlopening to much library at
startup. This needs to be improved in the future.
I am guessing this is related to maybe DnD and C&P.
These binaries do not need the libtool library flags. This could actually lead
to problems. We already got a warning for one:
libtool: warning: '-version-info' is ignored for programs