[EGIT] [core/enlightenment] master 02/02: unfocus focused+disabled widget always, not just when focus jump fails
discomfitor pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=b67381916e60ebc12d29a10f9a5cfebaa341169c
commit b67381916e60ebc12d29a10f9a5cfebaa341169c
Author: discomfitor michael.blumenkra...@gmail.com
Date: Sat Oct 26 09:53:15 2013 +0100
unfocus focused+disabled widget always, not just when focus jump fails
pretty sure this doesn't affect anything in e18, but it does break things
in a really hard to reproduce setting involving clicking/disabling/focusing
widgets simultaneously
---
src/bin/e_widget.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/bin/e_widget.c b/src/bin/e_widget.c
index eab7e69..ee8cc68 100644
--- a/src/bin/e_widget.c
+++ b/src/bin/e_widget.c
@@ -460,7 +460,8 @@ e_widget_disabled_set(Evas_Object *obj, int disabled)
if (!o) break;
parent = o;
}
-if (!e_widget_focus_jump(parent, 1))
+e_widget_focus_jump(parent, 1);
+if (sd-focused)
{
sd-focused = 0;
if (sd-focus_func) sd-focus_func(obj);
--
[EGIT] [core/enlightenment] master 01/02: sanitize widget disabled_set flag, only jump focus when disabling focused widget
discomfitor pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=b11305652d6cf66588ccb390da0354a1e800dbcf
commit b11305652d6cf66588ccb390da0354a1e800dbcf
Author: discomfitor michael.blumenkra...@gmail.com
Date: Sat Oct 26 09:52:43 2013 +0100
sanitize widget disabled_set flag, only jump focus when disabling focused
widget
---
src/bin/e_widget.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/bin/e_widget.c b/src/bin/e_widget.c
index 565207c..eab7e69 100644
--- a/src/bin/e_widget.c
+++ b/src/bin/e_widget.c
@@ -447,9 +447,9 @@ EAPI void
e_widget_disabled_set(Evas_Object *obj, int disabled)
{
API_ENTRY return;
- if (sd-disabled == disabled) return;
- sd-disabled = disabled;
- if (sd-focused)
+ if (sd-disabled == !!disabled) return;
+ sd-disabled = !!disabled;
+ if (sd-focused sd-disabled)
{
Evas_Object *o = NULL, *parent = NULL;
--
[EGIT] [core/efl] master 01/01: evas gl engine related - fix elm image example 01 (T182).
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=c4a45c75b15a3bcfb8bfd089a02cdaff3b7102f0
commit c4a45c75b15a3bcfb8bfd089a02cdaff3b7102f0
Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
Date: Sat Oct 26 21:09:17 2013 +0900
evas gl engine related - fix elm image example 01 (T182).
this fixes https://phab.enlightenment.org/T182 as it is an issue with a
surface alloc overwriting an already allocated surface entirely inside
the general software image infra.
---
src/lib/evas/common/evas_image_main.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/lib/evas/common/evas_image_main.c
b/src/lib/evas/common/evas_image_main.c
index 38aac78..b9d64ce 100644
--- a/src/lib/evas/common/evas_image_main.c
+++ b/src/lib/evas/common/evas_image_main.c
@@ -571,16 +571,18 @@ _evas_common_rgba_image_dirty(Image_Entry *ie_dst, const
Image_Entry *ie_src)
evas_common_rgba_image_scalecache_dirty((Image_Entry *)ie_src);
evas_common_rgba_image_scalecache_dirty(ie_dst);
evas_cache_image_load_data(src-cache_entry);
- if (_evas_common_rgba_image_surface_alloc(dst-cache_entry,
- src-cache_entry.w,
src-cache_entry.h))
+ if (!evas_cache_image_pixels(ie_dst))
{
+if (_evas_common_rgba_image_surface_alloc(dst-cache_entry,
+ src-cache_entry.w,
src-cache_entry.h))
+ {
#ifdef EVAS_CSERVE2
-// if (ie_src-data1) evas_cserve2_image_free((Image_Entry*) ie_src);
-if (ie_src-data1) ERR(Shouldn't reach this point since we are using
cache2.);
+ // if (ie_src-data1) evas_cserve2_image_free((Image_Entry*)
ie_src);
+ if (ie_src-data1) ERR(Shouldn't reach this point since we are
using cache2.);
#endif
-return 1;
+ return 1;
+ }
}
-
#ifdef EVAS_CSERVE2
// if (ie_src-data1) evas_cserve2_image_free((Image_Entry*) ie_src);
if (ie_src-data1) ERR(Shouldn't reach this point since we are using
cache2.);
--
Re: [E-devel] EFL 1.8 coming release
On Fri, Oct 25, 2013 at 9:27 AM, Leif Middelschulte leif.middelschu...@gmail.com wrote: Am 25.10.2013 um 10:35 schrieb Cedric BAIL cedric.b...@free.fr: Hello everyone, EFL and Elementary 1.8 have there todo list almost done by now. I think we are good to start the release process. So if nobody object by end of next week, on Sunday 3rd, we will enter on code freeze. As usual, only bug fixes, test code and limited API fix are allowed. Right now I am only aware of one major change that need to be done, fixing Ecore_Wayland.h exposing private structure. So if you have anything important, please share it here. I will go over phab and take of what I can. Time to finally roll 1.8 out ! Great new! Just to let you know tough: I’m trying to package efl (with default configuration) for Mac OS’ Homebrew package manager. So far no patches are necessary for efl. Yeah, amazing news, indeed! I'm gonna work on the Ecore_Wayland.h private structure, starting from Monday! I’ll update the status, once I’ve done it successfully. -- Leif -- Cedric BAIL -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Rafael Antognolli -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas cserve2
Hey, amazing work in here! Some comments follow: On Wed, Oct 23, 2013 at 11:45 PM, Jean-Philippe André j...@videolan.org wrote: Dear EFL developers, TL;DR I'd like to merge my work on cserve2 into EFL master soon. This is a commit-flood warning mail. I hope the lucky of you folks who attended EFL dev day 2013 had fun there. Also I hope this was a productive event and you got the opportunity to discuss various EFL-related topics. Amongst those, I trust Cedric made an awesome presentation about cserve2, and introduced the work I've put on top of what had already been done :-) Now is about time to merge this work into the master branch, as it's reached a state where it is (almost?) fast stable enough to be used to run E18. For those who forgot or could not attend, let me summarize what this is all about: Evas cserve2 is a caching mechanism for Evas images and font (glyphs) that is based on a client-server model. A program, evas_cserve2, runs as a server on the system, waits for commands on a UNIX socket, and loads image files, image data and font data in memory. The memory is then shared and exposed in virtual files in /dev/shm and all applications can access it. This means multiple apps will reuse the exact same resources in memory, and won't need to duplicate common elements such as font glyphs and theme image data. When I first started working on cserve2, it was in an experimentally working state. That is, it worked pretty well in some situations, but there were huge performance bottlenecks, that made it impractical to use in production. One of the main bottlenecks was the massive amount of IPC involved in just opening loading an image. (Example: client A sends a message to cserve2 to OPEN an image, then waits for cserve2 to answer. cserve2 sends a message to its slave to OPEN that image, receives a message from the slave when it's done, sends a message back to the client A, ... So far the data itself is still not even loaded, and client A will have to request the data in a second message to cserve2...) In particular, most scaling was done on the server and not on the client side, which means that lots of scaled images could be cached even when used only once. So, I worked on reducing unnecessary IPC and optimizing data loading, in two ways: - Reuse the scalecache logic for scaled images (cache only images that would otherwise hit the scalecache, scale on the fly all the rest) - Implement a shared indexing system, where cserve2 exposes its internal cache structure to all the clients. The clients can then scan the indexes (also stored in /dev/shm), bypass part of the heavy IPC and directly open the data. This works very well for images as they will not change at all after being fully loaded. Nice idea, I saw Cedric talking about it on the presentation, really good. BTW, do you keep reference for each client using a given image? How do you know when to drop an image, even if a client is still using it? And I assume you are not worried with security yet, as we were not yet when we first did it, but will have to work on this at some point, right? In terms of stability, I've also improved the following: - Support the GL engine (very basic support right now) - Support some exotic stuff (eg. animated Gif) - Allow cserve2 to crash without affecting clients (as long as the system restarts the server) Great stuff! The overall objective of cserve2 is to reduce memory usage at the system level, as applications will share more resources. Also, we can integrate in the future with E, so that the required resources are loaded ASAP when an app starts (predict what an app needs before even it has requested them). So there is a potential performance increase as well, on slower devices at least. I've been actually using it for a couple days and it's surprisingly quite stable ^^. I will fix bugs as they come [1]. The source code is available in my dev branch (rebased on top of master): https://git.enlightenment.org/core/efl.git/log/?h=devs/jpeg/cserve2 It's a LOT of commits, so out of question that I push them without previous notice discussion :-) As usual, if there's any bug left, blame Cedric. Good work man, would be great if I could make a review on this, but I am not sure that I'll be able to do it. Best regards, [1] I know (only) one bug right now, but sh, don't tell... Regards, Rafael Antognolli -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list
Re: [E-devel] Eolian meta-data parsing
json++ On Fri, Oct 25, 2013 at 5:01 AM, Cedric BAIL cedric.b...@free.fr wrote: Hello, On Tue, Oct 22, 2013 at 2:29 AM, daniel.za...@samsung.com daniel.za...@samsung.com wrote: I would like to discuss about a project that we are beginning just now. I presented it on EFL dev. day yesterday but I would like to share it here since it will imply all the EFL developers (yes, you) one day or another. It is called Eolian and was first aimed to facilitate addition of new Eo functions by auto-generating code. Then we noted that we can automatically generate language bindings too but it is not the goal of this discussion. The idea is that each Eo class is represented into a .eo file. These files are manually modified to add new functions, comments, callbacks... and parsed and the generation phase updates the C/H files. They contain descriptions of inherited classes, properties, methods, base classes implemented functions and callbacks. We thought about two formats: - a C-like format: [snip] - JSON format: [snip] So, until yesterday (the day I presented), I really thought we would go on the C (ok, C++) style but now that I saw some faces when I showed the C format and since I want to come back home safe, I prefer asking here. Thanks a lot for asking ! I am very pleased by the ongoing result and I am obviously going to vote for JSON also. -- Cedric BAIL -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Rafael Antognolli -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/elementary] master 01/01: Strip color profiles from new pngs
raster pushed a commit to branch master. http://git.enlightenment.org/core/elementary.git/commit/?id=45d0260763f5c12dd740cf53609e055163e51094 commit 45d0260763f5c12dd740cf53609e055163e51094 Author: Doug Newgard scimmi...@outlook.com Date: Sat Oct 26 23:48:55 2013 +0900 Strip color profiles from new pngs Summary: I stripped these in elementary previously, but not in the dark theme repo. When they got copied over, the embedded profiles are back. This strips them again as previously discussed. Reviewers: raster Differential Revision: https://phab.enlightenment.org/D269 --- data/themes/img/O/icon_favorites.png | Bin 12356 - 10241 bytes data/themes/img/O/icon_performance.png | Bin 19926 - 20337 bytes data/themes/img/O/randr_icon_on.png | Bin 3016 - 474 bytes data/themes/img/emo-angry-shout.png | Bin 8717 - 6079 bytes data/themes/img/emo-angry.png| Bin 8959 - 6321 bytes data/themes/img/emo-crazy-laugh.png | Bin 9225 - 6587 bytes data/themes/img/emo-evil-laugh.png | Bin 9092 - 6454 bytes data/themes/img/emo-evil.png | Bin 8991 - 6353 bytes data/themes/img/emo-goggle-smile.png | Bin 9670 - 7032 bytes data/themes/img/emo-grumpy-smile.png | Bin 8587 - 5949 bytes data/themes/img/emo-grumpy.png | Bin 8574 - 5936 bytes data/themes/img/emo-guilty-smile.png | Bin 9298 - 6660 bytes data/themes/img/emo-guilty.png | Bin 9151 - 6513 bytes data/themes/img/emo-haha.png | Bin 8993 - 6355 bytes data/themes/img/emo-half-smile.png | Bin 8667 - 6029 bytes data/themes/img/emo-happy-panting.png| Bin 9206 - 6568 bytes data/themes/img/emo-happy.png| Bin 8571 - 5933 bytes data/themes/img/emo-indifferent.png | Bin 8526 - 5888 bytes data/themes/img/emo-kiss.png | Bin 9214 - 6576 bytes data/themes/img/emo-knowing-grin.png | Bin 8481 - 5843 bytes data/themes/img/emo-laugh.png| Bin 9139 - 6501 bytes data/themes/img/emo-little-bit-sorry.png | Bin 8288 - 5650 bytes data/themes/img/emo-love-lots.png| Bin 9671 - 7033 bytes data/themes/img/emo-love.png | Bin 8981 - 6343 bytes data/themes/img/emo-minimal-smile.png| Bin 8896 - 6258 bytes data/themes/img/emo-not-happy.png| Bin 8885 - 6247 bytes data/themes/img/emo-not-impressed.png| Bin 8300 - 5662 bytes data/themes/img/emo-omg.png | Bin 8727 - 6089 bytes data/themes/img/emo-opensmile.png| Bin 9580 - 6942 bytes data/themes/img/emo-smile.png| Bin 9590 - 6952 bytes data/themes/img/emo-sorry.png| Bin 8638 - 6000 bytes data/themes/img/emo-squint-laugh.png | Bin 9103 - 6465 bytes data/themes/img/emo-surprised.png| Bin 8431 - 5793 bytes data/themes/img/emo-suspicious.png | Bin 8543 - 5905 bytes data/themes/img/emo-tongue-dangling.png | Bin 9005 - 6367 bytes data/themes/img/emo-tongue-poke.png | Bin 8974 - 6336 bytes data/themes/img/emo-uh.png | Bin 8641 - 6003 bytes data/themes/img/emo-unhappy.png | Bin 8686 - 6048 bytes data/themes/img/emo-very-sorry.png | Bin 9009 - 6371 bytes data/themes/img/emo-what.png | Bin 8410 - 5772 bytes data/themes/img/emo-wink.png | Bin 8749 - 6111 bytes data/themes/img/emo-worried.png | Bin 9116 - 6478 bytes data/themes/img/emo-wtf.png | Bin 8946 - 6308 bytes 43 files changed, 0 insertions(+), 0 deletions(-) diff --git a/data/themes/img/O/icon_favorites.png b/data/themes/img/O/icon_favorites.png index 208cc44..fad7df5 100644 Binary files a/data/themes/img/O/icon_favorites.png and b/data/themes/img/O/icon_favorites.png differ diff --git a/data/themes/img/O/icon_performance.png b/data/themes/img/O/icon_performance.png index 6e54bc5..da327dd 100644 Binary files a/data/themes/img/O/icon_performance.png and b/data/themes/img/O/icon_performance.png differ diff --git a/data/themes/img/O/randr_icon_on.png b/data/themes/img/O/randr_icon_on.png index 3859d42..d7324a6 100644 Binary files a/data/themes/img/O/randr_icon_on.png and b/data/themes/img/O/randr_icon_on.png differ diff --git a/data/themes/img/emo-angry-shout.png b/data/themes/img/emo-angry-shout.png index 25477c5..78103e3 100644 Binary files a/data/themes/img/emo-angry-shout.png and b/data/themes/img/emo-angry-shout.png differ diff --git a/data/themes/img/emo-angry.png b/data/themes/img/emo-angry.png index e151077..407136d 100644 Binary files a/data/themes/img/emo-angry.png and b/data/themes/img/emo-angry.png differ diff --git a/data/themes/img/emo-crazy-laugh.png b/data/themes/img/emo-crazy-laugh.png index 4e87937..a46cb7e 100644 Binary files a/data/themes/img/emo-crazy-laugh.png and b/data/themes/img/emo-crazy-laugh.png differ diff --git a/data/themes/img/emo-evil-laugh.png b/data/themes/img/emo-evil-laugh.png index 1a0ec3a..208a8bf 100644 Binary files a/data/themes/img/emo-evil-laugh.png and
[EGIT] [core/elementary] master 01/01: add another example to ignores
raster pushed a commit to branch master. http://git.enlightenment.org/core/elementary.git/commit/?id=88e58ba5ab18b260a499828c052acb084499a6f4 commit 88e58ba5ab18b260a499828c052acb084499a6f4 Author: Carsten Haitzler (Rasterman) ras...@rasterman.com Date: Sat Oct 26 23:51:10 2013 +0900 add another example to ignores --- src/examples/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/src/examples/.gitignore b/src/examples/.gitignore index 2789245..971ef8e 100644 --- a/src/examples/.gitignore +++ b/src/examples/.gitignore @@ -105,3 +105,4 @@ /prefs_example_03.epb /web_example_01 /web_example_02 +/track_example_01 --
[EGIT] [core/efl] master 01/01: PKGBUILD cleanup
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=b10243a5ea385e3456d7456f2765de3734677518
commit b10243a5ea385e3456d7456f2765de3734677518
Author: Doug Newgard scimmi...@outlook.com
Date: Sat Oct 26 23:56:25 2013 +0900
PKGBUILD cleanup
Summary:
Some of the files in the efl package (emotion engine and others IIRC)
were linked to libs in the efl_x11 package. This created a circular dep
requiring both to be installed. Should just be one package in that case.
LGPL2 is actually LGPL2.1.
Added 'custom' to license array to cover COPYING.SMALL.
There is no 'dbus-core' package, it's part of 'dbus' now.
Doesn't build without 'check' installed.
provides_efl doesn't work, changed to just provides.
Got rid of tabs in depends and provides, replaced with spaces.
No need to add default 'strip', 'docs', and 'zipman' options, if someone
want to override them, there's no reason to stop them.
buildflags doesn't work as a variable, added them to CFLAGS and CXXFLAGS
manually. -O2 and -g are already included by default, if someone wants to
change them on their system, there's no reason to override them.
Add install script to update mime database.
Change shebang on eina-bench-cmp so it runs with python2, python is 3 on
Arch.
make dist doesn't tar Makefile, so we need to check that it exists before
running make clean distclean. Otherwise the build just fails.
Building of docs should be done in the build function.
Quoted all uses of $pkgdir and $srcdir
Each package function gets it's own $pkgdir, so rm-ing them at the
beginning of the function isn't needed.
Use cp -a instead of cp -r to make sure permissions are preserved.
Set correct pkgdesc, arch, license, depends, provides, and install for the
doc package.
Reviewers: raster
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D240
---
Makefile.am | 3 +-
pkgbuild/PKGBUILD.in | 107 ++-
pkgbuild/efl.install | 16
3 files changed, 65 insertions(+), 61 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 8a33250..161a091 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -107,7 +107,8 @@ old/README.ethumb \
old/README.evas \
old/README.evil \
spec/efl.spec \
-pkgbuild/PKGBUILD
+pkgbuild/PKGBUILD \
+pkgbuild/efl.install
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA =
diff --git a/pkgbuild/PKGBUILD.in b/pkgbuild/PKGBUILD.in
index 63ed745..d7c7a8b 100644
--- a/pkgbuild/PKGBUILD.in
+++ b/pkgbuild/PKGBUILD.in
@@ -1,35 +1,45 @@
# Maintainer: Enlightenment Developers enlightenment-de...@enlightenment.org
-pkgname=('efl' 'efl_doc' 'efl_x11')
+pkgname=('efl' 'efl_doc')
pkgver=@VERSION@
pkgrel=1
pkgdesc=Enlightenment Foundation Libraries - GIT development snapshot (Ecore,
Eldbus, Edje, Eet, Eeze, Efreet, Eina, Eio, Embryo, Emotion, Eo, Ephysics,
Ethumb, Evas)
arch=('i686' 'x86_64' 'arm')
url=http://www.enlightenment.org;
-license=('BSD' 'LGPL2' 'GPL2')
-makedepends=('doxygen')
+license=('BSD' 'LGPL2.1' 'GPL2' 'custom')
+makedepends=('doxygen' 'check')
depends=('bullet' 'libpng' 'libjpeg-turbo' 'gstreamer0.10'
- 'gstreamer0.10-base' 'gstreamer0.10-good'
-'gstreamer0.10-bad' 'gstreamer0.10-ugly' 'gstreamer0.10-ffmpeg'
-'zlib' 'lua' 'libtiff' 'openssl' 'util-linux' 'curl' 'dbus-core'
-'glibc' 'fontconfig' 'freetype2' 'fribidi' 'libpulse'
-'libsndfile' 'systemd' 'libx11' 'libxau' 'libxcomposite'
-'libxdamage' 'libxdmcp' 'libxext' 'libxfixes' 'libxinerama'
-'libxi' 'libxrandr' 'libxrender' 'libxss' 'libxtst'
-'libxcursor' 'libxp' 'libgl' 'giflib' 'libwebp' 'harfbuzz')
-provides_efl=(ecore=$pkgver eldbus=$pkgver edje=$pkgver
- eet=$pkgver eeze=$pkgver efreet=$pkgver
- eina=$pkgver eio=$pkgver embryo=$pkgver emotion=$pkgver
- ephysics=$pkgver ethumb=$pkgver evas=$pkgver)
-options=('strip' 'docs' 'zipman' '!libtool' 'debug')
-buildflags=-O2 -g -fvisibility=hidden -fomit-frame-pointer
+ 'gstreamer0.10-base' 'gstreamer0.10-good'
+ 'gstreamer0.10-bad' 'gstreamer0.10-ugly' 'gstreamer0.10-ffmpeg'
+ 'zlib' 'lua' 'libtiff' 'openssl' 'util-linux' 'curl' 'dbus'
+ 'glibc' 'fontconfig' 'freetype2' 'fribidi' 'libpulse'
+ 'libsndfile' 'systemd' 'libx11' 'libxau' 'libxcomposite'
+ 'libxdamage' 'libxdmcp' 'libxext' 'libxfixes' 'libxinerama'
+ 'libxi' 'libxrandr' 'libxrender' 'libxss' 'libxtst'
+ 'libxcursor' 'libxp' 'libgl' 'giflib' 'libwebp' 'harfbuzz')
+provides=(ecore=$pkgver eldbus=$pkgver edje=$pkgver
+ eet=$pkgver eeze=$pkgver efreet=$pkgver
+ eina=$pkgver eio=$pkgver embryo=$pkgver emotion=$pkgver
+ ephysics=$pkgver ethumb=$pkgver evas=$pkgver)
+conflicts=('ecore' 'edje' 'eet' 'eeze' 'efreet' 'eina' 'eio' 'embryo'
Re: [E-devel] [EGIT] [core/efl] master 03/07: If the init count is = 1, then we want to iterate (ecore_imf wayland module adds an extra init).
Hey dh, On Tue, Jul 23, 2013 at 3:15 AM, Chris Michael - Enlightenment Git no-re...@enlightenment.org wrote: devilhorns pushed a commit to branch master. commit cc596a358851e06f162dd3e8f75938c4b6395584 Author: Chris Michael cp.mich...@samsung.com Date: Thu Jul 18 11:07:05 2013 +0100 If the init count is = 1, then we want to iterate (ecore_imf wayland module adds an extra init). Why do we need to do that? If ecore_wl_init returns 1, it means that it was initialized already, and nothing will happen inside of that function. Plus if we call wl_display_dispatch() when there's nothing to be dispatched, it will block until something else occurs. And this is what is going on with elm tests, when we click on a test button and it blocks until the mouse is moved, or a key is pressed, or whatever. I'm trying to understand why ecore_imf wayland module needs this, but if that's the case, we could maybe add this dispatch inside the module itself, instead of here, no? Fix some formatting Signed-off-by: Chris Michael cp.mich...@samsung.com --- src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c | 2 +- src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c index e8a4570..1d5ac49 100644 --- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c +++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c @@ -112,7 +112,7 @@ ecore_evas_wayland_egl_new_internal(const char *disp_name, unsigned int parent, ERR(Failed to initialize Ecore_Wayland); return NULL; } - else if (count == 1) + else if (count = 1) ecore_wl_display_iterate(); if (!(ee = calloc(1, sizeof(Ecore_Evas diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c index fae0b4f..048d2c7 100644 --- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c +++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c @@ -111,7 +111,7 @@ ecore_evas_wayland_shm_new_internal(const char *disp_name, unsigned int parent, ERR(Failed to initialize Ecore_Wayland); return NULL; } - else if (count == 1) + else if (count = 1) ecore_wl_display_iterate(); if (!(ee = calloc(1, sizeof(Ecore_Evas @@ -179,7 +179,8 @@ ecore_evas_wayland_shm_new_internal(const char *disp_name, unsigned int parent, wdata-parent = p; wdata-win = - ecore_wl_window_new(p, x, y, w + fw, h + fh, ECORE_WL_WINDOW_BUFFER_TYPE_SHM); + ecore_wl_window_new(p, x, y, w + fw, h + fh, + ECORE_WL_WINDOW_BUFFER_TYPE_SHM); ee-prop.window = wdata-win-id; ee-evas = evas_new(); -- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk -- Rafael Antognolli -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 03/07: If the init count is = 1, then we want to iterate (ecore_imf wayland module adds an extra init).
On Sat, Oct 26, 2013 at 3:13 PM, Rafael Antognolli antogno...@gmail.com wrote: Hey dh, On Tue, Jul 23, 2013 at 3:15 AM, Chris Michael - Enlightenment Git no-re...@enlightenment.org wrote: devilhorns pushed a commit to branch master. commit cc596a358851e06f162dd3e8f75938c4b6395584 Author: Chris Michael cp.mich...@samsung.com Date: Thu Jul 18 11:07:05 2013 +0100 If the init count is = 1, then we want to iterate (ecore_imf wayland module adds an extra init). Why do we need to do that? If ecore_wl_init returns 1, it means that it was initialized already, and nothing will happen inside of that function. Plus if we call wl_display_dispatch() when there's nothing to be dispatched, it will block until something else occurs. And this is what is going on with elm tests, when we click on a test button and it blocks until the mouse is moved, or a key is pressed, or whatever. I'm trying to understand why ecore_imf wayland module needs this, but if that's the case, we could maybe add this dispatch inside the module itself, instead of here, no? nvm, I just noticed that it's because of ecore_wl_registry_get and ecore_wl_globals_get. So, I think we need a better and more asynchronous way of init the wl backend. Maybe an Ecore event that, when emitted, we are sure that everything that depends dispatch things was done already? And, in the case of someone calls those functions before the event being received, THEN we can block waiting for the dispatch being finished? That would be similar to what I did in ecore_wl_screen_size_get. I'll try to think about it carefully and see if I find a simple implementation. That would enable us to never block on init, and keep things that depend on the registry, global and display still working. And of course, remove this dispatch from the engine_new_internal code. Fix some formatting Signed-off-by: Chris Michael cp.mich...@samsung.com --- src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c | 2 +- src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c index e8a4570..1d5ac49 100644 --- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c +++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c @@ -112,7 +112,7 @@ ecore_evas_wayland_egl_new_internal(const char *disp_name, unsigned int parent, ERR(Failed to initialize Ecore_Wayland); return NULL; } - else if (count == 1) + else if (count = 1) ecore_wl_display_iterate(); if (!(ee = calloc(1, sizeof(Ecore_Evas diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c index fae0b4f..048d2c7 100644 --- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c +++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c @@ -111,7 +111,7 @@ ecore_evas_wayland_shm_new_internal(const char *disp_name, unsigned int parent, ERR(Failed to initialize Ecore_Wayland); return NULL; } - else if (count == 1) + else if (count = 1) ecore_wl_display_iterate(); if (!(ee = calloc(1, sizeof(Ecore_Evas @@ -179,7 +179,8 @@ ecore_evas_wayland_shm_new_internal(const char *disp_name, unsigned int parent, wdata-parent = p; wdata-win = - ecore_wl_window_new(p, x, y, w + fw, h + fh, ECORE_WL_WINDOW_BUFFER_TYPE_SHM); + ecore_wl_window_new(p, x, y, w + fw, h + fh, + ECORE_WL_WINDOW_BUFFER_TYPE_SHM); ee-prop.window = wdata-win-id; ee-evas = evas_new(); -- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk -- Rafael Antognolli -- Rafael Antognolli -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL 1.8 coming release
On 10/25/2013 07:05 PM, Cedric BAIL wrote: Hello everyone, EFL and Elementary 1.8 have there todo list almost done by now. I think we are good to start the release process. So if nobody object by end of next week, on Sunday 3rd, we will enter on code freeze. As usual, only bug fixes, test code and limited API fix are allowed. Right now I am only aware of one major change that need to be done, fixing Ecore_Wayland.h exposing private structure. So if you have anything important, please share it here. I will go over phab and take of what I can. Time to finally roll 1.8 out ! The following warning is treated as a Error on 64bit systems on Open Build Service [ 299s] gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../src/lib/efl -I../src/lib/efl -I.. -I../src/lib/edje -I../src/lib/edje -DPACKAGE_BIN_DIR=\/usr/bin\ -DPACKAGE_LIB_DIR=\/usr/lib64\ -DPACKAGE_DATA_DIR=\/usr/share/edje\ -DPACKAGE_BUILD_DIR=\`pwd`/..\ -DPACKAGE_SRC_DIR=\`pwd`/..\ -Wall -Wextra -Wpointer-arith -Wno-missing-field-initializers -fvisibility=hidden -fdata-sections -ffunction-sections -I../src/lib/edje -I../src/lib/edje -I../src/lib/ephysics -I../src/lib/ephysics -I../src/lib/eio -I../src/lib/eio -I../src/lib/embryo -I../src/lib/embryo -I../src/lib/ecore_imf_evas -I../src/lib/ecore_imf_evas -I../src/lib/ecore_imf -I../src/lib/ecore_imf -I../src/lib/ecore_input -I../src/lib/ecore_input -I../src/lib/ecore_file -I../src/lib/ecore_file -I../src/lib/ecore_evas -I../src/lib/ecore_evas -I../src/lib/ecore -I../src/lib/ecore -I../src/lib/evas -I../src/lib/evas -I../src/lib/eet -I../src/lib/eet -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -DEFL_ EDJE_BUILD=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wno-address -c -o bin/edje/bin_edje_edje_cc-edje_cc_parse.o `test -f 'bin/edje/edje_cc_parse.c' || echo './'`bin/edje/edje_cc_parse.c [ 299s] bin/edje/edje_cc_out.c: In function '_part_lookup_key_pc_hash': [ 299s] bin/edje/edje_cc_out.c:250:9: warning: passing argument 1 of 'eina_hash_int64' makes pointer from integer without a cast [enabled by default] [ 299s] In file included from ../src/lib/eina/eina_hash.h:1034:0, [ 299s] from ../src/lib/eina/Eina.h:227, [ 299s] from ../src/lib/evas/Evas.h:251, [ 299s] from ../src/lib/ecore_evas/Ecore_Evas.h:4, [ 299s] from bin/edje/edje_cc_out.c:19: [ 299s] ../src/lib/eina/eina_inline_hash.x:75:1: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int' [ 299s] bin/edje/edje_cc_out.c:251:11: warning: passing argument 1 of 'eina_hash_int64' makes pointer from integer without a cast [enabled by default] [ 299s] In file included from ../src/lib/eina/eina_hash.h:1034:0, [ 299s] from ../src/lib/eina/Eina.h:227, [ 299s] from ../src/lib/evas/Evas.h:251, [ 299s] from ../src/lib/ecore_evas/Ecore_Evas.h:4, [ 299s] from bin/edje/edje_cc_out.c:19: [ 299s] ../src/lib/eina/eina_inline_hash.x:75:1: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int' Full Build log: download log file from here: https://build.opensuse.org/package/live_build_log/X11:Enlightenment:Nightly/efl/openSUSE_12.3/x86_64 Other then that we've had a package following git for a good 6 months, im using it on my laptop and it seems to work fine. Cheers Simon Lees -- Enlightenment maintainer on openSUSE -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
