summaryrefslogtreecommitdiff
path: root/src/lib/ecore_evas/ecore_evas_private.h (follow)
AgeCommit message (Collapse)Author
2012-12-18ecore-evas: Async renderLeandro Pereira
SVN revision: 81283
2012-12-07efl: begin (still partial!) to make an uniform choice of engines ecore/evasGustavo Sverzut Barbieri
still lots to do, but some improvements: - ecore_evas does not inherit pkg-config from modules since modules are SO - renamed internal ecore evas define from SOFTWARE_BUFFER to BUFFER, to make consistent. SVN revision: 80473
2012-12-06ecore_evas: Removing warning about unused functionFlavio Vinicius Alvares Ceolin
Now the engines are modules, the checking for the engine is not done in the compile time anymore, so we're removing these checks. SVN revision: 80389
2012-12-05if you are going to use symbols implicitly from a module provided by aCarsten Haitzler
lib.. you have to EAPI them! SVN revision: 80283
2012-12-05ecore_evas: Make the engines loadable modulesFlavio Vinicius Alvares Ceolin
Implementing support for loadables modules. It makes the engines been loaded when they are needed. It not breakes the api, so each engine still has its own api. The implementation basically is: * Functions that creates Ecore_Evas, for example ecore_evas_software_x11_new, request to load its module and then get the module's function to create the Ecore_Evas. * The other functions such as \(.*\)_window_get from the Ecore_Evas its interface and then call the appropriate method. * As there is no unified interface to communicate with the engines (not break api problem), all interfaces were declared in ecore_evas_private.h * Now the data necessary for each module is not declared in the Ecore_Evas_Engine structure, instead of this, the struct has a void pointer that is used by the modules. * In this first moment engines as software_x11 and gl_x11 were put together in the same module, but obviously exporting all the things necessary. SVN revision: 80280
2012-12-05directfb says bye...Gustavo Sverzut Barbieri
After agreement in the mail list, core developers agree to remove this engine that was not being supported for a long time. Given that most operations Evas uses are not accelerated in DirectFB, or at least hardware that exclusively supports DirectFB, it's better for those people to just use Evas/Ecore software (buffer) rendering and expose DirectFB's framebuffer as destination surface. SVN revision: 80232
2012-12-05From: Gwanglim Lee <gl77.lee@samsung.com>Gwanglim Lee
Subject: Re: Re: Re: [E-devel] [RFC] Virtual desktop window profile I've attached 4th patch. May the 4th be with you. ecore patch has been merged with efl and all files are based on r80123. Thanks & Regards, Gwanglim ------- Original Message ------- Sender : Daniel Juyung Seo<seojuyung2@gmail.com> Date : 2012-12-04 01:55 (GMT+09:00) Title : Re: Re: [E-devel] [RFC] Virtual desktop window profile It looks ok to me. Sorry but can you re-generate the patch according to the recent ecore merge to efl single tree? Daniel Juyung Seo (SeoZ) On Thu, Nov 29, 2012 at 12:29 AM, Gwanglim Lee <gl77.lee@samsung.com> wrote: Dear Raster and Daniel Juyung Seo, I've attached 3rd patches and test_config according to your reviews. These are based on r79782. [elementary & ecore] 1. "profile,set" -> "profile,changed" - done 2. spaces after EINA_LIST_FOREACH - done 3. variable type - keep 4. author - done 5. removing deprecated marking in patch - done 6. add elm_win_available_profiles_get to test_config for the debugging purpose - done 7. check whether a given profile is present in an available profiles. otherwise window profile will be one of the item in available profiles. - newly added thing to the elm_win 8. merge with EO - done. :( Any comments would be appreciated. SVN revision: 80214
2012-12-02merge: add escape ecore, fix several bugsVincent Torri
SVN revision: 79995