[E-devel] Renaming elm_object_label_set/get
Dear Mike and everyone else, As you may know, mike_m recently added elm_object_label_set/get API and elm_object_text_set/get macros as a generic way to set/get text for elementary widgets. Not all the widgets are supported yet, but some are. I like this change a lot as it makes the API smaller, nicer, more consistent and easier to remember. Currently, elm_object_label_get accepts two parameters, the object, and the part in that object. So for example one would call: elm_object_label_get(some_label, default) for getting the default string of the label. I'm sending this mail because I disagree with Mike's choice of naming. He chose elm_object_label_set/get because in most cases we are setting labels, but since we also support setting entries, this name is just not good enough. I suggest renaming elm_object_label_set/get to elm_object_text_part_set/get or something similar which is, in my pov, better suiting than the former since we are using it to set/get more than just labels. What do you guys think? Should I rename them to elm_object_text_part_set/get? Thanks, Tom. P.S, again, thanks a lot to mike for doing this awesome change. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Renaming elm_object_label_set/get
On 04/07/11 10:48, Daniel Juyung Seo wrote: elm_object_text_part_set/get? +1. I really agree with this idea. This is what I had in my mind. We already talked this issue in the mailing list. http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg32884.html You misread my email :) We already have this API by a different name. I'm suggesting a rename to elm_object_text_part_set/get. -- Tom. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Renaming elm_object_label_set/get
We already have this API by a different name. I'm suggesting a rename to elm_object_text_part_set/get. Yeah that's what I'm saying :) We discussed it but it was committed as a different name. So it's time to get it right. Daniel Juyung Seo (SeoZ) On Mon, Jul 4, 2011 at 4:55 PM, Tom Hacohen tom.haco...@partner.samsung.com wrote: On 04/07/11 10:48, Daniel Juyung Seo wrote: elm_object_text_part_set/get? +1. I really agree with this idea. This is what I had in my mind. We already talked this issue in the mailing list. http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg32884.html You misread my email :) We already have this API by a different name. I'm suggesting a rename to elm_object_text_part_set/get. -- Tom. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Renaming elm_object_label_set/get
On 07/04/2011 04:41 PM, Tom Hacohen wrote: What do you guys think? Should I rename them to elm_object_text_part_set/get? Hey Tom, How about this: elm_object_label_set - elm_object_text_part_set elm_object_label_get - elm_object_text_part_get but keeping the elm_object_text_set/get macros as they are. i.e. EAPI void elm_object_text_part_set(Evas_Object *obj, const char *item, const char *label); #define elm_object_text_set(obj, label) elm_object_text_part_set((obj), NULL, (label)) I like elm_object_text_set() for the default part as it's short and simple. Using label_set for the name was to keep it separate from text_set, but I agree text_part_set is good. thanks, Mike -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Renaming elm_object_label_set/get
On 04/07/11 11:12, Mike McCormack wrote: How about this: elm_object_label_set - elm_object_text_part_set elm_object_label_get - elm_object_text_part_get but keeping the elm_object_text_set/get macros as they are. i.e. EAPI void elm_object_text_part_set(Evas_Object *obj, const char *item, const char *label); #define elm_object_text_set(obj, label) elm_object_text_part_set((obj), NULL, (label)) I like elm_object_text_set() for the default part as it's short and simple. Using label_set for the name was to keep it separate from text_set, but I agree text_part_set is good. Yeah, that's exactly what I meant. :) I'm glad you agree, will change it soon. -- Tom. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Renaming elm_object_label_set/get
Hello ~ Tom. I really really really agree with this change J It should be ~ I think. +1 to your opinion Thanks. WooHyun. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Renaming elm_object_label_set/get
Ok, it's in. Rev: 60975. -- Tom. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Patch] add evas_object_image_animated feature
Hi. I’m Jiyoun. I have plan to evas image object support animated image like Agif. I make patch related with image object which can support animated image. Added API is 1. EAPI Eina_Bool evas_object_image_animated_get(const Evas_Object *obj); - check image file's animation (DONE) 2. EAPI int evas_object_image_animated_frame_num_get(const Evas_Object *obj); - return total frame number of animated image(DONE) 3. EAPI Evas_Image_Animated_Loop_Hint evas_object_image_animated_loop_type_get(const Evas_Object *obj); - return loop type of image . currently I just add sequential(1-2-3-1...) type and reverse type(1-2-3-2-...).(DONE) 4. EAPI int evas_object_image_animated_loop_num_get(const Evas_Object *obj); - return animated image's loop number. It depends on image file type(DONE) 5. EAPI Eina_List *evas_object_image_animated_frame_times_get(const Evas_Object *obj, int start_frame, int fram_num); //return time duration - I added only API. If my concept related animated object, I will implement this API within this week. I almost done this) - this api return frame time list from start frame which size is frame_num. 6. EAPI void evas_object_image_animated_frame_set(Evas_Object *obj, int frame_num); - I divide this API implementation two step. a. First, I only support gif file type which have not to need previous frame. Application can request to set specific frame using this api. I will implement gif loader can decode specific frame which app request( I also this feature within tomorrow) b. second, support gif file type which have to need previout frame. For this, I add eina list to image entry or other object. (I 'll start this job after stabilization above feature) How about your opinion?? I send this patch for intermediate result. If my concept is right and acceptable, I 'll implement whole API and add doc or other things for summit. But if my approach is wrong , please get me advise to the right way. And I have plan support not only gif but also other animated type image. Thanks. evas_object_image_animated_feature.patch Description: Binary data -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Need help tracing OSX crash bug
E17 is overall working well with OSX. There's one important bug that needs to be fixed before it's ready for a binary release. On OSX, e17 crashes only on the first run after reboot. The white rectangle of death appears, and clicking continue a few times eventually brings up a working e17. However that's too buggy for a binary release. Just to be clear, if I quit e17 and restart, no crash. If I reboot, it crashes again in the same place. The crash only happens on the 1st run after reboot, and is reproducible. The gdb trace is here: http://pastebin.com/JzeA0xw6 The trace looks like something in mmx. If I compile ecore without mmx support, it crashes in the same place, but with equivalent non-mmx calls. That means the problem is probably higher up in the call stack, but I'm not sure where to look. This bug has been around for a while and I have posted before. Posting again hoping someone can help take a look at it. I can #irc if someone wants. If there's anything else useful I could capture pls let me know. I have valgrind, though I'm not sure how to effectively capture e17 in valgrind since it's never called directly - the wm is started with enlightenment_start. Dave -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] OSX crash bug: more info
The bug appears to be in evas, not ecore. I am running expedite using twm, so that none of the EFL's load until I launch expedite (with gdb). Expedite crashes before it even finishes loading, before any tests. GDB shows the exact same error as I was reporting for e17. On #irc now. Dave -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Need help tracing OSX crash bug
Reposting to keep the thread together (sorry): The bug appears to be in evas, not ecore. I am running expedite using twm, so that none of the EFL's load until I launch expedite (with gdb). Expedite crashes before it even finishes loading, before any tests. GDB shows the exact same error as I was reporting for e17. Expedite window is partially drawn. On #irc now. Dave -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Need help tracing OSX crash bug
Here is the gdb bt of expedite crashing when run in twm. This is the same evas
bug that's crashing e17 on OSX.
Expedite throws this before it finishes drawing the window.
(gdb) r -e xlib -f
Starting program: /usr/local/bin/expedite -e xlib -f
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x01ff
0x00010025c7d4 in _op_copy_c_dp_mmx (s=0x0, m=0x0, c=4294967295, d=0x1ff,
l=128) at op_copy_color_i386.c:12
12movq_r2m(mm1, d[0]);
(gdb) bt
#0 0x00010025c7d4 in _op_copy_c_dp_mmx (s=0x0, m=0x0, c=4294967295,
d=0x1ff, l=128) at op_copy_color_i386.c:12
#1 0x00010028b3f4 in rectangle_draw_internal ()
#2 0x00010028b0d3 in evas_common_rectangle_draw ()
#3 0x000100544562 in eng_rectangle_draw (data=0x100613880,
context=0x100613c90, surface=0x10062cd00, x=-592, y=0, w=720, h=420) at
evas_engine.c:181
#4 0x000100217ac1 in evas_object_rectangle_render ()
#5 0x000100247f4a in evas_render_mapped ()
#6 0x00010024968b in evas_render_updates_internal ()
#7 0x000100249d43 in evas_render ()
#8 0x00011ab4 in main (argc=4, argv=0x7fff5fbff1f8) at main.c:1373
(gdb) fr 1
#1 0x00010028b3f4 in rectangle_draw_internal ()
(gdb) l
7 movd_m2r(c, mm1);
8 movq_r2r(mm1, mm2);
9 psllq_i2r(32, mm1);
10 por_r2r(mm2, mm1);
11 for (; d e; d+=2) {
12movq_r2m(mm1, d[0]);
13 }
14 e+=1;
15 for (; d e; d++) {
16*d = c;
(gdb) p c
No symbol c in current context.
(gdb) p mm1
No symbol mm1 in current context.
(gdb) p mm2
No symbol mm2 in current context.
(gdb) p d
No symbol d in current context.
(gdb) p e
No symbol e in current context.
(gdb) p *d
No symbol d in current context.
(gdb) fr 2
#2 0x00010028b0d3 in evas_common_rectangle_draw ()
(gdb) l
17 }
18 }
19
20 #define _op_copy_cn_dp_mmx _op_copy_c_dp_mmx
21 #define _op_copy_can_dp_mmx _op_copy_c_dp_mmx
22 #define _op_copy_caa_dp_mmx _op_copy_c_dp_mmx
23
24 #define _op_copy_cn_dpan_mmx _op_copy_c_dp_mmx
25 #define _op_copy_c_dpan_mmx _op_copy_c_dp_mmx
26 #define _op_copy_can_dpan_mmx _op_copy_c_dp_mmx
(gdb) p _op_copy_c_dp_mmx
$1 = {void (DATA32 *, DATA8 *, DATA32, DATA32 *, int)} 0x10025c794
_op_copy_c_dp_mmx
(gdb) p _op_copy_cn_dp_mmx
No symbol _op_copy_cn_dp_mmx in current context.
(gdb) p _op_copy_can_dp_mmx
No symbol _op_copy_can_dp_mmx in current context.
(gdb) p _op_copy_caa_dp_mmx
No symbol _op_copy_caa_dp_mmx in current context.
(gdb) p _op_copy_cn_dpan_mmx
No symbol _op_copy_cn_dpan_mmx in current context.
(gdb) fr 0
#0 0x00010025c7d4 in _op_copy_c_dp_mmx (s=0x0, m=0x0, c=4294967295,
d=0x1ff, l=128) at op_copy_color_i386.c:12
12movq_r2m(mm1, d[0]);
(gdb) l
7 movd_m2r(c, mm1);
8 movq_r2r(mm1, mm2);
9 psllq_i2r(32, mm1);
10 por_r2r(mm2, mm1);
11 for (; d e; d+=2) {
12movq_r2m(mm1, d[0]);
13 }
14 e+=1;
15 for (; d e; d++) {
16*d = c;
(gdb) fr 3
#3 0x000100544562 in eng_rectangle_draw (data=0x100613880,
context=0x100613c90, surface=0x10062cd00, x=-592, y=0, w=720, h=420) at
evas_engine.c:181
181 evas_common_rectangle_draw(surface, context, x, y, w, h);
(gdb) l
176 )
177 evas_common_pipe_rectangle_draw(surface, context, x, y, w, h);
178else
179 #endif
180 {
181 evas_common_rectangle_draw(surface, context, x, y, w, h);
182 evas_common_cpu_end_opt();
183 }
184 }
185
(gdb) p surface
$2 = (void *) 0x10062cd00
(gdb) p context
$3 = (void *) 0x100613c90
(gdb) p x
$4 = -592
(gdb) p y
$5 = 0
(gdb) p w
$6 = 720
(gdb) p h
$7 = 420
(gdb) fr 4
#4 0x000100217ac1 in evas_object_rectangle_render ()
(gdb) l
186 static void
187 eng_line_draw(void *data __UNUSED__, void *context, void *surface, int
x1, int y1, int x2, int y2)
188 {
189 #ifdef BUILD_PIPE_RENDER
190if ((cpunum 1)
191 #ifdef EVAS_FRAME_QUEUING
192 evas_common_frameq_enabled()
193 #endif
194 )
195 evas_common_pipe_line_draw(surface, context, x1, y1, x2, y2);
(gdb) p cpunum
$8 = 2
(gdb) p surface
No symbol surface in current context.
(gdb) p context
No symbol context in current context.
(gdb) p x1
No symbol x1 in current context.
(gdb) p y1
$9 = {text variable, no debug info} 0x7fff85a57b60 y1
(gdb) p x2
No symbol x2 in current context.
(gdb) p y2
No symbol y2 in current context.
(gdb)
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of
Re: [E-devel] [patch] evas - add checking event type
On Mon, 27 Jun 2011 18:24:57 +0900 Hyoyoung Chang hyoyoung.ch...@samsung.com
said:
in svn! thanks very muchly! :)
Dear developers.
I found a bug about evas event handling.
In some situation, evas blocks some events by checking _evas_event_counter.
So I made a patch that is checking event type also event counter.
Reproduce steps:
1. make a window
2. show window before adding a elementary/genlist widget
--- codes ---
void _gl_mousedown_cb(void *data, Evas *evas, Evas_Object *obj,
void *event_info)
{
printf(_gl_mousedown_cb !! \n);
}
static Eina_Bool create_main_win(App *app)
{
app-win = elm_win_add(NULL, genlist-win, ELM_WIN_BASIC);
evas_object_show(app-win); -- position 1
Evas_Object *genlist = elm_genlist_add(app-win);
elm_win_resize_object_add(app-win, genlist);
evas_object_event_callback_add(genlist, EVAS_CALLBACK_MOUSE_DOWN,
_gl_mousedown_cb, NULL);
evas_object_show(genlist);
evas_object_resize(app-win, 320, 240);
//evas_object_show(app-win); -- position 2
return EINA_TRUE;
}
--- codes ---
In common use case, apps don't show main window at position 1.
However to reproduce, it can be at position 1.
Then, focus is at just on main window.
In that situation, if a user clicks a genlist, its event is dropped by evas.
Because in mouse down callback, it give focus to genlist.
Then two events is made.
First is mouse down, second is focus handling.
In event callback, evas processes mouse down after focus handling.
But evas found that mouse event is retarded event than focus handling.
So it ignores it.
This patch is introduce event handling type checking to
evas_object_event_callback_call.
Thank you.
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/evas: . src/lib/canvas src/lib/include
backport needed?
Daniel Juyung Seo (SeoZ)
On Tue, Jul 5, 2011 at 10:33 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
From: Hyoyoung Chang hyoyoung.ch...@samsung.com
Subject: [E-devel] [patch] evas - add checking event type
Dear developers.
I found a bug about evas event handling.
In some situation, evas blocks some events by checking _evas_event_counter.
So I made a patch that is checking event type also event counter.
Reproduce steps:
1. make a window
2. show window before adding a elementary/genlist widget
--- codes ---
void _gl_mousedown_cb(void *data, Evas *evas, Evas_Object *obj, void
*event_info)
{
printf(_gl_mousedown_cb !! \n);
}
static Eina_Bool create_main_win(App *app)
{
app-win = elm_win_add(NULL, genlist-win, ELM_WIN_BASIC);
evas_object_show(app-win); -- position 1
Evas_Object *genlist = elm_genlist_add(app-win);
elm_win_resize_object_add(app-win, genlist);
evas_object_event_callback_add(genlist, EVAS_CALLBACK_MOUSE_DOWN,
_gl_mousedown_cb, NULL);
evas_object_show(genlist);
evas_object_resize(app-win, 320, 240);
//evas_object_show(app-win); -- position 2
return EINA_TRUE;
}
--- codes ---
In common use case, apps don't show main window at position 1.
However to reproduce, it can be at position 1. Then, focus is at just on
main window.
In that situation, if a user clicks a genlist, its event is dropped by evas.
Because in mouse down callback, it give focus to genlist.
Then two events is made. First is mouse down, second is focus handling.
In event callback, evas processes mouse down after focus handling.
But evas found that mouse event is retarded event than focus handling.
So it ignores it.
This patch is introduce event handling type checking to
evas_object_event_callback_call.
Author: raster
Date: 2011-07-04 18:33:59 -0700 (Mon, 04 Jul 2011)
New Revision: 61026
Trac: http://trac.enlightenment.org/e/changeset/61026
Modified:
trunk/evas/ChangeLog trunk/evas/src/lib/canvas/evas_callbacks.c
trunk/evas/src/lib/include/evas_private.h
Modified: trunk/evas/ChangeLog
===
--- trunk/evas/ChangeLog 2011-07-05 00:06:27 UTC (rev 61025)
+++ trunk/evas/ChangeLog 2011-07-05 01:33:59 UTC (rev 61026)
@@ -413,3 +413,8 @@
* Polygon: Implemented is_inside.
+2011-07-05 Hyoyoung Chang
+
+ * Fix bug where event causes event in callback on same object, but
+ with same event counter, so also filter out same event types.
+
Modified: trunk/evas/src/lib/canvas/evas_callbacks.c
===
--- trunk/evas/src/lib/canvas/evas_callbacks.c 2011-07-05 00:06:27 UTC (rev
61025)
+++ trunk/evas/src/lib/canvas/evas_callbacks.c 2011-07-05 01:33:59 UTC (rev
61026)
@@ -170,8 +170,10 @@
Evas *e;
if ((obj-delete_me) || (!obj-layer)) return;
- if (obj-last_event == _evas_event_counter) return;
+ if ((obj-last_event == _evas_event_counter)
+ (obj-last_event_type == type)) return;
obj-last_event = _evas_event_counter;
+ obj-last_event_type = type;
if (!(e = obj-layer-evas)) return;
_evas_walk(e);
Modified: trunk/evas/src/lib/include/evas_private.h
===
--- trunk/evas/src/lib/include/evas_private.h 2011-07-05 00:06:27 UTC (rev
61025)
+++ trunk/evas/src/lib/include/evas_private.h 2011-07-05 01:33:59 UTC (rev
61026)
@@ -499,6 +499,7 @@
int mouse_grabbed;
int last_event;
+ Evas_Callback_Type last_event_type;
struct {
int in_move, in_resize;
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: antognolli trunk/ecore/src/lib/ecore
On Tue, 28 Jun 2011 12:08:14 -0300 Rafael Antognolli antogno...@profusion.mobi said: On Tue, Jun 28, 2011 at 12:05 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: ecore/fd_handler - Fix prepare_callback_set and improve its doc. Now they can be set even if the list is empty (sorry discomfitor, removing your optimization and making it O(n) again, back from O(0)). Also notice that due to the already existing check, if a prepare callback was already set to a fd handler, it can't be changed, so I added that to the docs. Author: antognolli Date: 2011-06-28 08:05:09 -0700 (Tue, 28 Jun 2011) New Revision: 60765 Trac: http://trac.enlightenment.org/e/changeset/60765 Modified: trunk/ecore/src/lib/ecore/ecore_main.c Modified: trunk/ecore/src/lib/ecore/ecore_main.c === --- trunk/ecore/src/lib/ecore/ecore_main.c 2011-06-28 15:03:58 UTC (rev 60764) +++ trunk/ecore/src/lib/ecore/ecore_main.c 2011-06-28 15:05:09 UTC (rev 60765) @@ -937,10 +937,21 @@ /** * @brief Set the prepare callback with data for a given #Ecore_Fd_Handler + * * @param fd_handler The fd handler * @param func The prep function * @param data The data to pass to the prep function - * This function will be called prior to the the fd handler's callback function. + * + * This function will be called prior to any fd handler's callback function + * (even the other fd handlers), before entering the main loop select function. + * + * @note Once a prepare callback is set for a fd handler, it cannot be changed. + * You need to delete the fd handler and create a new one, to set another + * callback. + * @note You probably don't need this function. It is only necessary for very + * uncommon cases that need special behavior. + * + * @ingroup Ecore_FD_Handler_Group */ EAPI void ecore_main_fd_handler_prepare_callback_set(Ecore_Fd_Handler *fd_handler, Ecore_Fd_Prep_Cb func, const void *data) @@ -953,7 +964,8 @@ } fd_handler-prep_func = func; fd_handler-prep_data = (void *)data; - if (fd_handlers_with_prep (!eina_list_data_find (fd_handlers_with_prep, fd_handler))) + if ((!fd_handlers_with_prep) || + (fd_handlers_with_prep (!eina_list_data_find (fd_handlers_with_prep, fd_handler /* FIXME: THIS WILL NOT SCALE WITH LOTS OF PREP FUNCTIONS!!! */ fd_handlers_with_prep = eina_list_append (fd_handlers_with_prep, fd_handler); } Is there anybody using this? Is it necessary anywhere? Since it wasn't working at all before this commit, I believe that its use is not necessary... A simple grep in E svn and I couldn't find it being used on any code. So, can we deprecate this API? i'd say no. here's why: 1. it was added back in 2005 by tilman 2. log msg is: Ecore_Fd_Handler: added a 'prepare' callback, that is called just before the main loop does its select() run for the FD handlers 3. it matches glib's prepare func. as such this allows you to do something to prepare the fd for select/poll. nothing we use right now requires this, but i can see that it may be needed in future. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
