Re: [E-devel] E-MODULES-EXTRA migration to git
On Fri, 12 Jul 2013 18:20:07 -0300 Eduardo Lima (Etrunko) ebl...@gmail.com
said:
Can you try the attached patch and comment? I think it makes sense to
have the icon above the selection.
well i think it looks ok. just icons feel a bit big at the default 40px shelf
size. that's why i made it smaller to start with. also the taskbar now leaves
almsot no spacing/padding at the top/bottom... your offset of 2 1 is also
asymmetrical... :/ (part { name: sel_base - that one). try the attached one:
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
diff --git a/data/themes/edc/tasks.edc b/data/themes/edc/tasks.edc
index 1a31cfb0..044ad8a 100644
--- a/data/themes/edc/tasks.edc
+++ b/data/themes/edc/tasks.edc
@@ -46,8 +46,8 @@ group { name:e/modules/tasks/item;
part { name: sel_base; mouse_events: 0;
clip_to: sel_clip;
description { state: default 0.0;
-rel1.offset: 4 4;
-rel2.offset: -5 -5;
+rel1.offset: 3 3;
+rel2.offset: -4 -4;
image.normal: vgrad_med_dark.png;
fill.smooth: 0;
TILED_HORIZ(120)
@@ -178,14 +178,26 @@ group { name:e/modules/tasks/item;
color: 255 255 255 64;
}
}
+ part { name: bar; mouse_events: 0;
+ clip_to: sel_clip;
+ description { state: default 0.0;
+rel1.offset: -5 -10;
+rel1.relative: 0.0 1.0;
+rel1.to: sel_base;
+rel2.offset: 4 4;
+rel2.to: sel_base;
+image.normal: horizontal_separated_bar_glow.png;
+image.border: 7 7 7 7;
+fill.smooth: 0;
+fixed: 0 1;
+ }
+ }
part { name: e.swallow.icon; type: SWALLOW; mouse_events: 0;
clip_to: icon_clip;
description { state: default 0.0;
aspect: 1.0 1.0; aspect_preference: VERTICAL;
align: 0.0 0.5;
-rel1.offset: 4 4;
rel1.to: icon;
-rel2.offset: -5 -5;
rel2.to: icon;
color: 255 0 0 128;
}
@@ -206,20 +218,6 @@ group { name:e/modules/tasks/item;
color: 0 0 0 0;
}
}
- part { name: bar; mouse_events: 0;
- clip_to: sel_clip;
- description { state: default 0.0;
-rel1.offset: -5 -10;
-rel1.relative: 0.0 1.0;
-rel1.to: sel_base;
-rel2.offset: 4 4;
-rel2.to: sel_base;
-image.normal: horizontal_separated_bar_glow.png;
-image.border: 7 7 7 7;
-fill.smooth: 0;
-fixed: 0 1;
- }
- }
part { name: sel_shine; mouse_events: 0;
clip_to: sel_clip;
description { state: default 0.0;
--
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___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC][xdg-utils] Use enlightenment_open to open files in xdg-open
On Sat, 13 Jul 2013 19:50:27 +0400 Igor Murzov intergalactic.anonym...@gmail.com said: a read of that patch says to me that that looks good. :) submit it! The patch is for xdg-utils project. It makes various xdg-* scripts detect if enlightenment is running and use enlightenment_open in xdg-open. How to test the patch: 1. Clone xdg-utils repository from here: git://anongit.freedesktop.org/xdg/xdg-utils 2. Apply the patch. 3. Run ./configure 4! Update scripts from scripts/ directory with: $ cd scripts make scripts Without this step you won't get any changes for the xdg-* scripts! 5. Run make install Please test and give a response. If the patch is good i'll send it to xdg-utils project. -- Igor -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Introduction and patch to flip_animation_duration_set/get
On Sun, 14 Jul 2013 09:49:38 +0100 Martin Robinson mar...@cybercontrolsystems.co.uk said: 1. phabricator + arcanist would be best: https://phab.enlightenment.org/w/arcanist/ 2. if you want to make this configurable - awesome. can i suggest you look at elm_config.c and make it a config value loaded from the system/user config? :) Hi. I have just joined this list, and want to briefly introduce myself and propose a patch - so this is asking for the right way to go about that. I am working on a touch-screen based controller for a home automation system, and after evaluating GTK and (briefly) QT, decided that the Elementary widget set was going to be the best looking and least cumbersome way of going about it. The board I am using has a 800Mhz AMR9 processor but no graphics hardware support, so graphics performance is poor (Software X11 on a framebuffer). Hence the first thing I needed was a way of altering a flip duration from its unchangeable default of 0.5sec. I have a minimal patch that provides this (plus Doxygen text). How should I propose this patch? Simply in an email a to this list? Regards, Martin Cybercontrolsystems -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Weekly news from the automated build and QA front
Hello. This should give everyone an overview over what has happened in the last week regarding our continuous integration builds, unit tests and coverage as well as all static analyser runs and things like address-sanitizer. The numbers in parentheses reflect the values from last week to give you a trend. CI: o More work have been done to setup a mingw (windows cross) build for efl. It comes along quite nicely but is not yet ready. o Overall build statistic: 16.48% (12.7%) failed and 83.43% (87.3%) succeeded. https://build.enlightenment.org/ clang scan-build: o Nightly builds got fixed so we have up to date scan build results again o EFL scan-build reports 596 (596) issues. https://build.enlightenment.org/job/nightly_efl_clang_x86_64/lastSuccessfu lBuild/artifact/scan-build/build/ Exactness: o Problems with fonts o Still waiting for the first successful run on jenkins Unit tests: o 266 unit tests for efl and none failing Coverage: o EFL total coverage is at 25.7% (25.2%) lines and 28.4% (28.0%) functions o Thanks for more tests goes to Sergii Kanaev. But don't feel left out everybody can contribute here :) Coverity: o EFL: Outstanding defects 493 (533) with a density of 0.95 (1.03). 37 defects fixed since last build and 1 added. o Elm: Outstanding defects 42 (41) with a density of 0.20 (0.20). 0 defects fixed since last build and 1 added. o E: Outstanding defects 200 (203) with a density of 0.74 (0.75). 3 defects fixed since last build and 0 added. If anybody wants to see something added here let me know and be my guest. regards Stefan Schmidt -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Wrong linespacing (I guess) on 1.7 branch
On 12/07/13 22:13, Rafael Antognolli wrote: Hi Tom, I think the following commit broke the calculation of linespace on 1.7 branch: 79bfa9cd10ee64f49008bf3638db77fd2c557552 It has your name on it, so I think you can help here :P The error was first noticed on elementary client side window decorations in wayland backend, but you can can also see it just by comparing two versions of elementary test running (on X11 too) side by side, one on master and another on 1.7. Or take screenshots. You will notice that in elementary_test, the genlist row height is different between both versions. Let me know if you need more help to reproduce it, or if you want me to open a ticket on phab. Please open a ticket on phab regardless. I will take a look as soon as I can. -- Tom. -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 02/02: evas: let's get the pixels if the image is dirty, not only when we do already have pixels.
seriously, fucking stop it with the tabs. I've been after you about this for months, you know I have, so just fucking change your fucking editor to stop fucking putting them in. On Mon, Jul 15, 2013 at 11:12 AM, Cedric Bail - Enlightenment Git no-re...@enlightenment.org wrote: cedric pushed a commit to branch master. commit dce0fbcb848404b3f42fa23ff3979aaca6663132 Author: Cedric Bail cedric.b...@samsung.com Date: Mon Jul 15 19:11:06 2013 +0900 evas: let's get the pixels if the image is dirty, not only when we do already have pixels. --- -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: examples: Add missing Ecore_Eo.h for some defines.
Hello. On 07/15/2013 02:19 AM, Cedric BAIL wrote: Hello, On Sat, Jul 13, 2013 at 3:43 AM, Rafael Antognolli antogno...@gmail.com wrote: Ecore.h already includes Ecore_Eo.h, so why do we need this extra include? Indeed. Well, I know exactly why. E*_Eo.h API is unstable and will not be a supported feature for 1.8. This is why you need to use a specific flag to turn it on. That should cover Rafael's question why I added it. Examples have been converted to use the EO api but the build system has not been changed to add the flag. Now I tried to find the problem with our nightly builds and just realized that some defines have been missing. A grep gave me Ecore_Eo.h as provider so I just thought they have been missing. Example should not at this stage, I think, expose any E*_Eo.h API as I don't think we want to encourage people to use it. Why did the examples get then converted in the first place? Completely ignoring the fact they they never could have been even compile tested as the change was not done in the build system. I would be more for disabling the build of this example at this stage. Instead of disabling example they should just get reverted to the state before the eo api change and kept working like this. regards Stefan Schmidt -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 02/02: evas: let's get the pixels if the image is dirty, not only when we do already have pixels.
On 15/07/13 13:24, Michael Blumenkrantz wrote: seriously, fucking stop it with the tabs. I've been after you about this for months, you know I have, so just fucking change your fucking editor to stop fucking putting them in. I politely agree with Mike. -- Tom. -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Wrong linespacing (I guess) on 1.7 branch
On 12/07/13 22:13, Rafael Antognolli wrote: Hi Tom, I think the following commit broke the calculation of linespace on 1.7 branch: 79bfa9cd10ee64f49008bf3638db77fd2c557552 It has your name on it, so I think you can help here :P The error was first noticed on elementary client side window decorations in wayland backend, but you can can also see it just by comparing two versions of elementary test running (on X11 too) side by side, one on master and another on 1.7. Or take screenshots. You will notice that in elementary_test, the genlist row height is different between both versions. Let me know if you need more help to reproduce it, or if you want me to open a ticket on phab. Hey, Just tried to reproduce it, I can't. 1.7 and master look the same. I tried the genlist test. Well, there's one apparent reason, 1.7 doesn't have the shadows of overlapping genlist items. Am I missing something? Tried 1.7.7 (latest on arch). -- Tom. -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: examples: Add missing Ecore_Eo.h for some defines.
On Mon, Jul 15, 2013 at 9:34 PM, Stefan Schmidt s.schm...@samsung.comwrote: Hello. On 07/15/2013 02:19 AM, Cedric BAIL wrote: Hello, On Sat, Jul 13, 2013 at 3:43 AM, Rafael Antognolli antogno...@gmail.com wrote: Ecore.h already includes Ecore_Eo.h, so why do we need this extra include? Indeed. Well, I know exactly why. E*_Eo.h API is unstable and will not be a supported feature for 1.8. This is why you need to use a specific flag to turn it on. That should cover Rafael's question why I added it. Examples have been converted to use the EO api but the build system has not been changed to add the flag. Now I tried to find the problem with our nightly builds and just realized that some defines have been missing. A grep gave me Ecore_Eo.h as provider so I just thought they have been missing. Example should not at this stage, I think, expose any E*_Eo.h API as I don't think we want to encourage people to use it. Why did the examples get then converted in the first place? Completely ignoring the fact they they never could have been even compile tested as the change was not done in the build system. I would be more for disabling the build of this example at this stage. Instead of disabling example they should just get reverted to the state before the eo api change and kept working like this. +1 Yes the examples with eo should be reverted to the previous state. Thanks. Daniel Juyung Seo (SeoZ) regards Stefan Schmidt -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: examples: Add missing Ecore_Eo.h for some defines.
Hello. On 07/15/2013 01:34 PM, Stefan Schmidt wrote: On 07/15/2013 02:19 AM, Cedric BAIL wrote: I would be more for disabling the build of this example at this stage. Instead of disabling example they should just get reverted to the state before the eo api change and kept working like this. I did a bit of digging on this. Reverting my patch breaks make examples like this: ecore_idler_example.c:109:17: error: ‘ECORE_IDLER_CLASS’ undeclared (first use in this function) The usage of ECORE_IDLER_CLASS is like this since the efl merge. Means before any change of the Eo headers coming in. Which in turn makes this a regression in the API we are offering. An application that might used that with 1.7 would not longer be able to use it with 1.8. Well, it could enable the flag to get the Eo api but that is something we don't want. regards Stefan Schmidt -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA migration to git
On Mon, Jul 15, 2013 at 4:29 AM, Carsten Haitzler ras...@rasterman.com wrote:
On Fri, 12 Jul 2013 18:20:07 -0300 Eduardo Lima (Etrunko) ebl...@gmail.com
said:
Can you try the attached patch and comment? I think it makes sense to
have the icon above the selection.
well i think it looks ok. just icons feel a bit big at the default 40px shelf
size. that's why i made it smaller to start with. also the taskbar now leaves
almsot no spacing/padding at the top/bottom... your offset of 2 1 is also
asymmetrical... :/ (part { name: sel_base - that one). try the attached
one:
Looks alright. I was trying to keep the tasks buttons and settings
applet aligned to the top, but still keeping some spacing between the
buttons. The shadow and glow on the bottom take more space than on the
top part, that's why i used different values.
--
Eduardo de Barros Lima ◤✠◢
ebl...@gmail.com
--
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
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo: potential improvements
On 10/07/13 11:00, Cedric BAIL wrote: On Wed, Jul 10, 2013 at 6:02 PM, Jérémy Zurcher jer...@asynk.ch wrote: On Wednesday 10 July 2013 16:41, Cedric BAIL wrote : On Tue, Jul 9, 2013 at 11:08 PM, Jérémy Zurcher jer...@asynk.ch wrote: On Tuesday 09 July 2013 13:40, Tom Hacohen wrote : On 09/07/13 03:55, Carsten Haitzler (The Rasterman) wrote: On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen tom.haco...@samsung.com said: Hey guys, The hero Jeremy Zurcher has been playing around and looking for ways to improve Eo and address all the issues that have been raised by everyone. We revisited some old ideas, tried some new ideas and changed our compromises and preferences to better suit our needs (followed by the extensive trial period). We think we made things better and we'd like to hear your thoughts and suggestions. The code resides in devs/tasn/eo2. The differences are not major usage-wise (i.e eo_do), but are major internally and class-creation-wise. There's an example of the usage of the new API in the eo2test directory. The existing code-base hasn't been changed to use the new API, so there's not a lot to review. Eo2 is not complete, we'd like to hear your thoughts before finishing things. Major changes: 1. No more va_args, good ol' normal functions instead. good and bad. good as varags is a bit unwieldy. bad as in more symbols and either more function calls inlined in app code OR more code in general inlined (with macros or inline funcs). end result? unknown until we try. also another bad... work to port the existing eo code over. without full details, amount of work unknown. (missing git tree). I think it's better to inline those in the app, yeah. I don't think a function call + an if are much to worry about. Amount of work is known: everything needs to be done. This is a draft, not even a complete solution. This example doesn't handle eo_do_super and the eo_data_scope_get. I pushed some stuff in devs/tasn/eo2, nothing inlined (real method call performed), basic eo_data_scope_get support (+ real eo fct call) I think that in your design eo2_func_get need to return the klass somehow or it won't work. that's why i replaced it with eo2_call_resolve Yeah, saw that later on. and a stupid benchmark Ok, I pushed my own benchmark and fixed Eo.h compilation with C++. The can't compile anymore, gcc and clang yels ./src/lib/eo/Eo.h:619:47: error: expected expression before ‘=’ token __##Name##_func func = (__##Name##_func) = call.func; \ can you fix please Oh ! Stupid merge issue. Fixed now. benchmark is half done has the event can't be tested as those function are eo_do for the moment. Never the less, eo_do2 does create an around 25% slow down in that benchmark. I have yet to understand why and what is going on. I tried to play with pure and const __attribute__, but to no change. Please check what is going on (Also with latest change, I don't think the compiler can optimize the request to _eo_data_scope_get anymore). I think so, maybe we should go back to eo2_func_get eo2_data_scope_get, (and return klass somehow) instead of eo2_call_resolve I am thinking that having a function that return the klass would be better and then get the func and data from it. All this function could be marked with __attribute__((const)) I guess and lead to further automatic elimination of duplicated call. Signal/Benchmark: eo call: OK Benchmark: callback loop: 18.260155ns per round: OK Signal/Benchmark: eo2 call: OK Benchmark: callback loop: 23.235780ns per round: OK bad !! Apparently the main issue come from the call to eo_unref. Using _eo_unref directly would give an almost 10% speed increase. Same goes for eo2_do_start that has a potential for 7% increase if we can call _eo_ref directly. But the biggest benefit would be to reduce the cost of calling eo2_call_resolve_internal. Having a const function there would definitively help the compiler to call those function a limited amount of time. Funny enough, the time spend in __inc is 2% of the all benchmark with eo2 and 2.30% with eo, so it doesn't require a big leap to do. By direct you mean the same without the id/magic check? If so, that can easily be done and is planned. Won't be inlined though, which is an annoyance. -- Tom. -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo: potential improvements
On 09/07/13 04:09, Cedric BAIL wrote: Hello, On Tue, Jul 9, 2013 at 2:00 AM, Tom Hacohen tom.haco...@samsung.com wrote: The hero Jeremy Zurcher has been playing around and looking for ways to improve Eo and address all the issues that have been raised by everyone. We revisited some old ideas, tried some new ideas and changed our compromises and preferences to better suit our needs (followed by the extensive trial period). We think we made things better and we'd like to hear your thoughts and suggestions. The code resides in devs/tasn/eo2. The differences are not major usage-wise (i.e eo_do), but are major internally and class-creation-wise. There's an example of the usage of the new API in the eo2test directory. The existing code-base hasn't been changed to use the new API, so there's not a lot to review. Eo2 is not complete, we'd like to hear your thoughts before finishing things. Major changes: 1. No more va_args, good ol' normal functions instead. 2. Functions are resolved in eo and then called directly, creating a flatter backtrace. 3. We can have return values (to some extent). 4. Less boiler-plate. 5. Looks like we'll be able to get rid of some code thanks to this change. 6. Possibly (probably) faster on platforms that pass parameters in registers. 7. Easier to do breakpoint on a specific eo_do call, instead of an implementation. Sounds like valid point. What we'd still like to achieve: 1. Being able to drop the IDs in favour for more friendly IDs. It'd be best to find a way to use the function pointers (for example) as the IDs, but the problem is, that because function pointers are more unknown we can do less optimisations on them which we'd like to avoid. 2. Reduce more boiler-plate. Haven't been implemented yet: eo_do_super (among many other things). There is more FIXME lurking around also in eo.c in your branch. Yes. Additional comments: EO_FUNC - this one creates a function that resolves and returns the appropriate function. The functions created using this macro should be used instead of the current eo macros. This one can potentially be improved. eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and possibly other stuff in the future). I have some issue with EO_FUNC. The main one being that I really can't get what the parameter of the created function are. Reading a header full of those will be completely useless to me ! The readability of that macro should really be improved. Also the eo2_do macro lead to weird eo_o parameter for all function call. This seems like a duplication and source for potential error. You can't do it otherwise. Well you can have an EO_CALL macro like Jeremy likes, but I hate it, it's more of a mess. If you have an idea, please let me know and I'll try it. The second problem I see is that we are going to push a lot of pressure on the compiler with all this functions. Every EO_FUNC will be a static inline function, there is going to be a massive number of them in all our headers, slowing down compilation quite a lot. True, well, we can make them symbols instead, but I didn't want to increase the symbol count. I think making them inline will give an advantage in that regard. An advantage you also agree with. On a debugging and tracing ability, we do loose some ability there. There is no easy way to hook before and after the function call at this stage. This could be useful for many tools. Like Daniel's espion, that does something like strace but to an efl application. Or my starting attempt to do a performance analysis by knowing from which klass the function come from and where we do spend time. I disagree. You can hook on the eo_do_begin and eo_do_end calls in eo_do2. That will give you exactly the same. From an optimization perspective, it would be good to mark eo_func_get as being 'pure' so it will eliminate multiple call if they are on the same object. Also did you do any benchmark comparing the previous use of eo_do with your new approach ? Right now using Eo doesn't slow us down, I would be interested to see a comparison of the same example (CPU, library size and used memory). I haven't done any benchmarks, it's an API mock-up at the moment, not a full blown implementation one can compare to. There are more details to be ironed out before that. Looking forward to hearing what you have to say. Eo is one of the biggest change we did for 1.8. At this stage it is optimized to a point where we don't feel the cost compared to 1.7. It may be even faster in some work load and use less memory. Any major change like this is going to have an impact on any release for 1.8 (We are already 2 months late and will likely be 3, so what is it to add 2 more months delay). A major question is how fast can you roll your change in EFL ? The answer: I don't know. It depends if we really want it. German Daniel claims that there are tools that can help me do it. I
Re: [E-devel] Wrong linespacing (I guess) on 1.7 branch
On Mon, Jul 15, 2013 at 9:37 AM, Tom Hacohen tom.haco...@samsung.com wrote: On 12/07/13 22:13, Rafael Antognolli wrote: Hi Tom, I think the following commit broke the calculation of linespace on 1.7 branch: 79bfa9cd10ee64f49008bf3638db77fd2c557552 It has your name on it, so I think you can help here :P The error was first noticed on elementary client side window decorations in wayland backend, but you can can also see it just by comparing two versions of elementary test running (on X11 too) side by side, one on master and another on 1.7. Or take screenshots. You will notice that in elementary_test, the genlist row height is different between both versions. Let me know if you need more help to reproduce it, or if you want me to open a ticket on phab. Hey, Just tried to reproduce it, I can't. 1.7 and master look the same. I tried the genlist test. Well, there's one apparent reason, 1.7 doesn't have the shadows of overlapping genlist items. Am I missing something? Tried 1.7.7 (latest on arch). OK, will open a ticket, but that commit is on top of 1.7.7. That means evas-1.7 branch, so it doesn't happen on the released version. But will be there on a possible future release (1.7.8, if that happens). -- Rafael Antognolli -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Wrong linespacing (I guess) on 1.7 branch
On 15/07/13 17:02, Rafael Antognolli wrote: On Mon, Jul 15, 2013 at 9:37 AM, Tom Hacohen tom.haco...@samsung.com wrote: On 12/07/13 22:13, Rafael Antognolli wrote: Hi Tom, I think the following commit broke the calculation of linespace on 1.7 branch: 79bfa9cd10ee64f49008bf3638db77fd2c557552 It has your name on it, so I think you can help here :P The error was first noticed on elementary client side window decorations in wayland backend, but you can can also see it just by comparing two versions of elementary test running (on X11 too) side by side, one on master and another on 1.7. Or take screenshots. You will notice that in elementary_test, the genlist row height is different between both versions. Let me know if you need more help to reproduce it, or if you want me to open a ticket on phab. Hey, Just tried to reproduce it, I can't. 1.7 and master look the same. I tried the genlist test. Well, there's one apparent reason, 1.7 doesn't have the shadows of overlapping genlist items. Am I missing something? Tried 1.7.7 (latest on arch). OK, will open a ticket, but that commit is on top of 1.7.7. That means evas-1.7 branch, so it doesn't happen on the released version. But will be there on a possible future release (1.7.8, if that happens). That explains why my tests failed. :) Yeah, open a ticket and assign it to me, and I'll take another look as soon as I can. -- Tom. -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC][xdg-utils] Use enlightenment_open to open files in xdg-open
a read of that patch says to me that that looks good. :) submit it! Done. https://bugs.freedesktop.org/show_bug.cgi?id=66944 -- Igor The patch is for xdg-utils project. It makes various xdg-* scripts detect if enlightenment is running and use enlightenment_open in xdg-open. How to test the patch: 1. Clone xdg-utils repository from here: git://anongit.freedesktop.org/xdg/xdg-utils 2. Apply the patch. 3. Run ./configure 4! Update scripts from scripts/ directory with: $ cd scripts make scripts Without this step you won't get any changes for the xdg-* scripts! 5. Run make install Please test and give a response. If the patch is good i'll send it to xdg-utils project. -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: examples: Add missing Ecore_Eo.h for some defines.
Yop, On Mon, Jul 15, 2013 at 11:12 PM, Stefan Schmidt s.schm...@samsung.com wrote: On 07/15/2013 01:34 PM, Stefan Schmidt wrote: On 07/15/2013 02:19 AM, Cedric BAIL wrote: I would be more for disabling the build of this example at this stage. Instead of disabling example they should just get reverted to the state before the eo api change and kept working like this. I did a bit of digging on this. Reverting my patch breaks make examples like this: ecore_idler_example.c:109:17: error: ‘ECORE_IDLER_CLASS’ undeclared (first use in this function) The usage of ECORE_IDLER_CLASS is like this since the efl merge. Means before any change of the Eo headers coming in. Which in turn makes this a regression in the API we are offering. An application that might used that with 1.7 would not longer be able to use it with 1.8. Well, it could enable the flag to get the Eo api but that is something we don't want. The merge with eo started before the single tree merge. ECORE_IDLER_CLASS is provided by Ecore_Eo.h and does only exist in 1.8. It is just impossible it comes from 1.7, Eo didn't exist at that times. I have no idea where the example come from and I couldn't dig a version that come from before the merge. That's why I proposed to disable it for now. -- Cedric BAIL -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA migration to git
On Mon, 15 Jul 2013 11:13:16 -0300 Eduardo Lima (Etrunko) ebl...@gmail.com
said:
On Mon, Jul 15, 2013 at 4:29 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Fri, 12 Jul 2013 18:20:07 -0300 Eduardo Lima (Etrunko)
ebl...@gmail.com said:
Can you try the attached patch and comment? I think it makes sense to
have the icon above the selection.
well i think it looks ok. just icons feel a bit big at the default 40px
shelf size. that's why i made it smaller to start with. also the taskbar
now leaves almsot no spacing/padding at the top/bottom... your offset of 2
1 is also asymmetrical... :/ (part { name: sel_base - that one). try the
attached one:
Looks alright. I was trying to keep the tasks buttons and settings
applet aligned to the top, but still keeping some spacing between the
buttons. The shadow and glow on the bottom take more space than on the
top part, that's why i used different values.
the same blue is used elsewhere (toolbars, also in the elmd dark theme for
anchor style buttons, genlist headers etc.) i know it takes space, but in all
of them content ins vertically centered excluding the blue bar, so blue bar is
part of the space for the content. i'd rather it stay consistent. :)
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
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
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 02/02: evas: let's get the pixels if the image is dirty, not only when we do already have pixels.
Where the fuck do you see tabs ! And I use the coding style specified on our wiki for years : http://trac.enlightenment.org/e/wiki/ECoding/Emacs . As I have stated before, I have no fucking idea what you are talking about. An improvement in your communication ability would be welcome. On Mon, Jul 15, 2013 at 9:24 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: seriously, fucking stop it with the tabs. I've been after you about this for months, you know I have, so just fucking change your fucking editor to stop fucking putting them in. On Mon, Jul 15, 2013 at 11:12 AM, Cedric Bail - Enlightenment Git no-re...@enlightenment.org wrote: cedric pushed a commit to branch master. commit dce0fbcb848404b3f42fa23ff3979aaca6663132 Author: Cedric Bail cedric.b...@samsung.com Date: Mon Jul 15 19:11:06 2013 +0900 evas: let's get the pixels if the image is dirty, not only when we do already have pixels. --- -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Cedric BAIL -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo: potential improvements
Hello, On Tue, Jul 16, 2013 at 12:35 AM, Tom Hacohen tom.haco...@samsung.com wrote: On 09/07/13 04:09, Cedric BAIL wrote: On Tue, Jul 9, 2013 at 2:00 AM, Tom Hacohen tom.haco...@samsung.com wrote: The hero Jeremy Zurcher has been playing around and looking for ways to improve Eo and address all the issues that have been raised by everyone. We revisited some old ideas, tried some new ideas and changed our compromises and preferences to better suit our needs (followed by the extensive trial period). We think we made things better and we'd like to hear your thoughts and suggestions. The code resides in devs/tasn/eo2. The differences are not major usage-wise (i.e eo_do), but are major internally and class-creation-wise. There's an example of the usage of the new API in the eo2test directory. The existing code-base hasn't been changed to use the new API, so there's not a lot to review. Eo2 is not complete, we'd like to hear your thoughts before finishing things. Major changes: 1. No more va_args, good ol' normal functions instead. 2. Functions are resolved in eo and then called directly, creating a flatter backtrace. 3. We can have return values (to some extent). 4. Less boiler-plate. 5. Looks like we'll be able to get rid of some code thanks to this change. 6. Possibly (probably) faster on platforms that pass parameters in registers. 7. Easier to do breakpoint on a specific eo_do call, instead of an implementation. Sounds like valid point. What we'd still like to achieve: 1. Being able to drop the IDs in favour for more friendly IDs. It'd be best to find a way to use the function pointers (for example) as the IDs, but the problem is, that because function pointers are more unknown we can do less optimisations on them which we'd like to avoid. 2. Reduce more boiler-plate. Haven't been implemented yet: eo_do_super (among many other things). There is more FIXME lurking around also in eo.c in your branch. Yes. Additional comments: EO_FUNC - this one creates a function that resolves and returns the appropriate function. The functions created using this macro should be used instead of the current eo macros. This one can potentially be improved. eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and possibly other stuff in the future). I have some issue with EO_FUNC. The main one being that I really can't get what the parameter of the created function are. Reading a header full of those will be completely useless to me ! The readability of that macro should really be improved. Also the eo2_do macro lead to weird eo_o parameter for all function call. This seems like a duplication and source for potential error. You can't do it otherwise. Well you can have an EO_CALL macro like Jeremy likes, but I hate it, it's more of a mess. If you have an idea, please let me know and I'll try it. Maybe defining a macro with the same name after the function definition to automatically add the parameter. But that would be hugly to. I have yet to find an idea that I like. The second problem I see is that we are going to push a lot of pressure on the compiler with all this functions. Every EO_FUNC will be a static inline function, there is going to be a massive number of them in all our headers, slowing down compilation quite a lot. True, well, we can make them symbols instead, but I didn't want to increase the symbol count. I think making them inline will give an advantage in that regard. An advantage you also agree with. Yup, just a complain if someone got an idea on how to improve things, and no using a macro instead would be worth. On a debugging and tracing ability, we do loose some ability there. There is no easy way to hook before and after the function call at this stage. This could be useful for many tools. Like Daniel's espion, that does something like strace but to an efl application. Or my starting attempt to do a performance analysis by knowing from which klass the function come from and where we do spend time. I disagree. You can hook on the eo_do_begin and eo_do_end calls in eo_do2. That will give you exactly the same. No. Having hook on eo_do_begin and eo_do_end calls are way off what we want to look at. We want every operation. I am thinking about adding to function pointer set to NULL by default that will be used in the EO_FUNC_BODY macro, before and after the function call with all the parameter given to it. From an optimization perspective, it would be good to mark eo_func_get as being 'pure' so it will eliminate multiple call if they are on the same object. Also did you do any benchmark comparing the previous use of eo_do with your new approach ? Right now using Eo doesn't slow us down, I would be interested to see a comparison of the same example (CPU, library size and used memory). I haven't done any benchmarks, it's an API mock-up at the moment, not a full blown implementation one can compare to.
Re: [E-devel] Eo: potential improvements
On Tue, 16 Jul 2013 08:58:15 +0900 Cedric BAIL cedric.b...@free.fr said: Hello, On Tue, Jul 16, 2013 at 12:35 AM, Tom Hacohen tom.haco...@samsung.com wrote: On 09/07/13 04:09, Cedric BAIL wrote: On Tue, Jul 9, 2013 at 2:00 AM, Tom Hacohen tom.haco...@samsung.com ... That lead to an equivalent question, how many people have yet reviewed your proposal and are in favor of the change or have idea to improve it. I may want to put some pressure on that side, as I am really upset by our current delay on 1.8 and I really want to ear more than one voice in favor of another huge delay. Well, no one is saying anything either way. It's like Eo1. People were quiet until it was too late to complain. Expect the same. :) Snif ! You are breaking all hope in me this morning. you break git. tom breaks you. i like the symmetry. fyi - i did have a look and commented on it already :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: edje/vim - updated syntax
Oh it looks like there are two edc.vim files in git. efl/data/edje/edc.vim vs efl/data/edje/vim/syntax/edc.vim. What's the difference? Daniel Juyung Seo (SeoZ) On Mon, Jul 15, 2013 at 10:16 PM, ChunEon Park - Enlightenment Git no-re...@enlightenment.org wrote: hermet pushed a commit to branch master. commit 17f18500a73901b44d7ffc7511b886f78e9ff9ed Author: ChunEon Park her...@hermet.pe.kr Date: Mon Jul 15 22:16:08 2013 +0900 edje/vim - updated syntax --- data/edje/vim/syntax/edc.vim | 1 + 1 file changed, 1 insertion(+) diff --git a/data/edje/vim/syntax/edc.vim b/data/edje/vim/syntax/edc.vim index 6f41ae3..2a9b7e8 100644 --- a/data/edje/vim/syntax/edc.vim +++ b/data/edje/vim/syntax/edc.vim @@ -47,6 +47,7 @@ syn keyword edcLabelint double string external script_only contained syn keywordedcConstant COMP RAW LOSSY NONE ON_HOLD AUTOGRAB NOGRAB syn keywordedcConstant TEXT IMAGE RECT TEXTBLOCK SWALLOW GRADIENT GROUP +syn keywordedcConstant SPACER syn keywordedcConstant NONE PLAIN OUTLINE SOFT_OUTLINE SHADOW PROXY syn keywordedcConstant SOFT_SHADOW OUTLINE_SHADOW OUTLINE_SOFT_SHADOW syn keywordedcConstant GLOW FAR_SHADOW FAR_SOFT_SHADOW -- -- 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 -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Weekly news from the automated build and QA front
On Mon, 15 Jul 2013 09:16:44 +0100 Stefan Schmidt s.schm...@samsung.com said: Hello. This should give everyone an overview over what has happened in the last week regarding our continuous integration builds, unit tests and coverage as well as all static analyser runs and things like address-sanitizer. The numbers in parentheses reflect the values from last week to give you a trend. CI: o More work have been done to setup a mingw (windows cross) build for efl. It comes along quite nicely but is not yet ready. o Overall build statistic: 16.48% (12.7%) failed and 83.43% (87.3%) succeeded. https://build.enlightenment.org/ clang scan-build: o Nightly builds got fixed so we have up to date scan build results again o EFL scan-build reports 596 (596) issues. https://build.enlightenment.org/job/nightly_efl_clang_x86_64/lastSuccessfu lBuild/artifact/scan-build/build/ Exactness: o Problems with fonts o Still waiting for the first successful run on jenkins Unit tests: o 266 unit tests for efl and none failing Coverage: o EFL total coverage is at 25.7% (25.2%) lines and 28.4% (28.0%) functions o Thanks for more tests goes to Sergii Kanaev. But don't feel left out everybody can contribute here :) Coverity: o EFL: Outstanding defects 493 (533) with a density of 0.95 (1.03). 37 defects fixed since last build and 1 added. o Elm: Outstanding defects 42 (41) with a density of 0.20 (0.20). 0 defects fixed since last build and 1 added. o E: Outstanding defects 200 (203) with a density of 0.74 (0.75). 3 defects fixed since last build and 0 added. slow but steady reduction there. good. :) If anybody wants to see something added here let me know and be my guest. regards Stefan Schmidt -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
