EWS is a new Ecor_Evas engine that builds on top of other engines. It
will create a backing store Ecore_Evas and ecore_evas_ews_new()
windows are created in it as images, but transparent to the outside
users (similar to buffer's ecore_evas_object_image_new()).
It provides a basic windowing system, with a known background object
that can be changed to your pleasure, and issue Ecore_Events to notify
of new windows and changes like movement, etc. Then you can write a
simple window manager based on it. (See example, Elementary will
contain one as well).
Backing store is determined by your best engine (as in
ecore_evas_new()) or specified with ecore_evas_ews_engine_set() or
environment variable $ECORE_EVAS_EWS (format:
engine-name❌y:w:h:options). The size can be set with
ecore_evas_ews_setup().
SVN revision: 63848
Subject: [E-devel] XRender engine causes ecore build failure
while building ecore. The problem is that this engine was removed from evas
but not yet completely from ecore. I was on IRC with Vincent Torri (vtorri)
and Daniel Juyung Seo (SeoZ) and the consensus was to remove the code for the
XRender engines, both the Xlib and XCB versions.
There is a switch over the different engine types, where there are still a few
places left where XRender is handled, grep for "xrender" or "XRENDER" and you
will find them. The question is whether to just return NULL in order to signal
that this engine is not supported or to remove the whole thing. The latter
could break binary compatibility, therefore I left those stubs in.
SVN revision: 60502
Quartz is the name of the graphic library
Cocoa is the Objective C API to build applications
I can't test this so maybe I have forgotten some
modifications to do. Please report any problem in
that thread
SVN revision: 47339
* better check of Cocoa.h
Patch by Andrew Wiliams and myself.
As I had to modify the patch so that it compiles on linux, could
the Mac OS X users check if the compilation is fine ?
Next steps:
* change the name 'quartz' to 'cocoa'
* add in ecore_cocoa all the needed functions to be used in ecore_evas
(windows management, cursors, events, etc...) so that ecore_evas_cocoa.c
does not contain objective c code anymore
SVN revision: 39915
between all ecore graphic engine to ease porting of application and reduce the amount of
specific code per engine. This patch does just that.
All your application should continu to work has previously, if it's not the case
please report any new behaviour regarding mouse and keyboard.
SVN revision: 39505
* fix requirements
* fix configuration on mac os x (problem with automake 1.9) and
add missing values/macro for quartz support
* small typo in ecore_evas_win32 api
* use m4 api in m4 files
SVN revision: 39471
* remove useless _DEPENDENCIES variables
* remove useless files in EXTRA_DIST
* use -no-undefied directly
* add some flags when the host is windows ce
make distcheck succeeds on my computer
next step will be to fix the horrible mess in Ecore.h and ecore_private.h
SVN revision: 37406
We usually want to create an Ecore_Evas and attach an object to it, be
it the background, your smart object that will manage the scene (ie:
edje) and this is replicated everywhere. Not anymore!
ecore_evas_new() and ecore_evas_object_associate() will behave much
like regular toolkits "window-new()" and "window-main-child-add()",
actually it was based on elm_win.c and hopefully we can remove that,
or most of that code and replace with this helper.
I'll add an Evas smart object to handle stacks of objects, that is, it
will be a clipped smart object that on resize it will resize every
child to the same size. This means we can associate this stack object
and add a background and then your stuff on top of it.
SVN revision: 37010
* use non deprecated version of AC_INIT and AM_INIT_AUTOMAKE
and check the required minimal versions.
* add bzipped distribution archive
* add AC_LIBTOOL_WIN32_DLL
* forbid libtool to check fortran
* compute libtool versioning from the version of the package
* pass the directories based on ${prefix} to the preoprocessor
with the -D option
* replace INCLUDES, wich is deprecated since 2001 by AM_CPPFLAGS
* remove useless -L flags in *_la_LDFLAGS
SVN revision: 32338
* The XCB backend is disabled by default during the
configuration. To enable it, add --enable-ecore-x-xcb. See the
messages that configure displays when it finishes.
* The way XCB is detected, and used in src/lib/ecore_x/Makefile.am
should be improved
* Any program that uses ecore_evas does not need to be modified.
Any program that uses ecore_x may need some changes. That is,
adding some functions (_prefetch and _fetch ones). No other
change is needed. See the documention of any _get functions, as
these are the ones that need those functions.
* There are some missing parts, especially everything that involves
the keyboard, as porting Xlib functions related to strings (utf8
stuff, XKeysymToString, etc...) is an horror. So keyboard events
are not working yet.
* I tried to write as much documentation as I could. But there is
certainly some missing doc here and there.
there are certainly other things that I have forgotten.
Improvements of that backend:
* the creation of an ecore_evas is faster. Especially when done over
an ssh connection (on my computer, 7-10s with Xlib, 1.5s with XCB,
over an ssh)
* A Window Manager should be more responsive. But it's not tomorrow
that e17 will use it :)
Have fun !
SVN revision: 29500
a module.
* Only do tests related to a module, if the module is to be built
* use AC_PATH_GENERIC
* Formatting
* Remove som weird AC_SUBST, why were they there?
SVN revision: 16543
to do ssl and al fo ecorE_evas stuff
BUt ecore_* may not be BUILT with that support
so the api stub exists
but it may just return NULL. theres calls to query for support here.
SVN revision: 11957
Gustavo Sverzut Barbieri
Christopher Michael
Ulrich Eckhardt
Cedric BAIL
Eduardo de Barros Lima
Carsten Haitzler
Vincent Torri
Sebastian Dransfeld
Lars Munch
doursse
sebastid
tsauerbeck