Summary:
neon code is only needed to be included for the arm architecture.
so that this code modify automake configure files to support it.
Reviewers: Hermet
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7096
a cxx compiler is not required unless physics, poppler, or ddraw support are
enabled, so don't fail configure unless one of those cases is true
ref T2838
Differential Revision: https://phab.enlightenment.org/D6683
Summary:
current copy color function has problem sometime on a arm neon environment.
inline asm code makes crashing problem.
so that this patch replace the asm code with a function which is a part of pixman project.
Reviewers: cedric, Hermet
Subscribers: kimcinoo, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6922
the elementary MARKUP stuff requires ecore_cocoa to be linked to evas to
find the function. However, ecore_XXXXX things should stay unrelated to
evas in most cases. Thus this was not a good idea and created a circular
dependency, this is fixed now.
Differential Revision: https://phab.enlightenment.org/D6865
Summary:
For the actaul release this might be helpfull, however, we are in a
freeze, people are getting theire alpha releases, that might contain
bugs, its just makes the workflow of fixing faster if we can get and
see debugging output.
Reviewers: devilhorns, stefan_schmidt
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6548
Summary:
-Wno-shadow warnings disable a improper warning directive for C++, this is made because
it is common for people to use the same CFLAGS as CXXFLAGS, enabling, unadvertadly, the
smae warning for C and C++.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6821
this greatly improves build times by improving parallelizing, though it
does introduce more BUILT_SOURCES usage which causes builds with cxx
bindings to take significantly longer
fix T7157
ref T7154
Differential Revision: https://phab.enlightenment.org/D6633
Summary:
As Lua bindings don't work right now, it is pointless to waste
build time generating them. Elua itself on the other hand is
useful and should stay enabled.
This also does some preparation work for separate configure
switch for bindings after release, but for now keep configure
switches as they are.
Reviewers: zmike, stefan_schmidt
Subscribers: cedric, bu5hm4n, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6721
automake 1.16 changed the naming of object files:
- When subdir-objects is in effect, Automake will now construct
shorter object file names when no programs and libraries name
clashes are encountered. This should make the discouraged use of
'foo_SHORTNAME' unnecessary in many cases.
https://lists.gnu.org/archive/html/info-gnu/2018-02/msg00008.html
this requires that object-specific rules must be changed to match the new
naming scheme if newer automake is being used. the $am__api_version contains
the version string of the automake version used during autoreconf, so this
should be checked during configure time in order to generate the correct
makefile rule for that automake version
other similar rules should be changed in the same way
note that this conditional speculates on behavior of automake versions past
1.16, which are not yet released and thus may change, meaning that this issue may
reoccur in future automake versions
Differential Revision: https://phab.enlightenment.org/D6594
these are used in places other than quicklaunch and must be correctly
detected in order for functionality to be enabled
@fix
Differential Revision: https://phab.enlightenment.org/D6517
This reverts commit 7b4ff708dc.
This had a side effect of breaking the distcheck build (which I need for
the upcoming alpha today). I talked to Marcel and we agreed on reverting
this for now and come back with a fully working patch afterwards.
Summary:
the files that are generated are calling files that dont exist anymore.
This cannot work and is only eating time when building, disable this for
now. It can be reenabled late.
The api missing was removed in fc88037977.
Reviewers: devilhorns, ManMower
Reviewed By: ManMower
Subscribers: ManMower, cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6506
Summary:
using runtime directory in all cases for this is wrong, as ecore-con has a number
of fallback codepaths for the case where runtime directory is not set or not valid.
by using the same ecore-con function which ecore-ipc uses to generate the socket
string, the error message path should always be the same as the path which is
used by efreetd
extra linkage was required by efreet in order to use ecore-con functions, so
the internal lib variable in the build system was modified to provide this
@fix
fix T7045
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7045
Differential Revision: https://phab.enlightenment.org/D6425
Summary: If realpath program does not exist, then readlink program can be used.
Test Plan:
Execute configure and check the log "checking for realpath".
If realpath program does not exist, then "checking for readlink" log is also printed.
Reviewers: woohyun, lauromoura, devilhorns
Reviewed By: lauromoura
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6470
Since commit 7a7abb, LIBINPUT_EVENT_SWITCH_TOGGLE was introduced to
Elput, however this enum did not get released into libinput until 1.7
so we need to require updated libinput now in our configure.ac
@fix
Summary:
build with this disabled is just not working as the thread model of eo
falls apart. The threadmodel is required to have eo_id, as it decoded
the thread information in the eo_id, which is not working without eo_id.
This also fixes the testcases that have never been executed due to the
fact of the missing HAVE_EO_ID
fix T6610
Depends on D6327
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T6610
Differential Revision: https://phab.enlightenment.org/D6328
Summary:
this is part of the datadir distribution, it should not be in a different
directory than the rest of the datadir distribution
the gnu coding standards (https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
define 'datadir' as:
The directory for installing idiosyncratic read-only architecture-independent
data files for this program. This is usually the same place as ‘datarootdir’,
but we use the two separate variables so that you can move these program-specific
files without altering the location for Info files, man pages, etc.
This should normally be /usr/local/share, but write it as $(datarootdir).
(If you are using Autoconf, write it as ‘@datadir@’.)
The definition of ‘datadir’ is the same for all packages, so you should install your
data in a subdirectory thereof. Most packages install their data under $(datadir)/package-name/.
while this text has no clear requirement or suggestion for a corresponding
repository layout, projects typically employ a certain consistency in their
repository layout both for ease of maintenance and ease of learning for new
contributors.
this project has both a data/ directory, which contains the datadir distribution,
as well as the config/ directory, which also contains the datadir distribution.
this complicates matters both for active maintainers/developers who must
remember that the repository and build tree layouts have this exception,
and for new contributors who will initially be confused by this exception
other well-organized open source projects, such as wayland, have chosen to not
use a data/ directory. these projects have the datadir distribution in the base
directory of the repositor, which is a fine practice as it maintains consistency
for the project since all the files for the datadir distribution are in the same
directory.
by applying this patch, the project will move towards a more easily readable and
learnable layout. current and future developers will no longer need to wonder why
this directory is outside of the data/ directory, and anyone attempting to reference
these files from the source/build trees will be able to do so more easily
Reviewers: cedric, stefan_schmidt, raster
Reviewed By: stefan_schmidt, raster
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6013
While compat shims exist for systems outside linux to provide
both, these require extra linkage and we're currently not set
up for that, besides we have native kqueue impls where relevant
so it's probably best to just disable.
This reverts commit d764e0b279.
The whole idea of renaming the default theme is an "api break" even if
config is changed. and symlinks don't work on windows as a solution.
(well on ntfs only as only as administrator, so they don't exist).
modifying config for switch from default to dark also will break the
case where someone put ~/.elementary/themes/default.edj there and it just
is different to the system one and how their theme changes on them as
it switches to dark.
basically we can't rename a theme like this mid-flight in efl. default is
default and has to stay that name. it can change the look, but not the
name.
i think the apparent reasoning behind this is not a good one. the work on
flat is temporary. i don't think we will ever maintain multiple "default
themes" as its just far too much work.
we can maintain color SCHEMES which are just a list of colorclasses and
colors for them - that's separate to a theme and would override. right now
these things don't exist. we are not going to create a dark.edj and a
light.edj just to store differing default colorclass values. we should be
doing the above with colorclass "color palette/scheme/whatever" files
that override those named colorclasses globally on init.
so reverting because this is an api break and we shouldn't break api
unless there is really absolutely no other choice.
here the choice is to just temporarily work in a branch and modify
default and then merge the branch when done.
We have been using gz as a fallback for a long time. By now every system
unpacking the efl tarballs should be capable of using xz. Having only
one file will not onyl save space but also ease the release handling.
when run in a non-wayland environment, it's necessary to do some extra work
in order to guarantee that the keymap remains the same in the compositor as
in the xserver and to also guarantee that modifier states are accurately
applied even when the compositor is not actively focused
fix T6631
This reverts commit 2cea85db38.
Their was a typo that I made during cleanup of the patch before pushing that I didn't
notice broke some stuff. But also you may have an old efl_general.h in your elementary
directory that is now being picked instead of the one provided by the tree.
Revert "elementary: currently double declare elm_init/shutdown."
This reverts commit 44bb0c1848.
Revert "elementary: fix efl_ui_multibutton installed headers."
This reverts commit 32a213dc72.
Revert "elementary: introduce Efl_Ui.h."
This reverts commit df3d3f7334.
Revert "ecore: do not display error message on cancel."
This reverts commit 99654b7cd2.
Revert "efl: and don't forget to install the new dependencies."
This reverts commit 814ffb9b6b.
Revert "ecore: remove EFL_OBJECT_BETA as Efl_Core.h is for Efl new inerfaces."
This reverts commit 619d0f3cff.
Revert "ecore: move EAPI_MAIN from elementary to ecore."
This reverts commit e5d84da864.
as such commit e5d84da864 starts the
breaking. enlightenment, terminologya and other apps can't compile
against that efl anymore. 619d0f3cff
then makes this even worse with even more header errors and undefined
types. on top of this df3d3f7334 then
starts making elementary_test segfault when it runs. it wont even
start up.
asu such of these 7 commits in the first 4 (that are then relied on
later) 3 of these first 4 cause serious breakage. this simply is a
complete lack of testing changes, so i've rolled fl back to before
these things so it builds and works again and you can build against it.
PLEASE test these things. this looks ot me to be obviously a lack of
any testing... :(
as decided by unanimous vote, the community does not want builds to pause or
stop when various features are disabled. warnings for disabling features have
been left intact
ref V30
@feature
This reverts commit 7a98f617e9.
this commit breaks compiling things against efl badly. i'm on holiday
and haver only a mini screen and keyboard wwith me so any serious wok
in hunting these issues isn't going to be fun or easy. as this causes
bad build brreaks this is worth a revert IMHO. please re-submit wwhen
you've tested against efl by building things against it. also our
public headers just should not have such ifdefs/if's that change api
presented based on how efl is cnfigured. we expose the same api and
macros and types regardless of internal config.
Summary:
Realization of audio data playback through WASAPI (Windows Audio Session API).(minimal)
WASAPI model:
1. Find a playback device (in the default system)
2. Register the client on the playback device.
3. Create a playback format for audio data.
4. Initialize the client with the created format, and access mode, ....
5. Take the object-rendering from the client for play the data stream.
6. Play data stream
ecore_audio model:
1. create a object for play the data stream(out object)
2. create a object to receive the data stream(in object)
3. register in the out-object the in-object
4. play data stream
Necessary:
Realize the ecore_audio object to play the data stream using the WASAPI model.
How implemented:
1. The object ecore_audio_out_wasapi is implemented
2. object ecore_audio_out_wasapi - the object constructor is find a playback device (in the default system)(WASAPI)
3. _ecore_audio_out_wasapi_ecore_audio_out_input_attach - register in the out-object the in-object
3.1 Register the client on the playback device.(WASAPI)
3.2 Create a playback format for audio data.(WASAPI)
3.3 Initialize the client with the created format, and access mode, ....(WASAPI)
4. _write_cb - play data
4.1 Take the object-rendering from the client for play the data stream.(WASAPI)
4.2 Play data stream(WASAPI)
Reviewers: cedric, vtorri, raster, an.kroitor, NikaWhite, FurryMyad, rimmed, t.naumenko, Jaehyun, bowonryu
Reviewed By: vtorri, NikaWhite
Subscribers: artem.popov, cedric, jpeg
Tags: #windows
Differential Revision: https://phab.enlightenment.org/D5029
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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.
Wonki Kim
Mike Blumenkrantz
Chris Michael
Marcel Hollerbach
Stefan Schmidt
Felipe Magno de Almeida
Daniel Kolesa
Jaehyun Cho
Mike Blumenkrantz
Cedric BAIL
Daniel Kolesa
Carsten Haitzler
Stefan Schmidt
Vitor Sousa
Lauro Moura
Ivan Furs
Andre Lupa
Vincent Torri
Derek Foreman