[E-devel] Please fix your app/lib to use elm_object_content_set/get/unset APIs
Hi. I applied all widgets to use elm_object_content_set/get/unset APIs. Now some elementary APIs regarding content_set are deprecated. Additionally, I added macros into Elementary.h for a case -one widget has one more contents- so as to avoid user mistake. Here are some examples. //This widget has one more content parts. so please use elm_object_content_part_set/get/unset APIs. i.e) Evas_Object *panes; elm_object_content_part_set(panes, ELM_PANES_CONTET_LEFT, left_content); elm_object_content_part_set(panes, ELM_PANES_CONTENT_RIGHT, right_content); //This widget has just one content part. So you can use elm_object_content_set/get/unset APIs. i.e) Evas_Object *scroller; elm_object_content_set(scroller, content); You can refer the information about content parts which are available in the Elementary.h You may find it in head of the widget doxy. Anyway. From this time, please fix your app/lib to use the above common APIs! If you have any problems or questions, please reply me. Thank you. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix the bug that user cannot input key
On Fri, 28 Oct 2011 21:03:49 +0900 Jihoon Kim jihoon48@samsung.com said: also TranslateMessage needs to be called on KEYDOWNS... and KEYDOWN events and ALL events after the keydown have to be queued and held UNTIL the WM_CHAR that corresponds the KEYDOWN that is being held comes in then the WM_CHAR is matched up to that keydown, the string for the key is put into the event along with keyname and keysymbol and all events should be passed on/flushed after it until there are none left OR the next pending KEYDOWN being held are reached. this is necessary to keep order of events right like key downs BEFORE key up's etc. also note that the strings in windows are UTF-16. efl is expecting UTF-8. u need to eina_str_convert() it to UTF-8 Hi, EFL developers and Vincent. On Windows 7, there are some bugs related to key input in elementary_test. 1. alphabet and symbol characters doesn't be inputted in elementary entry. 2. When the space key is pressed, space string is entered in elementary entry. In this patch, I've tried to fix the above bugs. It works well when I tested. Would you please review this patch? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix the bug that user cannot input key
At this moment, space is processed in case of WM_KEYDOWN and WM_CHAR. Therefore, 'space' key is processed twice, it makes bug. In previous my patch, I changed keyname and string wrong. I send the revised patch again. Would you please review again? -Original Message- From: Carsten Haitzler (The Rasterman) [mailto:ras...@rasterman.com] Sent: Monday, October 31, 2011 12:28 PM To: Enlightenment developer list Cc: Jihoon Kim Subject: Re: [E-devel] [PATCH] Fix the bug that user cannot input key On Fri, 28 Oct 2011 21:03:49 +0900 Jihoon Kim jihoon48@samsung.com said: i don't think this is right. this means u get 2 key press events, with with key string, one without... :( Hi, EFL developers and Vincent. On Windows 7, there are some bugs related to key input in elementary_test. 1. alphabet and symbol characters doesn't be inputted in elementary entry. 2. When the space key is pressed, space string is entered in elementary entry. In this patch, I've tried to fix the above bugs. It works well when I tested. Would you please review this patch? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com Index: src/lib/ecore_win32/ecore_win32.c === --- src/lib/ecore_win32/ecore_win32.c (revision 64494) +++ src/lib/ecore_win32/ecore_win32.c (working copy) @@ -86,10 +86,10 @@ _ecore_win32_window_procedure(HWND window, INF(keydown message); _ecore_win32_event_handle_key_press(data, 1); return 0; - /* case WM_CHAR: */ - /* INF(char message); */ - /* _ecore_win32_event_handle_key_press(data, 0); */ - /* return 0; */ + case WM_CHAR: + INF(char message); + _ecore_win32_event_handle_key_press(data, 0); + return 0; case WM_KEYUP: INF(keyup message); _ecore_win32_event_handle_key_release(data, 1); Index: src/lib/ecore_win32/ecore_win32_event.c === --- src/lib/ecore_win32/ecore_win32_event.c (revision 64494) +++ src/lib/ecore_win32/ecore_win32_event.c (working copy) @@ -798,11 +798,6 @@ _ecore_win32_event_keystroke_get(intkey, kc = KP_Delete; } break; - case VK_SPACE: - kn = space; - ks = space; - kc = space; - break; case VK_F1: kn = F1; ks = F1; @@ -994,7 +989,7 @@ _ecore_win32_event_char_get(intkey, case VK_SPACE: strncpy(kn, space, 32); strncpy(ks, space, 32); - strncpy(kc, space, 32); + strncpy(kc, , 32); break; default: /* displayable characters */ -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix the bug that user cannot input key
On Mon, 31 Oct 2011 15:46:35 +0900 Jihoon Kim jihoon48@samsung.com said: i am wondering if we still need utf-=16 conversion? i think this works for conversions to ascii but things like Ö are not goign to turn out well. right now it works only because the key integer (which really is the first char of a utf16 string - right?) when converted to a char fits inside the ascii range. :) (in _ecore_win32_event_char_get()) At this moment, space is processed in case of WM_KEYDOWN and WM_CHAR. Therefore, 'space' key is processed twice, it makes bug. In previous my patch, I changed keyname and string wrong. I send the revised patch again. Would you please review again? -Original Message- From: Carsten Haitzler (The Rasterman) [mailto:ras...@rasterman.com] Sent: Monday, October 31, 2011 12:28 PM To: Enlightenment developer list Cc: Jihoon Kim Subject: Re: [E-devel] [PATCH] Fix the bug that user cannot input key On Fri, 28 Oct 2011 21:03:49 +0900 Jihoon Kim jihoon48@samsung.com said: i don't think this is right. this means u get 2 key press events, with with key string, one without... :( Hi, EFL developers and Vincent. On Windows 7, there are some bugs related to key input in elementary_test. 1. alphabet and symbol characters doesn't be inputted in elementary entry. 2. When the space key is pressed, space string is entered in elementary entry. In this patch, I've tried to fix the above bugs. It works well when I tested. Would you please review this patch? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix the bug that user cannot input key
On Mon, 31 Oct 2011 15:46:35 +0900 Jihoon Kim jihoon48@samsung.com said: utf-16 issue still there :( At this moment, space is processed in case of WM_KEYDOWN and WM_CHAR. Therefore, 'space' key is processed twice, it makes bug. In previous my patch, I changed keyname and string wrong. I send the revised patch again. Would you please review again? -Original Message- From: Carsten Haitzler (The Rasterman) [mailto:ras...@rasterman.com] Sent: Monday, October 31, 2011 12:28 PM To: Enlightenment developer list Cc: Jihoon Kim Subject: Re: [E-devel] [PATCH] Fix the bug that user cannot input key On Fri, 28 Oct 2011 21:03:49 +0900 Jihoon Kim jihoon48@samsung.com said: i don't think this is right. this means u get 2 key press events, with with key string, one without... :( Hi, EFL developers and Vincent. On Windows 7, there are some bugs related to key input in elementary_test. 1. alphabet and symbol characters doesn't be inputted in elementary entry. 2. When the space key is pressed, space string is entered in elementary entry. In this patch, I've tried to fix the above bugs. It works well when I tested. Would you please review this patch? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA cleanup session
On 30/10/11 18:46, Christopher Michael wrote: No worries ;) No insults taken :) Was just clarifying that screenshot is not deprecated (at least until E's shot module gets some of the missing features) :) Cool. :) Ahhh, well who knows what nonsense was being spilled out there ;) Yeah, those bastards shouldn't be trusted. -- Tom. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor trunk/E-MODULES-EXTRA/notification/src
On 31/10/11 01:23, Joerg Sonnenberger wrote: Actually, a good implementation of strncmp and strcmp will do the same if alignment permits. Please read closely, we are comparing strncmp vs memcmp, not strcmp. And in that case, as I said in my previous post, they are not the same. -- Tom. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA cleanup session
On 30/10/11 21:19, Michael Jennings wrote: I, too, am forced to have both tclock and the default clock visible because there's no way to configure the default clock to display the date at all times. No, a popup is NOT acceptable. That changed ages ago, my default clock shows the date... -- Tom. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elm_map: add image loading error handling
If it is NULL, it just returns -1.
Because ecore_file_remove() func. uses linux remove() func.
On error, remove() func just returns -1.
and return value is not needed.
From: Sanjeev as2902.b@sa... -2011-10-31 06:25
What happens when gi-file is NULL ?
-Original Message-
From: Bluezery [mailto:ohpowel@...]
Sent: 31 October 2011 14:54
To: enlightenment-devel@...
Subject: [E-devel] [Patch] elm_map: add image loading error handling
Dear all
I made a bug fix for elm_map.
When a downloaded image has an error, , elm_map removes a file and goes on
just like download succeeded .
However, it is not success, so it should be marked as FALSE for later retry.
Can anyone review this simple patch? :)
Index: elm_map.c
===
--- elm_map.c (리비전 64538)
+++ elm_map.c (작업 사본)
@@ -1186,7 +1186,12 @@ _tile_update(Grid_Item *gi)
gi-download = EINA_FALSE;
evas_object_image_file_set(gi-img, gi-file, NULL);
if (evas_object_image_load_error_get(gi-img) != EVAS_LOAD_ERROR_NONE)
- ecore_file_remove(gi-file);
+ {
+WRN(Image loading error (%s), gi-file);
+ecore_file_remove(gi-file);
+gi-have = EINA_FALSE;
+return;
+ }
obj_rotate_zoom(gi-wd-obj, gi-img);
evas_object_show(gi-img);
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: woohyun trunk/elementary/src/lib
+ sd-still_in = 1;
Please use EINA_TRUE/FALSE
-Regards, Hermet-
-Original Message-
From: Enlightenment SVNlt;no-re...@enlightenment.orggt;
To: enlightenment-...@lists.sourceforge.net
Cc:
Sent: 11-10-31(월) 17:26:12
Subject: E SVN: woohyun trunk/elementary/src/lib
Log:
elementary/elm_widget : Focus should be moved by clicked not by
mouse_up. So modified about this.
Author: woohyun
Date: 2011-10-31 01:26:12 -0700 (Mon, 31 Oct 2011)
New Revision: 64548
Trac: http://trac.enlightenment.org/e/changeset/64548
Modified:
trunk/elementary/src/lib/elm_widget.c
Modified: trunk/elementary/src/lib/elm_widget.c
===
--- trunk/elementary/src/lib/elm_widget.c 2011-10-31 07:20:53 UTC (rev 64547)
+++ trunk/elementary/src/lib/elm_widget.c 2011-10-31 08:26:12 UTC (rev 64548)
@@ -114,6 +114,7 @@
Eina_Bool disabled : 1;
Eina_Bool is_mirrored : 1;
Eina_Bool mirrored_auto_mode : 1; /* This is TRUE by default */
+ Eina_Bool still_in : 1;
Eina_List *focus_chain;
Eina_List *event_cb;
@@ -244,14 +245,50 @@
}
static void
-_sub_obj_mouse_up(void *data __UNUSED__,
+_sub_obj_mouse_down(void *data,
+ Evas *e __UNUSED__,
+ Evas_Object *obj __UNUSED__,
+ void *event_info)
+{
+ Smart_Data *sd = data;
+ Evas_Event_Mouse_Down *ev = event_info;
+ if (!(ev-event_flags EVAS_EVENT_FLAG_ON_HOLD))
+ sd-still_in = 1;
+}
+
+static void
+_sub_obj_mouse_move(void *data,
+ Evas *e __UNUSED__,
+ Evas_Object *obj,
+ void *event_info)
+{
+ Smart_Data *sd = data;
+ Evas_Event_Mouse_Move *ev = event_info;
+ if (sd-still_in)
+ {
+ if (ev-event_flags EVAS_EVENT_FLAG_ON_HOLD)
+ sd-still_in = 0;
+ else
+ {
+ Evas_Coord x, y, w, h;
+ evas_object_geometry_get(obj, x, y, w, h);
+ if ((ev-cur.canvas.x lt; x) || (ev-cur.canvas.y lt; y) ||
+ (ev-cur.canvas.x = (x + w)) || (ev-cur.canvas.y = (y + h)))
+ sd-still_in = 0;
+ }
+ }
+}
+
+static void
+_sub_obj_mouse_up(void *data,
Evas *e __UNUSED__,
Evas_Object *obj,
- void *event_info)
+ void *event_info __UNUSED__)
{
- Evas_Event_Mouse_Up *ev = event_info;
- if (!(ev-event_flags EVAS_EVENT_FLAG_ON_HOLD))
- elm_widget_focus_mouse_up_handle(obj);
+ Smart_Data *sd = data;
+ if (sd-still_in)
+ elm_widget_focus_mouse_up_handle(obj);
+ sd-still_in = 0;
}
static void
@@ -1002,6 +1039,10 @@
}
evas_object_event_callback_del_full(sd-resize_obj, EVAS_CALLBACK_DEL,
_sub_obj_del, sd);
+ evas_object_event_callback_del_full(sd-resize_obj, EVAS_CALLBACK_MOUSE_DOWN,
+ _sub_obj_mouse_down, sd);
+ evas_object_event_callback_del_full(sd-resize_obj, EVAS_CALLBACK_MOUSE_MOVE,
+ _sub_obj_mouse_move, sd);
evas_object_event_callback_del_full(sd-resize_obj, EVAS_CALLBACK_MOUSE_UP,
_sub_obj_mouse_up, sd);
evas_object_smart_member_del(sd-resize_obj);
@@ -1025,6 +1066,10 @@
}
evas_object_event_callback_del_full(sobj, EVAS_CALLBACK_DEL,
_sub_obj_del, sd);
+ evas_object_event_callback_del_full(sobj, EVAS_CALLBACK_MOUSE_DOWN,
+ _sub_obj_mouse_down, sd);
+ evas_object_event_callback_del_full(sobj, EVAS_CALLBACK_MOUSE_MOVE,
+ _sub_obj_mouse_move, sd);
evas_object_event_callback_del_full(sobj, EVAS_CALLBACK_MOUSE_UP,
_sub_obj_mouse_up, sd);
evas_object_smart_member_del(sobj);
@@ -1049,6 +1094,10 @@
evas_object_smart_member_add(sobj, obj);
evas_object_event_callback_add(sobj, EVAS_CALLBACK_DEL,
_sub_obj_del, sd);
+ evas_object_event_callback_add(sobj, EVAS_CALLBACK_MOUSE_DOWN,
+ _sub_obj_mouse_down, sd);
+ evas_object_event_callback_add(sobj, EVAS_CALLBACK_MOUSE_MOVE,
+ _sub_obj_mouse_move, sd);
evas_object_event_callback_add(sobj, EVAS_CALLBACK_MOUSE_UP,
_sub_obj_mouse_up, sd);
_smart_reconfigure(sd);
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FOSDEM 2012
Hello. On Thu, 2011-10-27 at 13:13, Carsten Haitzler wrote: On Fri, 30 Sep 2011 16:25:47 +0200 Philippe Caseiro caseiro.phili...@gmail.com said: how many people would be willing to some to en e/efl specific econf - maybe if we schedule it for 2 days following fosdem for example? if we get some conference facilities etc. what i'd like to see here: 1. open invite to anyone who wants to attend 2. e developers or anyone involved in e in general giving presentations/demos/speeches. right now i think we'd manage 2 days of content at best and might have to live with a smallish budget - but we have to start somewhere. this would be open for both developers AND user to attend - or anyone else. invite people from fosdem to come if they want. Hello E devs. i'd like to do a quick canvas on how many people would like to attend to see if this is worth it? So we have some people. Enough to organize such an event? For people coming in by plane or need to take some days off work it would be good to know early if it will happen. :) Lets see what we would need: PROGRAM: o Presentations o Demos o Hands on hacking o Roadmap discussion This can all be prepared if date and location is fixed. If nobody else steps up I volunteer to organize the program part (please step up someone ;)). DATE: - o Two days following FOSDEM was suggested. o Makes sense as some people will already show up for FOSDEM and can just stay two days longer. o Other options? (Linuxcon in Barcelona could work but thats november) LOCATION: - o Biggest problem I would say. o What kind of facility would we need? o Conference hotel would be to expensive without sponsor. o Anyone knows some better facilities in Brussels? o Anyone living in Brussels or nearby who could take care of handling the location organization? Location is the hardest part. Without someone from Belgium, best directly in Brussels, who can handle this everything else would be mood. Sure, we might get a developer room at FOSDEM, but the chances are really small. Brainstorm and people power for the location is what we need now. Suggestions? regards Stefan Schmidt -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA cleanup session
tiling, e-tiling: do we need both? There are still some bugs in e-tiling I plan on fixing today or tomorrow. I never tested with dual-screens and it's known to be buggy. Tiling was not updated for years but maybe it is used as is. I started e-tiling because I wanted a different design. If no one steps in, it may be a good idea to remove it. -- Boris Faure -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FOSDEM 2012
I would be happy to help with whatever minimal time/resources I have. Demos and hands on hacking are a BIG YES. They linger on for longer time. I can make time for one demo app / use case. I am a bit concerned about having it right after one conference gets over, keeping in mind the attention span and energy levels of people. Better option would be to have an efl track - http://fosdem.org/2012/call_for_devrooms But the deadline is already over : 2011-10-27: Deadline for devroom requests And of course, the press is important too - to ensure sufficient coverage. Regards, Sanjeev -Original Message- From: Stefan Schmidt [mailto:ste...@datenfreihafen.org] Sent: 31 October 2011 19:09 To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] FOSDEM 2012 Hello. On Thu, 2011-10-27 at 13:13, Carsten Haitzler wrote: On Fri, 30 Sep 2011 16:25:47 +0200 Philippe Caseiro caseiro.phili...@gmail.com said: how many people would be willing to some to en e/efl specific econf - maybe if we schedule it for 2 days following fosdem for example? if we get some conference facilities etc. what i'd like to see here: 1. open invite to anyone who wants to attend 2. e developers or anyone involved in e in general giving presentations/demos/speeches. right now i think we'd manage 2 days of content at best and might have to live with a smallish budget - but we have to start somewhere. this would be open for both developers AND user to attend - or anyone else. invite people from fosdem to come if they want. Hello E devs. i'd like to do a quick canvas on how many people would like to attend to see if this is worth it? So we have some people. Enough to organize such an event? For people coming in by plane or need to take some days off work it would be good to know early if it will happen. :) Lets see what we would need: PROGRAM: o Presentations o Demos o Hands on hacking o Roadmap discussion This can all be prepared if date and location is fixed. If nobody else steps up I volunteer to organize the program part (please step up someone ;)). DATE: - o Two days following FOSDEM was suggested. o Makes sense as some people will already show up for FOSDEM and can just stay two days longer. o Other options? (Linuxcon in Barcelona could work but thats november) LOCATION: - o Biggest problem I would say. o What kind of facility would we need? o Conference hotel would be to expensive without sponsor. o Anyone knows some better facilities in Brussels? o Anyone living in Brussels or nearby who could take care of handling the location organization? Location is the hardest part. Without someone from Belgium, best directly in Brussels, who can handle this everything else would be mood. Sure, we might get a developer room at FOSDEM, but the chances are really small. Brainstorm and people power for the location is what we need now. Suggestions? regards Stefan Schmidt -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FOSDEM 2012
Hello. On Mon, 2011-10-31 at 19:39, Sanjeev wrote: I would be happy to help with whatever minimal time/resources I have. Good. :) Demos and hands on hacking are a BIG YES. They linger on for longer time. I can make time for one demo app / use case. That would be nice. Would you be available to show them off yourself or would someone else do this? I am a bit concerned about having it right after one conference gets over, keeping in mind the attention span and energy levels of people. Good point. But I think we have no other choice then piggy-backing with other conferences here. Getting a E conf started from scratch and motivate people to fly in just for this is a bit to much in one step. Best to give people two reasons to come in. :) About the energy levels. Yeah, people might be a bit tired after FOSDEM, but its only two days for each event. That should work ok IMHO. Better option would be to have an efl track - http://fosdem.org/2012/call_for_devrooms But the deadline is already over : 2011-10-27: Deadline for devroom requests It was requested by the french community already AFAIK. The problem with devrooms at FOSDEM is the high demand and low supply. They never have enough rooms and normally all are going to bigger projects. Not much one can do about. And of course, the press is important too - to ensure sufficient coverage. Agreed. _If_ we find a way to set this up it needs to be announced more widely then only as news on the e.org page. Getting some news pages the info might help. But thats all _after_ we find a location, date and enough people to make it happen. regards Stefan Schmidt -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FOSDEM 2012
On 10/31/2011 08:29 PM, Stefan Schmidt wrote: Hello. On Mon, 2011-10-31 at 19:39, Sanjeev wrote: I would be happy to help with whatever minimal time/resources I have. Good. :) Demos and hands on hacking are a BIG YES. They linger on for longer time. I can make time for one demo app / use case. That would be nice. Would you be available to show them off yourself or would someone else do this? I am open to both. I am a bit concerned about having it right after one conference gets over, keeping in mind the attention span and energy levels of people. Good point. But I think we have no other choice then piggy-backing with other conferences here. Getting a E conf started from scratch and motivate people to fly in just for this is a bit to much in one step. Best to give people two reasons to come in. :) About the energy levels. Yeah, people might be a bit tired after FOSDEM, but its only two days for each event. That should work ok IMHO. Better option would be to have an efl track - http://fosdem.org/2012/call_for_devrooms But the deadline is already over : 2011-10-27: Deadline for devroom requests It was requested by the french community already AFAIK. The problem with devrooms at FOSDEM is the high demand and low supply. They never have enough rooms and normally all are going to bigger projects. Not much one can do about. And of course, the press is important too - to ensure sufficient coverage. Agreed. _If_ we find a way to set this up it needs to be announced more widely then only as news on the e.org page. Getting some news pages the info might help. But thats all _after_ we find a location, date and enough people to make it happen. regards Stefan Schmidt -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FOSDEM 2012
On Mon, 31 Oct 2011, Stefan Schmidt wrote: Hello. On Thu, 2011-10-27 at 13:13, Carsten Haitzler wrote: On Fri, 30 Sep 2011 16:25:47 +0200 Philippe Caseiro caseiro.phili...@gmail.com said: how many people would be willing to some to en e/efl specific econf - maybe if we schedule it for 2 days following fosdem for example? if we get some conference facilities etc. what i'd like to see here: 1. open invite to anyone who wants to attend 2. e developers or anyone involved in e in general giving presentations/demos/speeches. right now i think we'd manage 2 days of content at best and might have to live with a smallish budget - but we have to start somewhere. this would be open for both developers AND user to attend - or anyone else. invite people from fosdem to come if they want. Hello E devs. i'd like to do a quick canvas on how many people would like to attend to see if this is worth it? So we have some people. Enough to organize such an event? For people coming in by plane or need to take some days off work it would be good to know early if it will happen. :) I won't be able to come after FOSDEM. I have to work on monday. Maybe update the wiki to list people who can come after FOSDEM Vincent Lets see what we would need: PROGRAM: o Presentations o Demos o Hands on hacking o Roadmap discussion This can all be prepared if date and location is fixed. If nobody else steps up I volunteer to organize the program part (please step up someone ;)). DATE: - o Two days following FOSDEM was suggested. o Makes sense as some people will already show up for FOSDEM and can just stay two days longer. o Other options? (Linuxcon in Barcelona could work but thats november) LOCATION: - o Biggest problem I would say. o What kind of facility would we need? o Conference hotel would be to expensive without sponsor. o Anyone knows some better facilities in Brussels? o Anyone living in Brussels or nearby who could take care of handling the location organization? Location is the hardest part. Without someone from Belgium, best directly in Brussels, who can handle this everything else would be mood. Sure, we might get a developer room at FOSDEM, but the chances are really small. Brainstorm and people power for the location is what we need now. Suggestions? regards Stefan Schmidt -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FOSDEM 2012
Hello. On Mon, 2011-10-31 at 12:57, Vincent Torri wrote: On Mon, 31 Oct 2011, Stefan Schmidt wrote: On Thu, 2011-10-27 at 13:13, Carsten Haitzler wrote: On Fri, 30 Sep 2011 16:25:47 +0200 Philippe Caseiro caseiro.phili...@gmail.com said: how many people would be willing to some to en e/efl specific econf - maybe if we schedule it for 2 days following fosdem for example? if we get some conference facilities etc. what i'd like to see here: 1. open invite to anyone who wants to attend 2. e developers or anyone involved in e in general giving presentations/demos/speeches. right now i think we'd manage 2 days of content at best and might have to live with a smallish budget - but we have to start somewhere. this would be open for both developers AND user to attend - or anyone else. invite people from fosdem to come if they want. Hello E devs. i'd like to do a quick canvas on how many people would like to attend to see if this is worth it? So we have some people. Enough to organize such an event? For people coming in by plane or need to take some days off work it would be good to know early if it will happen. :) I won't be able to come after FOSDEM. I have to work on monday. Maybe update the wiki to list people who can come after FOSDEM Would be nice. Still I would someone to enlight me how to register at the wiki. I still can only find a login but no register button. Neither an edit button (maybe onlky available when logged in). Is there some magic I'm missing? regards Stefan Schmidt -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FOSDEM 2012
On Mon, 31 Oct 2011, Stefan Schmidt wrote: Hello. On Mon, 2011-10-31 at 12:57, Vincent Torri wrote: On Mon, 31 Oct 2011, Stefan Schmidt wrote: On Thu, 2011-10-27 at 13:13, Carsten Haitzler wrote: On Fri, 30 Sep 2011 16:25:47 +0200 Philippe Caseiro caseiro.phili...@gmail.com said: how many people would be willing to some to en e/efl specific econf - maybe if we schedule it for 2 days following fosdem for example? if we get some conference facilities etc. what i'd like to see here: 1. open invite to anyone who wants to attend 2. e developers or anyone involved in e in general giving presentations/demos/speeches. right now i think we'd manage 2 days of content at best and might have to live with a smallish budget - but we have to start somewhere. this would be open for both developers AND user to attend - or anyone else. invite people from fosdem to come if they want. Hello E devs. i'd like to do a quick canvas on how many people would like to attend to see if this is worth it? So we have some people. Enough to organize such an event? For people coming in by plane or need to take some days off work it would be good to know early if it will happen. :) I won't be able to come after FOSDEM. I have to work on monday. Maybe update the wiki to list people who can come after FOSDEM Would be nice. Still I would someone to enlight me how to register at the wiki. I still can only find a login but no register button. Neither an edit button (maybe onlky available when logged in). Is there some magic I'm missing? it seems that the link has disappeared :) i've asked in IRC about restoring it Vincent -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
Hi, I'm not responding to the entire thread because it's pointless... only one thing below. On Sun, Oct 30, 2011 at 10:26 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 14:41:44 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Sunday, October 30, 2011, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 11:56:07 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: Sorry David, but what we are trying to show is that we have a psychological problem. Going code to solve the technical problem is not solving the worst one, the psychological. At IRC we also talked about the shameful behavior post 1.0 EFL. We did a release since the technical details were over, yet we failed to overcome the psychological problem and no releases after it. Even tho major bugs were fixed (stable bugfix) and great amount of features were done (new release). you must. have a blindfold on. you are blinkered. http://www.enlightenment.org/p.php?p=news jan 29 - efl 1.0 may 25 - efl 1.0.1 aug 5 - eeze 1.0.2 and right now we are in merge window for 1.1 - did you not read my email to e-devel about it? apparently not. I did, yet it should have been done months ago, not now. at this point you lost all credibility. you said no releases. i quoted our own release announcements and you STILL stick to your line. WHY should 1.1 have been done months ago? what amazing world changing thing would it have accomplished? what DID YOU DO TO TRY MAKE IT HAPPEN? let me look at time gap between releases of qt 4.6 and 4.7 ... GOSH!! 12/2009 vs 9/2010. 9 months! oh look... we have almost exactly the same gap! sure they did 4.6.1/2/3/4 in between, and we only did 1.0.1. but now... we're obviously WRONG and must release much earlier! you have not given 1 sensible piece of information as to why we all of a SUDDEN must do a release in the next 2 months. what world changing event will happen that if we miss it will kill us forever so that we must drop everything we are doing? why should we suddenly drop the plans that exist? how are YOU going to help (if you have already given up and are so demotivated you won't help anyway)? why should those left doing work dance to the tune of those sitting in their armchairs? What you seem to be missing is not that we want the thing to be suddenly released. We should be discussing whether releasing in a timely fashion would be better for the project than the current not-written-anywhere plan of releasing when a a TODO list is done. What several projects are using this days is to set a date and a TODO list; if the features are not ready when the stabilization period arrives, the features are dropped and postponed to another release. Another scheme that some projects use is release-vry-often... this is what is used in systemd/udev/bluez/connman for example. Both the approaches above have the benefit that Distros can package recent versions rather than a 1 year old library that sw are not using anymore. Distros will only package lib/sw that is released. If we take too long to release, software written using EFL will very often depend on svn versions. Take WebKit-EFL for example... every time we receive complaints of WebKit-EFL not compiling we have to say humn... you have to use EFL from svn. Regarding e 0.17 I'm really demotivated to do anything. It's taking long to be release and next version will be a major rewrite to use elm and/or script languages... why bother writing anything that will be dropped on next release? Regards, Lucas De Marchi -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Mon, 31 Oct 2011, Lucas De Marchi wrote: Hi, I'm not responding to the entire thread because it's pointless... only one thing below. On Sun, Oct 30, 2011 at 10:26 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 14:41:44 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Sunday, October 30, 2011, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 11:56:07 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: Sorry David, but what we are trying to show is that we have a psychological problem. Going code to solve the technical problem is not solving the worst one, the psychological. At IRC we also talked about the shameful behavior post 1.0 EFL. We did a release since the technical details were over, yet we failed to overcome the psychological problem and no releases after it. Even tho major bugs were fixed (stable bugfix) and great amount of features were done (new release). you must. have a blindfold on. you are blinkered. http://www.enlightenment.org/p.php?p=news jan 29 - efl 1.0 may 25 - efl 1.0.1 aug 5 - eeze 1.0.2 and right now we are in merge window for 1.1 - did you not read my email to e-devel about it? apparently not. I did, yet it should have been done months ago, not now. at this point you lost all credibility. you said no releases. i quoted our own release announcements and you STILL stick to your line. WHY should 1.1 have been done months ago? what amazing world changing thing would it have accomplished? what DID YOU DO TO TRY MAKE IT HAPPEN? let me look at time gap between releases of qt 4.6 and 4.7 ... GOSH!! 12/2009 vs 9/2010. 9 months! oh look... we have almost exactly the same gap! sure they did 4.6.1/2/3/4 in between, and we only did 1.0.1. but now... we're obviously WRONG and must release much earlier! you have not given 1 sensible piece of information as to why we all of a SUDDEN must do a release in the next 2 months. what world changing event will happen that if we miss it will kill us forever so that we must drop everything we are doing? why should we suddenly drop the plans that exist? how are YOU going to help (if you have already given up and are so demotivated you won't help anyway)? why should those left doing work dance to the tune of those sitting in their armchairs? What you seem to be missing is not that we want the thing to be suddenly released. We should be discussing whether releasing in a timely fashion would be better for the project than the current not-written-anywhere plan of releasing when a a TODO list is done. What several projects are using this days is to set a date and a TODO list; if the features are not ready when the stabilization period arrives, the features are dropped and postponed to another release. Another scheme that some projects use is release-vry-often... this is what is used in systemd/udev/bluez/connman for example. Both the approaches above have the benefit that Distros can package recent versions rather than a 1 year old library I think that it is a good point. Let's see what we will do after the 1.1 release. Maybe someone who will be the release manager. If I'm not mistaken, several projects use one different maitainer for each release, so that not only one person is in charge of this big task. that sw are not using anymore. Distros will only package lib/sw that is released. If we take too long to release, software written using EFL will very often depend on svn versions. Take WebKit-EFL for example... every time we receive complaints of WebKit-EFL not compiling we have to say humn... you have to use EFL from svn. Regarding e 0.17 I'm really demotivated to do anything. It's taking long to be release and next version will be a major rewrite to use elm and/or script languages... why bother writing anything that will be dropped on next release? If I'm not mistaken, e18 will not be a complete rewrite of e17, but an enhancement of e17. So I think that knowing e17 will help in coding in e18. regards Vincent -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Small patch with ecore_con_url.
Hello.
When I tested with elementary map, there is too many logs on console.
It makes me difficult to distinguish normal logs that I want to debug. :'-(
It's libcurl's internal log for representing progress bar like this.
-
downloaded : 343 / 363
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 362
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 361
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 344 / 365
downloaded : 345 / 365
downloaded : 346 / 365
downloaded : 347 / 365
-
So, I want to remove this log.
And I look around ecore_con_url's code.
Then I found solution for it.
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (revision 64559)
+++ src/lib/ecore_con/ecore_con_url.c (working copy)
@@ -355,6 +355,7 @@
// FIXME: For an unknown reason, progress continue to arrive after
destruction
// this prevent any further call to the callback.
curl_easy_setopt(url_con-curl_easy, CURLOPT_PROGRESSFUNCTION,
NULL);
+curl_easy_setopt(url_con-curl_easy, CURLOPT_NOPROGRESS,
EINA_TRUE);
if (url_con-active)
{
When ecore_con_url goes to finalize, ecore_con_url remove its own progress
function from libcurl.
But final progress function is called in libcurl, and if there is no
progress function libcurl print out internal progress log message.
Anyway as you seen above, it's useless!!
So I set libcurl option CURLOPT_NOPROGRESS, and it makes that be printed
out no more progress log.
Please review this simple patch, and commit in SVN.
Thanks!
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Small patch with ecore_con_url.
Ooops. I forgot to attach patch file. :-)
On Mon, Oct 31, 2011 at 11:13 PM, Kim Yunhan spb...@gmail.com wrote:
Hello.
When I tested with elementary map, there is too many logs on console.
It makes me difficult to distinguish normal logs that I want to debug. :'-(
It's libcurl's internal log for representing progress bar like this.
-
downloaded : 343 / 363
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 362
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 361
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 344 / 365
downloaded : 345 / 365
downloaded : 346 / 365
downloaded : 347 / 365
-
So, I want to remove this log.
And I look around ecore_con_url's code.
Then I found solution for it.
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (revision 64559)
+++ src/lib/ecore_con/ecore_con_url.c (working copy)
@@ -355,6 +355,7 @@
// FIXME: For an unknown reason, progress continue to arrive
after destruction
// this prevent any further call to the callback.
curl_easy_setopt(url_con-curl_easy, CURLOPT_PROGRESSFUNCTION,
NULL);
+curl_easy_setopt(url_con-curl_easy, CURLOPT_NOPROGRESS,
EINA_TRUE);
if (url_con-active)
{
When ecore_con_url goes to finalize, ecore_con_url remove its own progress
function from libcurl.
But final progress function is called in libcurl, and if there is no
progress function libcurl print out internal progress log message.
Anyway as you seen above, it's useless!!
So I set libcurl option CURLOPT_NOPROGRESS, and it makes that be printed
out no more progress log.
Please review this simple patch, and commit in SVN.
Thanks!
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (revision 64559)
+++ src/lib/ecore_con/ecore_con_url.c (working copy)
@@ -355,6 +355,7 @@
// FIXME: For an unknown reason, progress continue to arrive after
destruction
// this prevent any further call to the callback.
curl_easy_setopt(url_con-curl_easy, CURLOPT_PROGRESSFUNCTION, NULL);
+curl_easy_setopt(url_con-curl_easy, CURLOPT_NOPROGRESS, EINA_TRUE);
if (url_con-active)
{
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Edje lua color_class AND text_class functions.
On Mon, 31 Oct 2011 15:09:33 +1000 David Seikel onef...@gmail.com wrote: So try this one instead. It works. B-) Now here is a patch for text_class, it includes the last one. Next I'll work on accessing edje parts in other groups, to set their text and state at least. Coz I need it, and coz raster said that's one of the goals of lua script only groups. The API I'm thinking of might look something like this - edje.[my/group/name].my_part.state.default[1.0].text.text = Some text.; shown = edje.[edje/group/name].my_part.state.default[1.0].visible; edje.[my/group/name].my_part.state:state_set(other_state, 1.0); I've experimented with this a bit already. There is a bit of a problem. The lua developers say that arrays start at one. In reality - Tables are associative arrays, that may have any type or value as a key, except nil. Tables with keys that are positive integers greater than 0 are treated syntactically as arrays. There are some functions that deal with them that way. Here's the kicker - Tables with numeric keys that are equal to 0 only work sometimes. Sometimes they are just keys can be anything, and work fine. Other times lua thinks Hey, this is an integer, and you can't have an integer key of 0, coz arrays start at 1. And btw, in lua 0 and 0.0 are the same. There really is no integer type. The reason why this is important - in the above examples of API, I used state.default[1.0] coz state.default[0.0] or even state.default[0] don't work. And since edje state indexes are between 0.0, and 1.0, as well as the requirement for every part to have at least default 0.0, we gotta deal with zeros in a language that does not like them. So we gotta add 1. sigh Might be better off just treating them like strings, state.default[0.0]. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jaehwan IN trunk/edje/src: bin lib
On 31/10/11 16:14, Cedric BAIL wrote: Let me grumbl a little ! You should never again commit a patch that does change indentation and behaviour at the same time. It make it almost impossible to understand what is going on ! I can't review your change without reading the code once the patch is applied and trying to understand what change you did. That's very very bad. Please consider reverting this patch, in case this patch will ever insert bugs it'll be terribly annoying to review it in the future. Reverting and committing cleaner split patches is preferable. -- Tom. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FOSDEM 2012
Hello. On Mon, 2011-10-31 at 13:23, Vincent Torri wrote: On Mon, 31 Oct 2011, Stefan Schmidt wrote: I won't be able to come after FOSDEM. I have to work on monday. Maybe update the wiki to list people who can come after FOSDEM Would be nice. Still I would someone to enlight me how to register at the wiki. I still can only find a login but no register button. Neither an edit button (maybe onlky available when logged in). Is there some magic I'm missing? it seems that the link has disappeared :) Some magic fingers fixed it. Thanks. I updated the page with a section about the potential E Conf. regards Stefan Schmidt -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Edje lua color_class AND text_class functions.
On Tue, 1 Nov 2011 00:14:08 +1000 David Seikel onef...@gmail.com
wrote:
On Mon, 31 Oct 2011 15:09:33 +1000 David Seikel onef...@gmail.com
wrote:
So try this one instead. It works. B-)
Now here is a patch for text_class, it includes the last one.
Spent so much time writing that, I forgot to actually attach the
patch. lol
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
Index: ChangeLog
===
--- ChangeLog (revision 64519)
+++ ChangeLog (working copy)
@@ -175,3 +175,12 @@
2011-10-03 Tom Hacohen (TAsn)
* Entry: Added change information to entry,changed,user
+
+2011-10-30 David Seikel (onefang)
+
+ * Lua: Added color_class function.
+
+2011-10-31 David Seikel (onefang)
+
+ * Lua: Added text_class function.
+
Index: src/lib/edje_lua2.c
===
--- src/lib/edje_lua2.c (revision 64519)
+++ src/lib/edje_lua2.c (working copy)
@@ -84,6 +84,9 @@
static int _elua_objsize(lua_State *L);
static int _elua_objgeom(lua_State *L);
+static int _elua_color_class(lua_State *L);
+static int _elua_text_class(lua_State *L);
+
static int _elua_show(lua_State *L);
static int _elua_hide(lua_State *L);
static int _elua_visible(lua_State *L);
@@ -172,8 +175,9 @@
{size, _elua_objsize}, // get while edje object pos in canvas
{geom, _elua_objgeom}, // get while edje object geometry in canvas
- // FIXME: query color classes
- // FIXME: query text classes
+ // set and query color / text class
+ {color_class,_elua_color_class},
+ {text_class, _elua_text_class},
{rect, _elua_rect}, // new rect
// FIXME: need image(filled, normal), text, textblock, edje
@@ -1213,6 +1217,63 @@
return n;
}
+// FIXME: Should have separate functions for each lua type, instead of these multi argument style ones.
+static int
+_elua_str_int_get(lua_State *L, int i, Eina_Bool tr,
+const char *n1, char **v1,
+const char *n2, int *v2
+ )
+{
+ int n = 0;
+
+ if (lua_istable(L, i))
+ {
+lua_getfield(L, i, n1);
+if (lua_isnil(L, -1))
+ {
+ lua_pop(L, 1);
+ lua_rawgeti(L, i, 1);
+ lua_rawgeti(L, i, 2);
+ }
+else
+ lua_getfield(L, i, n2);
+if ((!lua_isnil(L, -1)) (!lua_isnil(L, -2)))
+ {
+ size_t len;
+ const char *temp = lua_tolstring(L, -2, len);
+
+ len++; // Cater for the null at the end.
+ *v1 = malloc(len);
+ if (*v1)
+ {
+ memcpy(*v1, temp, len);
+ *v2 = lua_tointeger(L, -1);
+ n = 1;
+ }
+ }
+if (tr) lua_settop(L, i);
+ }
+ else
+ {
+if ((lua_isstring(L, i + 0)) (lua_isnumber(L, i + 1)))
+ {
+ size_t len;
+ const char *temp = lua_tolstring(L, i + 0, len);
+
+ len++; // Cater for the null at the end.
+ *v1 = malloc(len);
+ if (*v1)
+ {
+ memcpy(*v1, temp, len);
+ *v2 = lua_tointeger(L, i + 1);
+ n = 2;
+ }
+ }
+if (tr) lua_newtable(L);
+ }
+ return n;
+}
+
/* XXX: not used
static int
_elua_3_int_get(lua_State *L, int i, Eina_Bool tr,
@@ -1327,6 +1388,14 @@
}
static void
+_elua_str_ret(lua_State *L, const char *n, const char *v)
+{
+ lua_pushstring(L, n);
+ lua_pushstring(L, v);
+ lua_settable(L, -3);
+}
+
+static void
_elua_color_fix(int *r, int *g, int *b, int *a)
{
if (*r *a) *r = *a;
@@ -1338,6 +1407,65 @@
//-
static int
+_elua_color_class(lua_State *L)
+{
+ Edje *ed = (Edje *)_elua_table_ptr_get(L, _elua_key);
+ Edje_Color_Class *c_class;
+ const char *class = luaL_checkstring(L, 1);
+ int r, g, b, a;
+
+ if (!class) return 0;
+
+ if (_elua_4_int_get(L, 2, EINA_TRUE, r, r, g, g, b, b, a, a) 0)
+ {
+_elua_color_fix(r, g, b, a);
+// This is the way that embryo does it -
+//edje_object_color_class_set(ed-obj, class, r, g, b, a, r, g, b, a, r, g, b, a);
+// But that deals with object scope, which is currently useless in lua,
+// since we have no objects that can use color_class yet.
+// So we do it at global scope instead.
+// LATER - Should do both?
+edje_color_class_set(class, r, g, b, a, r, g, b, a, r, g, b, a);
+ }
+
+ c_class = _edje_color_class_find(ed, class);
+ if (!c_class) return 0;
+
+ _elua_int_ret(L, r, c_class-r);
+ _elua_int_ret(L, g, c_class-g);
+ _elua_int_ret(L, b, c_class-b);
+ _elua_int_ret(L, a, c_class-a);
+ return 1;
+}
+
+static int
+_elua_text_class(lua_State *L)
+{
+ Edje *ed = (Edje
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 2:59 PM, Vincent Torri vto...@univ-evry.fr wrote: On Mon, 31 Oct 2011, Lucas De Marchi wrote: Hi, I'm not responding to the entire thread because it's pointless... only one thing below. On Sun, Oct 30, 2011 at 10:26 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 14:41:44 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Sunday, October 30, 2011, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 11:56:07 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: Sorry David, but what we are trying to show is that we have a psychological problem. Going code to solve the technical problem is not solving the worst one, the psychological. At IRC we also talked about the shameful behavior post 1.0 EFL. We did a release since the technical details were over, yet we failed to overcome the psychological problem and no releases after it. Even tho major bugs were fixed (stable bugfix) and great amount of features were done (new release). you must. have a blindfold on. you are blinkered. http://www.enlightenment.org/p.php?p=news jan 29 - efl 1.0 may 25 - efl 1.0.1 aug 5 - eeze 1.0.2 and right now we are in merge window for 1.1 - did you not read my email to e-devel about it? apparently not. I did, yet it should have been done months ago, not now. at this point you lost all credibility. you said no releases. i quoted our own release announcements and you STILL stick to your line. WHY should 1.1 have been done months ago? what amazing world changing thing would it have accomplished? what DID YOU DO TO TRY MAKE IT HAPPEN? let me look at time gap between releases of qt 4.6 and 4.7 ... GOSH!! 12/2009 vs 9/2010. 9 months! oh look... we have almost exactly the same gap! sure they did 4.6.1/2/3/4 in between, and we only did 1.0.1. but now... we're obviously WRONG and must release much earlier! you have not given 1 sensible piece of information as to why we all of a SUDDEN must do a release in the next 2 months. what world changing event will happen that if we miss it will kill us forever so that we must drop everything we are doing? why should we suddenly drop the plans that exist? how are YOU going to help (if you have already given up and are so demotivated you won't help anyway)? why should those left doing work dance to the tune of those sitting in their armchairs? What you seem to be missing is not that we want the thing to be suddenly released. We should be discussing whether releasing in a timely fashion would be better for the project than the current not-written-anywhere plan of releasing when a a TODO list is done. What several projects are using this days is to set a date and a TODO list; if the features are not ready when the stabilization period arrives, the features are dropped and postponed to another release. Another scheme that some projects use is release-vry-often... this is what is used in systemd/udev/bluez/connman for example. Both the approaches above have the benefit that Distros can package recent versions rather than a 1 year old library I think that it is a good point. Let's see what we will do after the 1.1 release. Maybe someone who will be the release manager. I agree with you Vincent, I have already stepped on doing the minor release. I thing I can continue to do so for 1.1.x branch. But the futur of this branch depend onn wether we switch on a time based release or not. If I'm not mistaken, several projects use one different maitainer for each release, so that not only one person is in charge of this big task. Yes, and I thing it's a good idea. I don't think that it's needed that every time raster need to do it. We should just fix targeted month and ask if someone want to step in for that release. At least that wouldn't put that much work always on the same person. that sw are not using anymore. Distros will only package lib/sw that is released. If we take too long to release, software written using EFL will very often depend on svn versions. Take WebKit-EFL for example... every time we receive complaints of WebKit-EFL not compiling we have to say humn... you have to use EFL from svn. Regarding e 0.17 I'm really demotivated to do anything. It's taking long to be release and next version will be a major rewrite to use elm and/or script languages... why bother writing anything that will be dropped on next release? If I'm not mistaken, e18 will not be a complete rewrite of e17, but an enhancement of e17. So I think that knowing e17 will help in coding in e18. As far as we discussed what will be in e18, it's mostly change in the infrastructure, no big rewrite at all. So any work that is done on the TODO now will stay for some times in svn in my opinion. -- Cedric BAIL -- Get your Android app more play: Bring it to the
Re: [E-devel] E-MODULES-EXTRA cleanup session
On Mon, 31 Oct 2011 01:14:44 +1000 David Seikel onef...@gmail.com wrote: Oh, and last time I checked, one or more of these widgets would not update on month and year roll overs. Guess I'll know which ones tomorrow. For those playing along at home - it's the calendar module. The others clocked over the month fine. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Small patch with ecore_con_url.
On Mon, Oct 31, 2011 at 3:15 PM, Kim Yunhan spb...@gmail.com wrote:
Ooops. I forgot to attach patch file. :-)
On Mon, Oct 31, 2011 at 11:13 PM, Kim Yunhan spb...@gmail.com wrote:
Hello.
When I tested with elementary map, there is too many logs on console.
It makes me difficult to distinguish normal logs that I want to debug. :'-(
It's libcurl's internal log for representing progress bar like this.
-
downloaded : 343 / 363
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 362
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 361
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 344 / 365
downloaded : 345 / 365
downloaded : 346 / 365
downloaded : 347 / 365
-
So, I want to remove this log.
And I look around ecore_con_url's code.
Then I found solution for it.
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (revision 64559)
+++ src/lib/ecore_con/ecore_con_url.c (working copy)
@@ -355,6 +355,7 @@
// FIXME: For an unknown reason, progress continue to arrive
after destruction
// this prevent any further call to the callback.
curl_easy_setopt(url_con-curl_easy, CURLOPT_PROGRESSFUNCTION,
NULL);
+ curl_easy_setopt(url_con-curl_easy, CURLOPT_NOPROGRESS,
EINA_TRUE);
if (url_con-active)
{
When ecore_con_url goes to finalize, ecore_con_url remove its own progress
function from libcurl.
But final progress function is called in libcurl, and if there is no
progress function libcurl print out internal progress log message.
Anyway as you seen above, it's useless!!
So I set libcurl option CURLOPT_NOPROGRESS, and it makes that be printed
out no more progress log.
Please review this simple patch, and commit in SVN.
I think I already saw that patch, it did go in and was reverted,
because when you set noprogress, you don't receive progress
information and you can't propagate a progress event. Result you won't
be able to update a progress bar during download. It's super annoying,
I agree, but I never saw a patch that make this progress feature work
without the printf storm.
So if the progress is working, what I doubt, this patch could go in,
if not, it won't.
--
Cedric BAIL
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Small patch with ecore_con_url.
Yes!
I empathized what you worry about.
At the first time, I tried to set this option at the initialization time in
ecore_con_url.
Then as you mentioned, no more propagation is occurred! :'-(
So I looked around more deeply, then I change that this code is called at
its finalization time as you seen in patch file.
And to conclude, the progress is working!!
Thank you.
On Mon, Oct 31, 2011 at 11:31 PM, Cedric BAIL cedric.b...@free.fr wrote:
On Mon, Oct 31, 2011 at 3:15 PM, Kim Yunhan spb...@gmail.com wrote:
Ooops. I forgot to attach patch file. :-)
On Mon, Oct 31, 2011 at 11:13 PM, Kim Yunhan spb...@gmail.com wrote:
Hello.
When I tested with elementary map, there is too many logs on console.
It makes me difficult to distinguish normal logs that I want to debug.
:'-(
It's libcurl's internal log for representing progress bar like this.
-
downloaded : 343 / 363
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 362
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 361
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 344 / 365
downloaded : 345 / 365
downloaded : 346 / 365
downloaded : 347 / 365
-
So, I want to remove this log.
And I look around ecore_con_url's code.
Then I found solution for it.
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (revision 64559)
+++ src/lib/ecore_con/ecore_con_url.c (working copy)
@@ -355,6 +355,7 @@
// FIXME: For an unknown reason, progress continue to arrive
after destruction
// this prevent any further call to the callback.
curl_easy_setopt(url_con-curl_easy, CURLOPT_PROGRESSFUNCTION,
NULL);
+curl_easy_setopt(url_con-curl_easy, CURLOPT_NOPROGRESS,
EINA_TRUE);
if (url_con-active)
{
When ecore_con_url goes to finalize, ecore_con_url remove its own
progress
function from libcurl.
But final progress function is called in libcurl, and if there is no
progress function libcurl print out internal progress log message.
Anyway as you seen above, it's useless!!
So I set libcurl option CURLOPT_NOPROGRESS, and it makes that be printed
out no more progress log.
Please review this simple patch, and commit in SVN.
I think I already saw that patch, it did go in and was reverted,
because when you set noprogress, you don't receive progress
information and you can't propagate a progress event. Result you won't
be able to update a progress bar during download. It's super annoying,
I agree, but I never saw a patch that make this progress feature work
without the printf storm.
So if the progress is working, what I doubt, this patch could go in,
if not, it won't.
--
Cedric BAIL
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Small patch with ecore_con_url.
On Mon, Oct 31, 2011 at 3:49 PM, Kim Yunhan spb...@gmail.com wrote:
Yes!
I empathized what you worry about.
At the first time, I tried to set this option at the initialization time in
ecore_con_url.
Then as you mentioned, no more propagation is occurred! :'-(
So I looked around more deeply, then I change that this code is called at
its finalization time as you seen in patch file.
And to conclude, the progress is working!!
Oh, I missed that information, so sounds interesting to test then. I
can't at the moment, but as you have already investigated the problem
I just pointed, sounds good to go in svn then.
On Mon, Oct 31, 2011 at 11:31 PM, Cedric BAIL cedric.b...@free.fr wrote:
On Mon, Oct 31, 2011 at 3:15 PM, Kim Yunhan spb...@gmail.com wrote:
Ooops. I forgot to attach patch file. :-)
On Mon, Oct 31, 2011 at 11:13 PM, Kim Yunhan spb...@gmail.com wrote:
Hello.
When I tested with elementary map, there is too many logs on console.
It makes me difficult to distinguish normal logs that I want to debug.
:'-(
It's libcurl's internal log for representing progress bar like this.
-
downloaded : 343 / 363
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 362
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 361
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 344 / 365
downloaded : 345 / 365
downloaded : 346 / 365
downloaded : 347 / 365
-
So, I want to remove this log.
And I look around ecore_con_url's code.
Then I found solution for it.
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (revision 64559)
+++ src/lib/ecore_con/ecore_con_url.c (working copy)
@@ -355,6 +355,7 @@
// FIXME: For an unknown reason, progress continue to arrive
after destruction
// this prevent any further call to the callback.
curl_easy_setopt(url_con-curl_easy, CURLOPT_PROGRESSFUNCTION,
NULL);
+ curl_easy_setopt(url_con-curl_easy, CURLOPT_NOPROGRESS,
EINA_TRUE);
if (url_con-active)
{
When ecore_con_url goes to finalize, ecore_con_url remove its own
progress
function from libcurl.
But final progress function is called in libcurl, and if there is no
progress function libcurl print out internal progress log message.
Anyway as you seen above, it's useless!!
So I set libcurl option CURLOPT_NOPROGRESS, and it makes that be printed
out no more progress log.
Please review this simple patch, and commit in SVN.
I think I already saw that patch, it did go in and was reverted,
because when you set noprogress, you don't receive progress
information and you can't propagate a progress event. Result you won't
be able to update a progress bar during download. It's super annoying,
I agree, but I never saw a patch that make this progress feature work
without the printf storm.
So if the progress is working, what I doubt, this patch could go in,
if not, it won't.
--
Cedric BAIL
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Cedric BAIL
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153;
Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)
On Sat, Oct 29, 2011 at 8:08 PM, Vincent Torri vto...@univ-evry.fr wrote: On Sat, 29 Oct 2011, Cedric BAIL wrote: On Fri, Oct 28, 2011 at 4:45 PM, Vincent Torri vto...@univ-evry.fr wrote: On Fri, 28 Oct 2011, Cedric BAIL wrote: On Fri, Oct 28, 2011 at 2:13 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I agree with vincent, and I think that there shouldn't be a define it before including eina.h implicit rule.. while it's not so bad, and it would work, it's not the right way to do it. these functions shouldn't be inlined I think, they should be a define, and Using define instead of inline has a lot issue. First it doesn't let the compiler when it's better or not to inline, it will always inline. Second it doesn't do any type checking so you can break stuff much more easily. And generally inline is much more easy to read than define. for the posix functions, they are way too big to be inline, they would dramatically increase the generated code, especially if you lock/unlock everywhere. I actually don't understand what point your are trying to make here. As for performance, give us hard numbers! I don't think it would affect performance for such function calls. So in my opinion, make them defines, and have the posix versions as actual functions that the defines call (so for non posix with smaller functions, you don't need an actual call). What does matter is call to small function, because the overhead of setting up the stack, saving register, jumping to the actual function to call and then coming by restoring register and the stack does introduce a cost. Something you will not see on your high end laptop, but on embedded device. And the inline function are function that are typically in the hot path of our stack, so function call really do matter. And moving to #define would not solve the issue Vincent is pointing as far as I understand it. indeed. So, with the argument of Jorge, there are 2 problems. No, there is no such problem. The compiler flag will not change any behaviour in eina library or I really missed something and please show me example code. And as for giving header random order support I really don't think it's important and worth it. did you read my mail about the example with raster's habit of putting everything in a private header ? I mean, really read it ? You didn't give any answer to it... Yes, I did. And I still don't konw how to answer it, because I just agree with your point. I agree that's a bad habit, that it should be fixed and that your fix were right. And I think every one did as in so many year nobody reverted them. So I have nothing to argue with you about your argument at all, but you still see that as a bug, despite your argument. So I really don't know what to say or argue, as I just agree with your point. -- Cedric BAIL -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] conf_randr - A Randr dialog for e17
Hello. Just found some time to test out this patch against todays svn. A small conflict due to the addition of the taskbar happens during applying it. Trivial to fix. More interesting is a segfault when edje_cc builds the .edj. A backtrace points to ecore_mainloop and friends used for the SVG stuff. And indeed, converting the svg to png make edje_cc happy. (separate mail for the issue) On Wed, 2011-10-19 at 21:37, Leif Middelschulte wrote: find attached another version of the patch. It works here, but I don't have the ressources to test it properly. Known issues: Frontend (conf_randr): - not pushed into e/demodulized yet - dialog has to be resized manually for displays to be proper positioned Thats a bit confusing at the first time. The display should be changed to something vendor neutral btw. :) I only see one output here which seems to be the LVDS of my notebook. The external monitor connected over DVI and from xrandr detected as HDMI2 seems to be missing completely. Problems with EDID parsing or such? Where should I look for debug infos for this? The setup is a Lenove X220 with a docking station and one monitor connected over DVI. I can test with VGA the next days as well. xrandr is happy with detecting it and I'm able to set it up as multi-monitor with it. - segv when closing the dialog because of resize callback of the arrengement smart class are called after the dialog's data is freed Does not happen here. - missing icons for policies and orientations - missing policy for ask what to do on connection Backend (e_randr): - missing polling backend for events - setup storage seems to fail, but should be fixable soon(TM). The popup if one wants to keep the settings seems also to small. The second counter is not completely visible. The storage button did not trigger any event and keep and restore have been not always working for me. Besides that it looks quite nice. Need to find out why it does not detect my external monitor the next days. regards Stefan Schmidt -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] edje_cc segfault when compiling and edj with a SVG image
Hello.
While testing the conf_randr patch I noticed a problem with edje_cc.
It segfault when the edc contains a SVG image. Minimal test case looks
like this:
images {
image: video-display.svg COMP;
}
The actual edj gets produced, though. From the backtrace (see below)
it looks to me like a problem with ecore mainloop and glib while
shutting down _after_ the successful edj creation.
stefan@excalibur:~/Projekte/efl/edje-bug $ gdb --args /usr/local/bin/edje_cc -v
-id images -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4
-DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC e-module-conf_randr.edc
e-module-conf_randr.edj
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/local/bin/edje_cc...done.
(gdb) run
Starting program: /usr/local/bin/edje_cc -v -id images -DLOWRES_PDA=1
-DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6
-DE17_PROFILE=SLOW_PC e-module-conf_randr.edc e-module-conf_randr.edj
[Thread debugging using libthread_db enabled]
/usr/local/bin/edje_cc: Wrote94 bytes ( 0Kb) for edje_file header
/usr/local/bin/edje_cc: Wrote 8785 bytes ( 9Kb) for edje/images/0
image entry video-display.svg compress: [raw: 76.2%] [real: 77.8%]
Summary:
Wrote 0 collections
Wrote 1 images
Wrote 0 fonts
Wrote 115 bytes (0Kb) of original source data
Wrote 12 bytes (0Kb) of original source font map
Conservative compression summary:
Wrote total 9006 bytes (9Kb) from 39574 (39Kb) input data
Output file is 22.8% the size of the input data
Saved 30568 bytes (30Kb)
Raw compression summary:
Wrote total 9006 bytes (9Kb) from 36911 (36Kb) raw input data
Output file is 24.4% the size of the raw input data
Saved 27905 bytes (27Kb)
Program received signal SIGSEGV, Segmentation fault.
0x7fffede8c510 in ?? ()
(gdb) bt f
#0 0x7fffede8c510 in ?? ()
No symbol table info available.
#1 0x748e603a in g_slice_free1 () from /lib/libglib-2.0.so.0
No symbol table info available.
#2 0x748c6024 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#3 0x748c6154 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#4 0x775100b5 in _ecore_main_loop_shutdown () at ecore_main.c:796
No locals.
#5 0x7750a4cf in ecore_shutdown () at ecore.c:245
__FUNCTION__ = ecore_shutdown
#6 0x77bb352a in _edje_shutdown_core () at edje_main.c:136
No locals.
#7 0x77bb391d in _edje_shutdown_core () at edje_main.c:115
No locals.
#8 edje_shutdown () at edje_main.c:166
No locals.
#9 0x00403321 in main (argc=13, argv=optimized out) at edje_cc.c:239
i = optimized out
st = {st_dev = 65030, st_ino = 3294669, st_nlink = 1, st_mode = 33188,
st_uid = 1000,
st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 47, st_blksize =
4096, st_blocks = 8,
st_atim = {tv_sec = 1320090081, tv_nsec = 0}, st_mtim = {tv_sec =
1320090081,
tv_nsec = 0}, st_ctim = {tv_sec = 1320090081, tv_nsec = 0},
__unused = {0, 0, 0}}
rpath =
/home/stefan/Projekte/efl/edje-bug/e-module-conf_randr.edc\000\365\377\177\000\000P\301\377\377\377\177\000\000b\237\336\367\377\177\000\000\000\000\000\000\000\000\000\000\251\336\367\377\177\000\000\030\340\377\367\377\177\000\000\370\336\377\377\377\177\000\000\000\337\377\377\377\177\000\000\340\303\027\365\377\177\000\000x\027\374\367\377\177\000\000\025\221\336\367\377\177\000\000\350\364\374\367\377\177\000\000\330\344\374\367\377\177\000\000\340\324\374\367\377\177\000\000\300\331\374\367\377\177\000\000\000\000\000\000\000\000\000\000\340\244\374\367\377\177\000\000\004\000\000\000\000\000\000\000\241\336\027\365\377\177\000\000P\301\377\377\377\177\000\000\000\000@\200\377\377\377\377\000\000\026R\275\357\377\377\n\002\000\000\246\000\000\000\217\000\000\000g\001\000\000\037\000\000\000?\000\000\000\000\000\000\000\023\002\000\000#\000\000\000\000\000\000\000_\000\000\000\301\001\000\000\320\336\377\377\377\177\000\000...
rpath2 =
Re: [E-devel] edje_cc segfault when compiling and edj with a SVG image
On Mon, Oct 31, 2011 at 8:51 PM, Stefan Schmidt
ste...@datenfreihafen.org wrote:
Hello.
While testing the conf_randr patch I noticed a problem with edje_cc.
It segfault when the edc contains a SVG image. Minimal test case looks
like this:
images {
image: video-display.svg COMP;
}
The actual edj gets produced, though. From the backtrace (see below)
it looks to me like a problem with ecore mainloop and glib while
shutting down _after_ the successful edj creation.
stefan@excalibur:~/Projekte/efl/edje-bug $ gdb --args /usr/local/bin/edje_cc
-v -id images -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4
-DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC e-module-conf_randr.edc
e-module-conf_randr.edj
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/local/bin/edje_cc...done.
(gdb) run
Starting program: /usr/local/bin/edje_cc -v -id images -DLOWRES_PDA=1
-DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6
-DE17_PROFILE=SLOW_PC e-module-conf_randr.edc e-module-conf_randr.edj
[Thread debugging using libthread_db enabled]
/usr/local/bin/edje_cc: Wrote 94 bytes ( 0Kb) for edje_file header
/usr/local/bin/edje_cc: Wrote 8785 bytes ( 9Kb) for edje/images/0
image entry video-display.svg compress: [raw: 76.2%] [real: 77.8%]
Summary:
Wrote 0 collections
Wrote 1 images
Wrote 0 fonts
Wrote 115 bytes (0Kb) of original source data
Wrote 12 bytes (0Kb) of original source font map
Conservative compression summary:
Wrote total 9006 bytes (9Kb) from 39574 (39Kb) input data
Output file is 22.8% the size of the input data
Saved 30568 bytes (30Kb)
Raw compression summary:
Wrote total 9006 bytes (9Kb) from 36911 (36Kb) raw input data
Output file is 24.4% the size of the raw input data
Saved 27905 bytes (27Kb)
Program received signal SIGSEGV, Segmentation fault.
0x7fffede8c510 in ?? ()
(gdb) bt f
#0 0x7fffede8c510 in ?? ()
No symbol table info available.
#1 0x748e603a in g_slice_free1 () from /lib/libglib-2.0.so.0
No symbol table info available.
#2 0x748c6024 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#3 0x748c6154 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#4 0x775100b5 in _ecore_main_loop_shutdown () at ecore_main.c:796
No locals.
#5 0x7750a4cf in ecore_shutdown () at ecore.c:245
__FUNCTION__ = ecore_shutdown
#6 0x77bb352a in _edje_shutdown_core () at edje_main.c:136
No locals.
#7 0x77bb391d in _edje_shutdown_core () at edje_main.c:115
No locals.
#8 edje_shutdown () at edje_main.c:166
No locals.
#9 0x00403321 in main (argc=13, argv=optimized out) at
edje_cc.c:239
i = optimized out
st = {st_dev = 65030, st_ino = 3294669, st_nlink = 1, st_mode = 33188,
st_uid = 1000,
st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 47, st_blksize =
4096, st_blocks = 8,
st_atim = {tv_sec = 1320090081, tv_nsec = 0}, st_mtim = {tv_sec =
1320090081,
tv_nsec = 0}, st_ctim = {tv_sec = 1320090081, tv_nsec = 0},
__unused = {0, 0, 0}}
rpath =
/home/stefan/Projekte/efl/edje-bug/e-module-conf_randr.edc\000\365\377\177\000\000P\301\377\377\377\177\000\000b\237\336\367\377\177\000\000\000\000\000\000\000\000\000\000\251\336\367\377\177\000\000\030\340\377\367\377\177\000\000\370\336\377\377\377\177\000\000\000\337\377\377\377\177\000\000\340\303\027\365\377\177\000\000x\027\374\367\377\177\000\000\025\221\336\367\377\177\000\000\350\364\374\367\377\177\000\000\330\344\374\367\377\177\000\000\340\324\374\367\377\177\000\000\300\331\374\367\377\177\000\000\000\000\000\000\000\000\000\000\340\244\374\367\377\177\000\000\004\000\000\000\000\000\000\000\241\336\027\365\377\177\000\000P\301\377\377\377\177\000\000\000\000@\200\377\377\377\377\000\000\026R\275\357\377\377\n\002\000\000\246\000\000\000\217\000\000\000g\001\000\000\037\000\000\000?\000\000\000\000\000\000\000\023\002\000\000#\000\000\000\000\000\000\000_\000\000\000\301\001\000\000\320\336\377\377\377\177\000\000...
rpath2 =
Re: [E-devel] edje_cc segfault when compiling and edj with a SVG image
Hello. On Mon, 2011-10-31 at 21:04, Cedric BAIL wrote: Could you run it under valgrind and also give us the version of your librsvg ? Sure :) tefan@excalibur:~/Projekte/efl/edje-bug $ valgrind /usr/local/bin/edje_cc -v -id images -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC e-module-conf_randr.edc e-module-conf_randr.edj ==14677== Memcheck, a memory error detector ==14677== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==14677== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==14677== Command: /usr/local/bin/edje_cc -v -id images -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC e-module-conf_randr.edc e-module-conf_randr.edj ==14677== /usr/local/bin/edje_cc: Wrote94 bytes ( 0Kb) for edje_file header /usr/local/bin/edje_cc: Wrote 8785 bytes ( 9Kb) for edje/images/0 image entry video-display.svg compress: [raw: 76.2%] [real: 77.8%] Summary: Wrote 0 collections Wrote 1 images Wrote 0 fonts Wrote 115 bytes (0Kb) of original source data Wrote 12 bytes (0Kb) of original source font map Conservative compression summary: Wrote total 9006 bytes (9Kb) from 39574 (39Kb) input data Output file is 22.8% the size of the input data Saved 30568 bytes (30Kb) Raw compression summary: Wrote total 9006 bytes (9Kb) from 36911 (36Kb) raw input data Output file is 24.4% the size of the raw input data Saved 27905 bytes (27Kb) ==14677== Jump to the invalid address stated on the next line ==14677==at 0xEF54510: ??? ==14677==by 0x80F7039: g_slice_free1 (in /lib/libglib-2.0.so.0.2800.8) ==14677==by 0x80D7023: ??? (in /lib/libglib-2.0.so.0.2800.8) ==14677==by 0x80D7153: ??? (in /lib/libglib-2.0.so.0.2800.8) ==14677==by 0x54EA0B4: _ecore_main_loop_shutdown (ecore_main.c:796) ==14677==by 0x54E44CE: ecore_shutdown (ecore.c:245) ==14677==by 0x4E87529: _edje_shutdown_core.part.0 (edje_main.c:136) ==14677==by 0x4E8791C: edje_shutdown (edje_main.c:115) ==14677==by 0x403320: main (edje_cc.c:239) ==14677== Address 0xef54510 is not stack'd, malloc'd or (recently) free'd ==14677== ==14677== ==14677== Process terminating with default action of signal 11 (SIGSEGV) ==14677== Access not within mapped region at address 0xEF54510 ==14677==at 0xEF54510: ??? ==14677==by 0x80F7039: g_slice_free1 (in /lib/libglib-2.0.so.0.2800.8) ==14677==by 0x80D7023: ??? (in /lib/libglib-2.0.so.0.2800.8) ==14677==by 0x80D7153: ??? (in /lib/libglib-2.0.so.0.2800.8) ==14677==by 0x54EA0B4: _ecore_main_loop_shutdown (ecore_main.c:796) ==14677==by 0x54E44CE: ecore_shutdown (ecore.c:245) ==14677==by 0x4E87529: _edje_shutdown_core.part.0 (edje_main.c:136) ==14677==by 0x4E8791C: edje_shutdown (edje_main.c:115) ==14677==by 0x403320: main (edje_cc.c:239) ==14677== If you believe this happened as a result of a stack ==14677== overflow in your program's main thread (unlikely but ==14677== possible), you can try to increase the size of the ==14677== main thread stack using the --main-stacksize= flag. ==14677== The main thread stack size used in this run was 8388608. ==14677== ==14677== HEAP SUMMARY: ==14677== in use at exit: 143,670 bytes in 658 blocks ==14677== total heap usage: 19,494 allocs, 18,798 frees, 4,651,363 bytes allocated ==14677== ==14677== LEAK SUMMARY: ==14677==definitely lost: 10,064 bytes in 43 blocks ==14677==indirectly lost: 2,708 bytes in 80 blocks ==14677== possibly lost: 34,064 bytes in 73 blocks ==14677==still reachable: 79,298 bytes in 473 blocks ==14677== suppressed: 0 bytes in 0 blocks ==14677== Rerun with --leak-check=full to see details of leaked memory ==14677== ==14677== For counts of detected and suppressed errors, rerun with: -v ==14677== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 70 from 9) Segmentation fault System is debian unstable with librsvg version: ii librsvg2-2 2.34.1-3SAX-based renderer library for SVG files (runtime) Getting some sleep now. If you need a more verbose valgrind let me know. regards Stefan Schmidt -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Sat, Oct 29, 2011 at 11:23:37AM +0900, Carsten Haitzler wrote: On Fri, 28 Oct 2011 22:46:55 +0200 Cedric BAIL cedric.b...@free.fr said: i'll post here as a summary. what k-s wants is to just release e17-as is after fixing some efm bugs. who agrees with that? everything stays as-is. the reason xrandr is on the todo is that there are many complaints and questions about how to get multi screen to work and we have no solution. the reason taskbar is there is because engage is compositing based realistically and we have to work without, and we again have had enough users complain and ask for a way to switch tasks. the reason efm is on the list is its mostly working and usable as a simple filemanager - that was its point. it needs some bugs fixed. the reason keymap config is there is for all those europeans (and a few others) with odd keymaps and people have no clue how to configure this on a command-line or in config files. the other todo items could get dropped, though theme does need to be polished. this wasnt unilaterally decided by me. i believe in making a good attempt at a quality release. gustavo just believes in dumping out whatever we have. all the bitching about gnome and others will happen to us if we don't provide these basics that gnome etc. already DO. to many people we are useless. these are not new fangled ideas or standards - this is old hat that we haven't covered. so how do u expect to make those people happy and try or stay with e when we are not functional in some key aspects? get these above done and we can do an alpha. Sorry for getting into this discussion only as E user. E17 is already very well usable and stable. When I shown E to my colleagues at SUSE, they were surprised how fast and usable it is and three already switched their machines to that. Quality is already good for use (as it was 2 years ago when I tried E for the first time). I have never used EFM, I don't use taskbar, I use terminal for keymap configuration, I don't use composition and I don't use python or JS for programming using EFL (shellementary is more than I need). There are many window managers (I know it's not the same as desktop environment) which doesn't use features mentioned above and have many users. All mentioned above sounds to me more like extra features. Having snapshots is way to go for distributions as the code will be more tested than 'yes-it-boots' and help distribution package maintainers to do their job. It's far better than asking on IRC which revision can be considered as working... my little user's vote: make snapshots and stabilize code periodically On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz m...@zentific.com wrote: On Fri, 28 Oct 2011 11:07:45 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I'm writing this mail so it's unified and everyone can opine without being in one place at one time (IRC/#edevelop). Recently I've talked to people and while I tried to express it at IRC, raster just got pissed and left. Later people would join and agree with me... so while I'm looking like a jerk I guess I'm not alone in there. I'll try to be as clear and short as possible. WHY RELEASE? 1. to clarify we know some snapshot is usable. This will get us in more distributions by default. good 2. to remove that stupid karma over the 17 number if e. Will help people that do not track us closely to know we're reasonable serious. people will probably still call it e17 even when we're on e20 3. we can start to bring in new technology without delaying it even further (ie: elm and scripting language - js/elev8) not really a valid reason to release, you can see it did wonders for gnome http://www.phoronix.com/scan.php?page=articleitem=gnome_survey_part1num=1 I don't really see the link with what you are saying. WHY NOT RELEASE? 1. there are both bugs (eg: efm) cedric has said a number of times that he'll be working on efm after he finishes emotion soon, and I'll likely disable eeze mounting entirely for the release since libmount is not widely deployed and I was unable to get widespread testing until now. 2. missing features (xrandr, taskbar, ...) * xrandr patches have been made and are on the list waiting for testing and review, so I'm not really sure why this is a missing feature. * New users will not be able to deal with E17 if it doesn't have a taskbar, end of story. Engage is in SVN now, it's usable and widely used already, it can be merged. No you can't ! Doesn't solve the problem for non composite use case and as long as we don't make the compositer the only possible choice we can't say that engage is the answer to that problem. * I don't care about keymap config since I'm american, but it seems important for users to be able to type in their own language * bw is awful, we should switch to and iron out detourious for release Yes, that's something we should do as soon as possible. As a side question, what is the
Re: [E-devel] RFC: E17 Release
On Sun, Oct 30, 2011 at 9:58 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: i'm already working on taskbar. i've fixed horizontal sizing issues already. i need to fix theme up. t_unix has pending patches for xrandr multi-screen i have yet to look at - if someone wants a release them why not review those patches and try them out while i'm busy? otherwise this just takes longer. we can't set dates because so many people agree to do shit and then DONT DO IT.. in the end... i do most of it. look at: Ok that's cool, just let me know and I can stress test and report bugs on taskbar or any other module. I also need the multiscreen stuff, right now I have a script that uses xrandr, so I got the setup ready and I can test it for you. As for dates, yes, set a date, and if someone doesn't do shit, then too bad, the missing features will be missing features, it shouldn't mean a delay of another year. no - i'm not setting a date. i set a task list. Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to http://trac.enlightenment.org/e/wiki/Release of the list left the following could be dropped: * connman module ui improvement * config modules for missing e config vars the rest are not droppable. of the droppable ones the connman ui is more droppable. but thats MOOT right now as these are not the last 2 things left. We went through the list with Cedric and Gustavo, and this is the list with comments : - Fix EFM to be completely reliable/functional -- That's not a feature, those are bugs, and if they are not fixed by the time RC1 is fixed then it's not an issue to fix them between RC1 and final release. - Redo resolution settings module -- It is important, and I need it myself *but* people can live without it. Those who can't will just have to endure it or wait for the next release. Anyways, if this work has already been started (or not hard enough), then IF it can be done for RC1 then it can be included, otherwise too bad. - Randr config module/integration -- I don't really know what it means, so I can't comment both of the above are the same and i disagree. people can't live without. this decision was agreed on back in march.. actually before that we knew there was a real need. Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. - Keymap config -- Same as the resolution module, while it is necessary, people can live without it, otherwise, they'll endure it or wait. If it can be done by the time of RC1 release, then bugfixes can be added for the final release. disagree. alphas are meant to be feature complete. and so what? so what if we do an alpha now? what will that change? all it will do is encourage people to NOT finish things. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. - Get a default theme 100% ready to ship -- This is a no brainer, that extra polishing (what exactly is missing anyways?) can be done from RC1 to final. - Connman module ui needs to be improved -- I don't use it so not much to say about it, I use nm-applet with the systray module. But I guess it's the same as above, while it's needed, it's not something that will break the release. - Add config modules for all missing E config vars -- Same as above. if people WANT A RELEASE, THEN STEPUP AND DO SOMETHING! with those done then we can absolutely do an alpha (though it must wait until after efl 1.1 which is now due in about 3 weeks). Why not do the alpha (or RC1, it's the same thing, different naming) at the same time as efl 1.1 release? That's what we discussed and I think it's a good idea. This also sets a date for people to get their patches in before the alpha release. hell no - not at the same time. we have enough work to do on efl1.1 - why does it matter that they are at the same time? other than a sudden desire to release from a whole bunch of people not working on the release? It doesn't matter that they are at the same
Re: [E-devel] RFC: E17 Release
On Sun, Oct 30, 2011 at 10:50 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 15:35:01 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: On Sun, 30 Oct 2011, Carsten Haitzler (The Rasterman) wrote: we released efl 1.0 back at the start of the year... is there a massive rise in developers? :) the EFL without kick-ass apps, showing we can do more than the other similar libraries, are useless. So it's not really surprising. sure. Btw, there is not a massive amount of new devs / users, but some new ones appear. And there more people in IRC chans (#edevev and #e.fr) the last few months. Not sure if the 1.0 release (with the puplicity we tried to make) and this increase of devs/users are correlated, but my opinion is that it helped. you know what gets lots and lots of users and attention? going onto a major distribution as the primary desktop. a release wont make that happen. haha, sure it won't.. cause distros will take the svn snapshot... and sure, doing a release in itself will not bring any user or attention, it has to be part of a major distribution... what's your big plan on achieving that? Oh and btw, I heard that if you weren't so stubborn, redhat/fedora/gnome might still be using E as their primary WM. About the release, I see good points and bad points in everything that was said, so I can't make up my mind :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask, taskbar and engage
I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.fr wrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 10:15 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sun, Oct 30, 2011 at 9:58 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: i'm already working on taskbar. i've fixed horizontal sizing issues already. i need to fix theme up. t_unix has pending patches for xrandr multi-screen i have yet to look at - if someone wants a release them why not review those patches and try them out while i'm busy? otherwise this just takes longer. we can't set dates because so many people agree to do shit and then DONT DO IT.. in the end... i do most of it. look at: Ok that's cool, just let me know and I can stress test and report bugs on taskbar or any other module. I also need the multiscreen stuff, right now I have a script that uses xrandr, so I got the setup ready and I can test it for you. As for dates, yes, set a date, and if someone doesn't do shit, then too bad, the missing features will be missing features, it shouldn't mean a delay of another year. no - i'm not setting a date. i set a task list. Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to http://trac.enlightenment.org/e/wiki/Release of the list left the following could be dropped: * connman module ui improvement * config modules for missing e config vars the rest are not droppable. of the droppable ones the connman ui is more droppable. but thats MOOT right now as these are not the last 2 things left. We went through the list with Cedric and Gustavo, and this is the list with comments : - Fix EFM to be completely reliable/functional -- That's not a feature, those are bugs, and if they are not fixed by the time RC1 is fixed then it's not an issue to fix them between RC1 and final release. - Redo resolution settings module -- It is important, and I need it myself *but* people can live without it. Those who can't will just have to endure it or wait for the next release. Anyways, if this work has already been started (or not hard enough), then IF it can be done for RC1 then it can be included, otherwise too bad. - Randr config module/integration -- I don't really know what it means, so I can't comment both of the above are the same and i disagree. people can't live without. this decision was agreed on back in march.. actually before that we knew there was a real need. Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. - Keymap config -- Same as the resolution module, while it is necessary, people can live without it, otherwise, they'll endure it or wait. If it can be done by the time of RC1 release, then bugfixes can be added for the final release. disagree. alphas are meant to be feature complete. and so what? so what if we do an alpha now? what will that change? all it will do is encourage people to NOT finish things. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. - Get a default theme 100% ready to ship -- This is a no brainer, that extra polishing (what exactly is missing anyways?) can be done from RC1 to final. - Connman module ui needs to be improved -- I don't use it so not much to say about it, I use nm-applet with the systray module. But I guess it's the same as above, while it's needed, it's not something that will break the release. - Add config modules for all missing E config vars -- Same as above. if people WANT A RELEASE, THEN STEPUP AND DO SOMETHING! with those done then we can absolutely do an alpha (though it must wait until after efl 1.1 which is now due in about 3 weeks). Why not do the alpha (or RC1, it's the same thing, different naming) at the same time as efl 1.1 release? That's what we discussed and I think it's a good idea. This also sets a date for people to get their patches in before the alpha release. hell no - not at the same time. we have enough work to do on efl1.1 - why does it matter that they are at the same time? other than a sudden desire to release
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 8:29 PM, hannes.janet...@gmail.com hannes.janet...@googlemail.com wrote: calm down. the TODO is a collection of things most developers agree to be necessary for a release. if you want a release to happen earlier work on it. Speek for yourself. Lucas De Marchi -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask, taskbar and engage
Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.fr wrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask, taskbar and engage
The fix should be in SVN now, r64588, try it now and see if that gets it fixed. On Mon, Oct 31, 2011 at 7:12 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.frwrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 6:29 PM, hannes.janet...@gmail.com hannes.janet...@googlemail.com wrote: On Mon, Oct 31, 2011 at 10:15 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sun, Oct 30, 2011 at 9:58 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: i'm already working on taskbar. i've fixed horizontal sizing issues already. i need to fix theme up. t_unix has pending patches for xrandr multi-screen i have yet to look at - if someone wants a release them why not review those patches and try them out while i'm busy? otherwise this just takes longer. we can't set dates because so many people agree to do shit and then DONT DO IT.. in the end... i do most of it. look at: Ok that's cool, just let me know and I can stress test and report bugs on taskbar or any other module. I also need the multiscreen stuff, right now I have a script that uses xrandr, so I got the setup ready and I can test it for you. As for dates, yes, set a date, and if someone doesn't do shit, then too bad, the missing features will be missing features, it shouldn't mean a delay of another year. no - i'm not setting a date. i set a task list. Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to http://trac.enlightenment.org/e/wiki/Release of the list left the following could be dropped: * connman module ui improvement * config modules for missing e config vars the rest are not droppable. of the droppable ones the connman ui is more droppable. but thats MOOT right now as these are not the last 2 things left. We went through the list with Cedric and Gustavo, and this is the list with comments : - Fix EFM to be completely reliable/functional -- That's not a feature, those are bugs, and if they are not fixed by the time RC1 is fixed then it's not an issue to fix them between RC1 and final release. - Redo resolution settings module -- It is important, and I need it myself *but* people can live without it. Those who can't will just have to endure it or wait for the next release. Anyways, if this work has already been started (or not hard enough), then IF it can be done for RC1 then it can be included, otherwise too bad. - Randr config module/integration -- I don't really know what it means, so I can't comment both of the above are the same and i disagree. people can't live without. this decision was agreed on back in march.. actually before that we knew there was a real need. Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. - Keymap config -- Same as the resolution module, while it is necessary, people can live without it, otherwise, they'll endure it or wait. If it can be done by the time of RC1 release, then bugfixes can be added for the final release. disagree. alphas are meant to be feature complete. and so what? so what if we do an alpha now? what will that change? all it will do is encourage people to NOT finish things. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. - Get a default theme 100% ready to ship -- This is a no brainer, that extra polishing (what exactly is missing anyways?) can be done from RC1 to final. - Connman module ui needs to be improved -- I don't use it so not much to say about it, I use nm-applet with the systray module. But I guess it's the same as above, while it's needed, it's not something that will break the release. - Add config modules for all missing E config vars -- Same as above. if people WANT A RELEASE, THEN STEPUP AND DO SOMETHING! with those done then we can absolutely do an alpha (though it must wait until after efl 1.1 which is now due in about 3 weeks). Why not do the alpha (or RC1, it's the same thing, different naming) at the same time as efl 1.1 release? That's what we discussed and I think it's a
Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)
On Wed, 26 Oct 2011 12:37:12 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: On Wed, 26 Oct 2011, Cedric BAIL wrote: On Wed, Oct 26, 2011 at 11:10 AM, Vincent Torri vto...@univ-evry.fr wrote: On Wed, 26 Oct 2011, Cedric BAIL wrote: On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri vto...@univ-evry.fr wrote: Eina includes eina_inline_lock_posix.h on something else than Windows, hence pthread.h. _GNU_SOURCE is not defined. Suppose now that a user of Eina does this: #include Eina.h #include pthread.h The user will not have the possibility to features available with _GNU_SOURCE (like CPU_SET for example. I have that problem with Enesim), except by defining it just before including Eina.h. Which is not the best solution, I think. The problem, here, is that lock stuff is only inlined functions. The problem will be solved if they are in a source file. Maybe at the beginning, having these functions inlined was interesting because they were short. I'm not sure that keeping them inlined is really useful, now. As from a performance point of view, it really matter to have them inlined or not. Function call does cost. Another solution would be to define _GNU_SOURCE before including pthread.h (maybe under some conditions). But is it a good solution too ? Honestly, I don't know what the best solution is. So if someone knows how to properly fix that problem... I have always started to put libc header first if I need them directly and then include other library. This just solve this kind of issue. So I don't thing it's an issue to solve. well, if you think that everyone on earth must code like you... Actually, what would you say to someone that put #ifdef HAVE_CONFIG_H at the end of the C file. That's bad idea and that's the same here. It's just sane to put config first, hell, just look at raster's use of headers : he puts everything in a _private.h (config.h too). If he wants to use Eina: #include Eina.h #include exported_header.h #include ***_private.h and boum, it will fail with Eina if he wants to use CPU_SET. He will have to include config.h before Eina.h in a specific source file, while it's alreay included in his _private.h. it's like that because no efl headers ever BEFORE relied on the hosts config.h - in fact they NEVER EVER EVER should do thbis. the header from a lib should provide the same features always -r egardless of what is in the apps config.h. sure - the app CAN try and disable features by playing with #define and #undef games but it should not accidentally happen - ie all #ifdefs should be namespaced OR be compiler or architecture or platform specific. relying in #define __GNU_SOURCE or other friends to be defined by the app is bad. Don't tell me how to use these headers. In case you don't remember, it's ME who moved all the inclusion of the headers from the *_private.h to the source file, to avoid such problems (especially on Windows where it's even more evil). that's a REAL pain in the arse as then the top of every file has the same set of 2, 5, 10, 20 header includes. it's maintenance hell. i put them all into the same common/private header and even if not all are used in each file, it provides a global scope for the app/lib/project that you don't have to keep re-figuring-out per file. you use eet* in file a then later need it in file b but find Eet.h isn't included so u have to go fix it again when it can just be a common include. And I still think that it is a bug. Vincent then include C library and then all headers in their dependencies order. Because there is some inline/define value in the libc and in any header that could directly affect any header/library that use it, meaning any C library. It is a dependence of it and it make sense to just respect dependencies order to avoid any issue. For me it is a bug. If you don't want to change anything, then documentation must describe that, and in addition, adding a #warning in eina_inline_posix.x if _GNU_SOURCE is not defined would be useful too. If you want. -- Cedric BAIL -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a
Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)
On Tue, 1 Nov 2011, Carsten Haitzler (The Rasterman) wrote: On Wed, 26 Oct 2011 12:37:12 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: On Wed, 26 Oct 2011, Cedric BAIL wrote: On Wed, Oct 26, 2011 at 11:10 AM, Vincent Torri vto...@univ-evry.fr wrote: On Wed, 26 Oct 2011, Cedric BAIL wrote: On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri vto...@univ-evry.fr wrote: Eina includes eina_inline_lock_posix.h on something else than Windows, hence pthread.h. _GNU_SOURCE is not defined. Suppose now that a user of Eina does this: #include Eina.h #include pthread.h The user will not have the possibility to features available with _GNU_SOURCE (like CPU_SET for example. I have that problem with Enesim), except by defining it just before including Eina.h. Which is not the best solution, I think. The problem, here, is that lock stuff is only inlined functions. The problem will be solved if they are in a source file. Maybe at the beginning, having these functions inlined was interesting because they were short. I'm not sure that keeping them inlined is really useful, now. As from a performance point of view, it really matter to have them inlined or not. Function call does cost. Another solution would be to define _GNU_SOURCE before including pthread.h (maybe under some conditions). But is it a good solution too ? Honestly, I don't know what the best solution is. So if someone knows how to properly fix that problem... I have always started to put libc header first if I need them directly and then include other library. This just solve this kind of issue. So I don't thing it's an issue to solve. well, if you think that everyone on earth must code like you... Actually, what would you say to someone that put #ifdef HAVE_CONFIG_H at the end of the C file. That's bad idea and that's the same here. It's just sane to put config first, hell, just look at raster's use of headers : he puts everything in a _private.h (config.h too). If he wants to use Eina: #include Eina.h #include exported_header.h #include ***_private.h and boum, it will fail with Eina if he wants to use CPU_SET. He will have to include config.h before Eina.h in a specific source file, while it's alreay included in his _private.h. it's like that because no efl headers ever BEFORE relied on the hosts config.h - in fact they NEVER EVER EVER should do thbis. the header from a lib should provide the same features always -r egardless of what is in the apps config.h. sure - the app CAN try and disable features by playing with #define and #undef games but it should not accidentally happen - ie all #ifdefs should be namespaced OR be compiler or architecture or platform specific. relying in #define __GNU_SOURCE or other friends to be defined by the app is bad. Don't tell me how to use these headers. In case you don't remember, it's ME who moved all the inclusion of the headers from the *_private.h to the source file, to avoid such problems (especially on Windows where it's even more evil). that's a REAL pain in the arse as then the top of every file has the same set of 2, 5, 10, 20 header includes. it's maintenance hell. 1) It's a matter of taste : I find cleaner to include only the needed header files. 2) it's not a maintainance hell : I did it once, for several libs. As they are stable, *no* maintainance is needed. So i don't see why it is a pain, nor for you (who do not touch them anyway), or for me (who maintain anyway those includes). So everyone is happy. Can you really think that I find that bothering, me, the current autotools and Windows port maintainer ? :-) 3) with that method, one of the problem of Eina i raised (I insist :-) ) would have been solved without including config.h before your *_private.h of each source file using features allowed by, e.g. _GNU_SOURCE (like CPU_SET) Vincent i put them all into the same common/private header and even if not all are used in each file, it provides a global scope for the app/lib/project that you don't have to keep re-figuring-out per file. you use eet* in file a then later need it in file b but find Eet.h isn't included so u have to go fix it again when it can just be a common include. -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Tue, Nov 1, 2011 at 12:35 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Mon, Oct 31, 2011 at 6:29 PM, hannes.janet...@gmail.com hannes.janet...@googlemail.com wrote: On Mon, Oct 31, 2011 at 10:15 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sun, Oct 30, 2011 at 9:58 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: i'm already working on taskbar. i've fixed horizontal sizing issues already. i need to fix theme up. t_unix has pending patches for xrandr multi-screen i have yet to look at - if someone wants a release them why not review those patches and try them out while i'm busy? otherwise this just takes longer. we can't set dates because so many people agree to do shit and then DONT DO IT.. in the end... i do most of it. look at: Ok that's cool, just let me know and I can stress test and report bugs on taskbar or any other module. I also need the multiscreen stuff, right now I have a script that uses xrandr, so I got the setup ready and I can test it for you. As for dates, yes, set a date, and if someone doesn't do shit, then too bad, the missing features will be missing features, it shouldn't mean a delay of another year. no - i'm not setting a date. i set a task list. Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to http://trac.enlightenment.org/e/wiki/Release of the list left the following could be dropped: * connman module ui improvement * config modules for missing e config vars the rest are not droppable. of the droppable ones the connman ui is more droppable. but thats MOOT right now as these are not the last 2 things left. We went through the list with Cedric and Gustavo, and this is the list with comments : - Fix EFM to be completely reliable/functional -- That's not a feature, those are bugs, and if they are not fixed by the time RC1 is fixed then it's not an issue to fix them between RC1 and final release. - Redo resolution settings module -- It is important, and I need it myself *but* people can live without it. Those who can't will just have to endure it or wait for the next release. Anyways, if this work has already been started (or not hard enough), then IF it can be done for RC1 then it can be included, otherwise too bad. - Randr config module/integration -- I don't really know what it means, so I can't comment both of the above are the same and i disagree. people can't live without. this decision was agreed on back in march.. actually before that we knew there was a real need. Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. - Keymap config -- Same as the resolution module, while it is necessary, people can live without it, otherwise, they'll endure it or wait. If it can be done by the time of RC1 release, then bugfixes can be added for the final release. disagree. alphas are meant to be feature complete. and so what? so what if we do an alpha now? what will that change? all it will do is encourage people to NOT finish things. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. - Get a default theme 100% ready to ship -- This is a no brainer, that extra polishing (what exactly is missing anyways?) can be done from RC1 to final. - Connman module ui needs to be improved -- I don't use it so not much to say about it, I use nm-applet with the systray module. But I guess it's the same as above, while it's needed, it's not something that will break the release. - Add config modules for all missing E config vars -- Same as above. if people WANT A RELEASE, THEN STEPUP AND DO SOMETHING! with those done then we can absolutely do an alpha (though it must wait until after efl 1.1 which is now due in about 3 weeks). Why not do the alpha (or RC1, it's the same thing, different naming) at
Re: [E-devel] RFC: E17 Release
On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. Now who's being an arrogant arse hole? Well, the armchair expert does not WANT to help out anymore. You have reached the level of insults and really have gone beyond trying to make sense. Now all you are doing is hurling abuse in really long emails. You are doing precisely what you accuse raster of. If you really think that is not working for raster, why do you think it will work for you? You really need to chill out. You did not get your way RIGHT NOW, stop throwing your tantrum. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)
On Wed, 26 Oct 2011 10:55:58 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: Hey Eina includes eina_inline_lock_posix.h on something else than Windows, hence pthread.h. _GNU_SOURCE is not defined. Suppose now that a user of Eina does this: #include Eina.h #include pthread.h The user will not have the possibility to features available with _GNU_SOURCE (like CPU_SET for example. I have that problem with Enesim), except by defining it just before including Eina.h. Which is not the best solution, I think. The problem, here, is that lock stuff is only inlined functions. The problem will be solved if they are in a source file. Maybe at the beginning, having these functions inlined was interesting because they were short. I'm not sure that keeping them inlined is really useful, now. Another solution would be to define _GNU_SOURCE before including pthread.h (maybe under some conditions). But is it a good solution too ? Honestly, I don't know what the best solution is. So if someone knows how to properly fix that problem... Vincent i agree with you - putting actual functions inside headers as macros or inlines has big problems when those functions: 1. can be big (that means maybe more than 10 lines of code) - this causes code bloat as the function is duplicated in the app every time its used 2. if the function must serve as a compatibility system - eg change behavior based on compiletime setup and maybe change from install to install of the library (feature is there or is not). once app is compiled, then what the function does can never change regardless of whatever we change in eina, so doing macors and inlines is best limited to cases where the content will NEVER change AND where performance is so absolutely necessary that we must make them inlined. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Mon, 31 Oct 2011 22:14:20 +0100 Tomas Cech tc...@suse.cz said: Sorry for getting into this discussion only as E user. E17 is already very well usable and stable. When I shown E to my colleagues at SUSE, they were surprised how fast and usable it is and three already switched their machines to that. Quality is already good for use (as it was 2 years ago when I tried E for the first time). I have never used EFM, I don't use taskbar, I use terminal for keymap configuration, I don't use composition and I don't use python or JS for programming using EFL (shellementary is more than I need). There are many window managers (I know it's not the same as desktop environment) which doesn't use features mentioned above and have many users. All mentioned above sounds to me more like extra features. Having snapshots is way to go for distributions as the code will be more tested than 'yes-it-boots' and help distribution package maintainers to do their job. It's far better than asking on IRC which revision can be considered as working... my little user's vote: make snapshots and stabilize code periodically just saying - 98% of the time a snapshot is exactly the same as a random svn checkout. that's why i'm not so incredibly keen on them. i do have to say that for efl a big barrier or doing releases is that we have so many libs that have to be separately disted and built - if it was 1 tree it'd be easier. either way - as for the final todo list, we are SOO close and to give up now on features that are pretty key to many users is silly. hell - taskbar is now in svn. On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz m...@zentific.com wrote: On Fri, 28 Oct 2011 11:07:45 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I'm writing this mail so it's unified and everyone can opine without being in one place at one time (IRC/#edevelop). Recently I've talked to people and while I tried to express it at IRC, raster just got pissed and left. Later people would join and agree with me... so while I'm looking like a jerk I guess I'm not alone in there. I'll try to be as clear and short as possible. WHY RELEASE? 1. to clarify we know some snapshot is usable. This will get us in more distributions by default. good 2. to remove that stupid karma over the 17 number if e. Will help people that do not track us closely to know we're reasonable serious. people will probably still call it e17 even when we're on e20 3. we can start to bring in new technology without delaying it even further (ie: elm and scripting language - js/elev8) not really a valid reason to release, you can see it did wonders for gnome http://www.phoronix.com/scan.php?page=articleitem=gnome_survey_part1num=1 I don't really see the link with what you are saying. WHY NOT RELEASE? 1. there are both bugs (eg: efm) cedric has said a number of times that he'll be working on efm after he finishes emotion soon, and I'll likely disable eeze mounting entirely for the release since libmount is not widely deployed and I was unable to get widespread testing until now. 2. missing features (xrandr, taskbar, ...) * xrandr patches have been made and are on the list waiting for testing and review, so I'm not really sure why this is a missing feature. * New users will not be able to deal with E17 if it doesn't have a taskbar, end of story. Engage is in SVN now, it's usable and widely used already, it can be merged. No you can't ! Doesn't solve the problem for non composite use case and as long as we don't make the compositer the only possible choice we can't say that engage is the answer to that problem. * I don't care about keymap config since I'm american, but it seems important for users to be able to type in their own language * bw is awful, we should switch to and iron out detourious for release Yes, that's something we should do as soon as possible. As a side question, what is the status of that theme for elementary ? Because it would make sense to also do the switch for elementary at some point. * Improved connman support is a big sticking point for me. I strongly believe that if the module does not improve now while it is actually a blocker for release, it never will. To this end, it's missing 3 big features that I can see people using: hidden network support, static ip setting, and enterprise encryption. It's likely that this is not actually a 6 month project as you have implied. Well, I have been using connman module since now one year and there is only one place in the world where I would have liked to have a UI to set static IP and a VPN... I am sure that's raster is in that place most of the time like some of our user base :-) So not a strong requirement from my point of view, but maybe some people at Samsung could take over that item as of
Re: [E-devel] RFC: E17 Release
On Mon, 31 Oct 2011 17:19:17 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sun, Oct 30, 2011 at 10:50 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 15:35:01 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: On Sun, 30 Oct 2011, Carsten Haitzler (The Rasterman) wrote: we released efl 1.0 back at the start of the year... is there a massive rise in developers? :) the EFL without kick-ass apps, showing we can do more than the other similar libraries, are useless. So it's not really surprising. sure. Btw, there is not a massive amount of new devs / users, but some new ones appear. And there more people in IRC chans (#edevev and #e.fr) the last few months. Not sure if the 1.0 release (with the puplicity we tried to make) and this increase of devs/users are correlated, but my opinion is that it helped. you know what gets lots and lots of users and attention? going onto a major distribution as the primary desktop. a release wont make that happen. haha, sure it won't.. cause distros will take the svn snapshot... and sure, doing a release in itself will not bring any user or attention, it has to be part of a major distribution... what's your big plan on achieving that? it won't happen because we are not a sexy desktop environment. there is 1 big mistake i made back in 96/97 - it's that i wasn't all enthused by the desktop environment bandwagon - i thought that apps were apps and should work just fine under any wm. the desktop shell (which i didn't have a name for back then) was what i cared about and what i wanted e to become. e17 is very close to being that. but i made a fatal error. i didn't jump on the DE bandwagon and declare E's path to become a DE of its own to compete. that was a mistake. the big regret. as long as E isn't a DE it doesn't matter as it doesn't INTEGRATE to apps. Qt or GTK based apps just look odd under e. people don't want it. so unless E becomes a DE... this won't happen on any major distro. major meaning ubuntu/suse/fedora/debian levels - the DEFAULT DE they get without asking explicitly. Oh and btw, I heard that if you weren't so stubborn, redhat/fedora/gnome might still be using E as their primary WM. that's a nice vicious rumour either you are making up now or that has been spread. e only was shipped because of accident and that i worked at redhat and that i did my job. i can tell you that when i left redhat there was bad blood between me and redhat. we were not getting along well at all. partly because i was hired away for a better salary to silicon valley and redhat officially fired me because i had accepted an offer and was waiting for visa approvals that at the time were problematic and took time in the USA? lucky for me my new visa came through a few days after that (which is when i was going to put in my 1 month notice anyway). it was not possible to change companies in the US without re-applying for a visa... maybe you didn't know that? and all visa applications were a matter of public record and redhat was watching that so that's how they found out. so sure - use the wm written by the guy you fired because you were pissed off at him moving to a better company in a better location for a better salary? m yeah. sure! i see you also need a little history lesson on gnome way back when. let's roll back to 1997. i was working on enlightenment. it was up to 0.13 - it worked and looked... different. i was hired by redhat. they had this new gnome thing that miguel started. they wanted me to work on that. ok. i gave imlib a gdk front end to gtk/ apps could sanely use it. i argued on the gnome devel list that they needed a wm as you couldn't do a desktop without integration to one. miguel kept arguing they could do it just fine with all wm's. this went on for about 10 months. i was ready to make e do whatever gnome needed, but they were not interested, so i went my own way with e as gnome was going to work with al wm's and no integration. suddenly 10 months later it was oh halp we need wm integration. the realization dawned finally that you DId need WM integration for pany elements of gnome. i sighed and went ok - i can do it and so i plugged extra things into e that conflicted with e's own internal features to make gnome happy - because that was my job. the fact is gnome WANTED the wm to be a dumb wm slave. of course that has now changed with gnome 3 - they finally are doing what i was always doing with e - a highly integrated wm. when i left redhat e went its own way. it was not going to be a slave wm for gnome and simply throw out its pagers, menus, wallpaper handling and pretty much everything else because gnome insisted on it. so gnome switched to sawfish as they didn't want to fight with e's duplicated features and non-gnome-like policies. so e wasn't going to be shipped anymore. i was fine with this as the WAY it was shipped - it was a dumb just draw
Re: [E-devel] RFC: E17 Release
On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to that list there on the release page was a result of a group of e devs getting together at cebit and refining the existing more vague list. it was not just me. i was there. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. and yes i need to It doesn't matter that they are at the same time, what does matter is to have a fixed date for it. I said at the same time as efl 1.1 because cedric suggested that (at the conference). And this isn't a sudden desire, it's a desire that's been there for years, you just don't want to see it. You need time to rest post efl 1.1 release, fine, but set a reasonable date. why does it have to BE A FIXED DATE? why do i have to repeat this question - what is so MAGIC about that date. i s you are tired of the rudeness? well sorry about that! And I'm also pretty fucking tired of your condescending arrogant bullshit! Yeah yeah, I'm the new guy, I'm just a user, I haven't contributed anything worthy, so I should shut up, but you know what, I still have a voice, and I've heard so many 'rumors' about you, but now I believe them after I've actually experienced the rasterman ever since I joined. You talk in a condescending manner, you are arrogant, and you piss pretty much everybody off, I don't know how e17 lasted this long with you driving away everyone.. oh wait, yeah, people did leave the team, and maybe if you weren't being the dictator that you're trying to be, the community would be much much much larger. I have a lot of respect for your work, you definitely have a lot of skills that very few people have, but this does not mean you can be a tyrant dictator and do whatever you want, ignoring everyone's opinions. I understand E is basically your baby, and for sure your word is important but you need to listen to what people tell you and stop being so fucking stubborn (and I'm not saying this just about this thread btw)! While I'm on the subject, like what Gustavo said, someone emails and says he wants to help with something and all you could answer him is that he'll fail, how stupid is that? is that how you build a community ? you are if it's the website? then yes - i said that, as i've seen it happen before - several times. from memory he wanted to tear down the current site and rebuild and i said don't do that - it will go like others - it'll end up half done and we have a half done site then others are left to pick up and fix again. do it in parallel and when it's ready, we can shift over. you are indeed new. you may think it's all roses. over the decade+ i have many times relied on people who said i will do X. be that the website, or a piece of code, and countless times they vanish, never do it, do a tiny bit and give up, and then i, or others, are left holding the bag going so.. where is it?. we were expecting it. it didn't happen. or the quality of what was done was so poor or half-done it was scrapped and redone. something like the website - i'm not going to have someone redo it live with the existing one torn down. poisoning it from the inside, and I'm pretty sure I'm not the only one who thinks that (I actually know I'm not), but I always speak my mind, I'm not scared of you or scared of hurting your feelings, while I respect, I won't hold out on my thoughts just out of that respect, so I don't know if others here already told you what I've just said, or maybe they tried to be more subtle about it and you didn't udnerstand it, or maybe they did and you ignored it, or maybe they simply didn't out of fear/respect, or the usual oh he's like that, let him.. but I needed to get that off my chest. (and yes, before I get flooded with responses, I'm not saying everyone here would agree with what I said, but I know at least a few who would). You say I'm being rude because I dare open my mouth without doing any of the work you want.. well I've wanted to help, but everytime it seems I lose then you are doing what i already saw. you are wanting to have those who want to finish the todo list march to your tune of release, regardless of quality and completeness. all the people asking for release are all demotivated and not helping. what makes me think they will help to fix bugs in alpha? or finish features during alpha? my motivation, I swear I could have started working on that TODO right now, but every time I read an email from you, I get tired of that arrogance and just want
Re: [E-devel] itask, taskbar and engage
On Mon, 31 Oct 2011 19:27:25 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: is it just me... or are you actually helping out? :) The fix should be in SVN now, r64588, try it now and see if that gets it fixed. On Mon, Oct 31, 2011 at 7:12 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.frwrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ 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 -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask, taskbar and engage
2011/10/31 Carsten Haitzler ras...@rasterman.com: On Mon, 31 Oct 2011 19:27:25 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: is it just me... or are you actually helping out? :) Shhh. Less talking, more doing. The fix should be in SVN now, r64588, try it now and see if that gets it fixed. On Mon, Oct 31, 2011 at 7:12 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.frwrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ 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 -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)
On Tue, 1 Nov 2011 01:23:01 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: On Tue, 1 Nov 2011, Carsten Haitzler (The Rasterman) wrote: On Wed, 26 Oct 2011 12:37:12 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: On Wed, 26 Oct 2011, Cedric BAIL wrote: On Wed, Oct 26, 2011 at 11:10 AM, Vincent Torri vto...@univ-evry.fr wrote: On Wed, 26 Oct 2011, Cedric BAIL wrote: On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri vto...@univ-evry.fr wrote: Eina includes eina_inline_lock_posix.h on something else than Windows, hence pthread.h. _GNU_SOURCE is not defined. Suppose now that a user of Eina does this: #include Eina.h #include pthread.h The user will not have the possibility to features available with _GNU_SOURCE (like CPU_SET for example. I have that problem with Enesim), except by defining it just before including Eina.h. Which is not the best solution, I think. The problem, here, is that lock stuff is only inlined functions. The problem will be solved if they are in a source file. Maybe at the beginning, having these functions inlined was interesting because they were short. I'm not sure that keeping them inlined is really useful, now. As from a performance point of view, it really matter to have them inlined or not. Function call does cost. Another solution would be to define _GNU_SOURCE before including pthread.h (maybe under some conditions). But is it a good solution too ? Honestly, I don't know what the best solution is. So if someone knows how to properly fix that problem... I have always started to put libc header first if I need them directly and then include other library. This just solve this kind of issue. So I don't thing it's an issue to solve. well, if you think that everyone on earth must code like you... Actually, what would you say to someone that put #ifdef HAVE_CONFIG_H at the end of the C file. That's bad idea and that's the same here. It's just sane to put config first, hell, just look at raster's use of headers : he puts everything in a _private.h (config.h too). If he wants to use Eina: #include Eina.h #include exported_header.h #include ***_private.h and boum, it will fail with Eina if he wants to use CPU_SET. He will have to include config.h before Eina.h in a specific source file, while it's alreay included in his _private.h. it's like that because no efl headers ever BEFORE relied on the hosts config.h - in fact they NEVER EVER EVER should do thbis. the header from a lib should provide the same features always -r egardless of what is in the apps config.h. sure - the app CAN try and disable features by playing with #define and #undef games but it should not accidentally happen - ie all ##ifdefs should be namespaced OR be compiler or architecture or platform specific. relying in #define __GNU_SOURCE or other friends to be defined by the app is bad. Don't tell me how to use these headers. In case you don't remember, it's ME who moved all the inclusion of the headers from the *_private.h to the source file, to avoid such problems (especially on Windows where it's even more evil). that's a REAL pain in the arse as then the top of every file has the same set of 2, 5, 10, 20 header includes. it's maintenance hell. 1) It's a matter of taste : I find cleaner to include only the needed header files. true. i prefer my c files with less stuff at the top. :) 2) it's not a maintainance hell : I did it once, for several libs. As they are stable, *no* maintainance is needed. So i don't see why it is a pain, nor for you (who do not touch them anyway), or for me (who maintain anyway those includes). So everyone is happy. Can you really think that I find that bothering, me, the current autotools and Windows port maintainer ? :-) well it's painful during development... i've had to add headers a few times before because of this as i expected to be able to use the same apis in one part of a lib as another. 3) with that method, one of the problem of Eina i raised (I insist :-) ) would have been solved without including config.h before your *_private.h of each source file using features allowed by, e.g. _GNU_SOURCE (like CPU_SET) yeah - it would solve it, but its a bi-product - an inadvertent fix that was not intended. if Eina.h RELIES on the app including config.h and defining __GNU_SOURCE to work then that's wrong. if anything it probably should do something like: #ifndef __GNU_SOURCE #define NO_GNU_SOURCE #define __GNU_SOURCE 1 ...(rest of eina header here) #ifdef NO_GNU_SOURCE #undef NO_GNU_SOURCE #undef __GNU_SOURCE #endif at least then the eina features would be isolated from the app itself (if eina really needs/wants __GNU_SOURCE set) Vincent i put them all into the same common/private header and even if not all are used in each file, it provides a global scope for the app/lib/project that
Re: [E-devel] RFC: E17 Release
On Tue, 1 Nov 2011 11:38:11 +1000 David Seikel onef...@gmail.com said: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. Now who's being an arrogant arse hole? Well, the armchair expert does not WANT to help out anymore. You have reached the level of insults and really have gone beyond trying to make sense. Now all you are doing is hurling abuse in really long emails. You are doing precisely what you accuse raster of. If you really think that is not working for raster, why do you think it will work for you? You really need to chill out. You did not get your way RIGHT NOW, stop throwing your tantrum. thanks :) i'm baffled as to why people don't get that there is even a compromise available, i was swilling to see some items dropped. i am hoping that anyone who disagrees on dropped items speaks up and says their bit. but its still not setting a date. imho we can set a date... WHEN the list is done. what i AM now happy to see is... kakaroto is even now beginning to pitch in! awesome!!! :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask, taskbar and engage
On Mon, 31 Oct 2011 23:59:57 -0200 Iván Briano (Sachiel) sachi...@gmail.com said: 2011/10/31 Carsten Haitzler ras...@rasterman.com: On Mon, 31 Oct 2011 19:27:25 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: is it just me... or are you actually helping out? :) Shhh. Less talking, more doing. hehehehe The fix should be in SVN now, r64588, try it now and see if that gets it fixed. On Mon, Oct 31, 2011 at 7:12 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.frwrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ 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 -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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 -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Small patch with ecore_con_url.
On Mon, 31 Oct 2011 23:49:22 +0900 Kim Yunhan spb...@gmail.com said:
i was going to say.. yes - that was reverted due to lack of progress callbacks
then.. but now this way works. awesome. in svn it is! thanks!
Yes!
I empathized what you worry about.
At the first time, I tried to set this option at the initialization time in
ecore_con_url.
Then as you mentioned, no more propagation is occurred! :'-(
So I looked around more deeply, then I change that this code is called at
its finalization time as you seen in patch file.
And to conclude, the progress is working!!
Thank you.
On Mon, Oct 31, 2011 at 11:31 PM, Cedric BAIL cedric.b...@free.fr wrote:
On Mon, Oct 31, 2011 at 3:15 PM, Kim Yunhan spb...@gmail.com wrote:
Ooops. I forgot to attach patch file. :-)
On Mon, Oct 31, 2011 at 11:13 PM, Kim Yunhan spb...@gmail.com wrote:
Hello.
When I tested with elementary map, there is too many logs on console.
It makes me difficult to distinguish normal logs that I want to debug.
:'-(
It's libcurl's internal log for representing progress bar like this.
-
downloaded : 343 / 363
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 362
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 343 / 361
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:--
0
downloaded : 344 / 365
downloaded : 345 / 365
downloaded : 346 / 365
downloaded : 347 / 365
-
So, I want to remove this log.
And I look around ecore_con_url's code.
Then I found solution for it.
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (revision 64559)
+++ src/lib/ecore_con/ecore_con_url.c (working copy)
@@ -355,6 +355,7 @@
// FIXME: For an unknown reason, progress continue to arrive
after destruction
// this prevent any further call to the callback.
curl_easy_setopt(url_con-curl_easy, CURLOPT_PROGRESSFUNCTION,
NULL);
+curl_easy_setopt(url_con-curl_easy, CURLOPT_NOPROGRESS,
EINA_TRUE);
if (url_con-active)
{
When ecore_con_url goes to finalize, ecore_con_url remove its own
progress
function from libcurl.
But final progress function is called in libcurl, and if there is no
progress function libcurl print out internal progress log message.
Anyway as you seen above, it's useless!!
So I set libcurl option CURLOPT_NOPROGRESS, and it makes that be printed
out no more progress log.
Please review this simple patch, and commit in SVN.
I think I already saw that patch, it did go in and was reverted,
because when you set noprogress, you don't receive progress
information and you can't propagate a progress event. Result you won't
be able to update a progress bar during download. It's super annoying,
I agree, but I never saw a patch that make this progress feature work
without the printf storm.
So if the progress is working, what I doubt, this patch could go in,
if not, it won't.
--
Cedric BAIL
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
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
Re: [E-devel] [PATCH] Fix the bug that user cannot input key
On Mon, 31 Oct 2011 15:46:35 +0900 Jihoon Kim jihoon48@samsung.com said: ok - i've put this in and implemented the wince code too for the same changes. it's not right yet - still need utf16-utf8 conversion... but its better than it was. At this moment, space is processed in case of WM_KEYDOWN and WM_CHAR. Therefore, 'space' key is processed twice, it makes bug. In previous my patch, I changed keyname and string wrong. I send the revised patch again. Would you please review again? -Original Message- From: Carsten Haitzler (The Rasterman) [mailto:ras...@rasterman.com] Sent: Monday, October 31, 2011 12:28 PM To: Enlightenment developer list Cc: Jihoon Kim Subject: Re: [E-devel] [PATCH] Fix the bug that user cannot input key On Fri, 28 Oct 2011 21:03:49 +0900 Jihoon Kim jihoon48@samsung.com said: i don't think this is right. this means u get 2 key press events, with with key string, one without... :( Hi, EFL developers and Vincent. On Windows 7, there are some bugs related to key input in elementary_test. 1. alphabet and symbol characters doesn't be inputted in elementary entry. 2. When the space key is pressed, space string is entered in elementary entry. In this patch, I've tried to fix the above bugs. It works well when I tested. Would you please review this patch? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elm_map: add image loading error handling
On Mon, 31 Oct 2011 14:54:19 +0900 Bluezery ohpo...@gmail.com said:
Dear all
I made a bug fix for elm_map.
When a downloaded image has an error, , elm_map removes a file and goes on
just like download succeeded .
However, it is not success, so it should be marked as FALSE for later
retry.
Can anyone review this simple patch? :)
i guess thats better than whats here. it really should be retrying too... i
should make it do that...
Index: elm_map.c
===
--- elm_map.c (리비전 64538)
+++ elm_map.c (작업 사본)
@@ -1186,7 +1186,12 @@ _tile_update(Grid_Item *gi)
gi-download = EINA_FALSE;
evas_object_image_file_set(gi-img, gi-file, NULL);
if (evas_object_image_load_error_get(gi-img) != EVAS_LOAD_ERROR_NONE)
- ecore_file_remove(gi-file);
+ {
+WRN(Image loading error (%s), gi-file);
+ecore_file_remove(gi-file);
+gi-have = EINA_FALSE;
+return;
+ }
obj_rotate_zoom(gi-wd-obj, gi-img);
evas_object_show(gi-img);
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
RSAreg; Conference 2012
Save #36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Tue, 1 Nov 2011 11:04:40 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 1 Nov 2011 11:38:11 +1000 David Seikel onef...@gmail.com said: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. Now who's being an arrogant arse hole? Well, the armchair expert does not WANT to help out anymore. You have reached the level of insults and really have gone beyond trying to make sense. Now all you are doing is hurling abuse in really long emails. You are doing precisely what you accuse raster of. If you really think that is not working for raster, why do you think it will work for you? You really need to chill out. You did not get your way RIGHT NOW, stop throwing your tantrum. thanks :) i'm baffled as to why people don't get that there is even a compromise available, i was swilling to see some items dropped. i am hoping that anyone who disagrees on dropped items speaks up and says their bit. but its still not setting a date. imho we can set a date... WHEN the list is done. what i AM now happy to see is... kakaroto is even now beginning to pitch in! awesome!!! :) I'm starting to pitch in again, but with the lowest priority stuff that no one cares about. lol Once lua is fleshed out a bit more, I think some people might start to care. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
2011/11/1 David Seikel onef...@gmail.com: On Tue, 1 Nov 2011 11:04:40 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 1 Nov 2011 11:38:11 +1000 David Seikel onef...@gmail.com said: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. Now who's being an arrogant arse hole? Well, the armchair expert does not WANT to help out anymore. You have reached the level of insults and really have gone beyond trying to make sense. Now all you are doing is hurling abuse in really long emails. You are doing precisely what you accuse raster of. If you really think that is not working for raster, why do you think it will work for you? You really need to chill out. You did not get your way RIGHT NOW, stop throwing your tantrum. thanks :) i'm baffled as to why people don't get that there is even a compromise available, i was swilling to see some items dropped. i am hoping that anyone who disagrees on dropped items speaks up and says their bit. but its still not setting a date. imho we can set a date... WHEN the list is done. what i AM now happy to see is... kakaroto is even now beginning to pitch in! awesome!!! :) I'm starting to pitch in again, but with the lowest priority stuff that no one cares about. lol Once lua is fleshed out a bit more, I think some people might start to care. If that will make you happy, then we won't. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask, taskbar and engage
Because I bumped into the problem myself so of course I'll try to debug it, and I didn't do it because you told me to. As for the fix, did you have a look? I'm not sure it's done properly, the 'needed' var seems a bit overkill to do the check (didn't have time figure it out properly). Also, I was wondering if there wouldn't be a better solution to do if no gadget is resizable. On Mon, Oct 31, 2011 at 10:05 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 23:59:57 -0200 Iván Briano (Sachiel) sachi...@gmail.com said: 2011/10/31 Carsten Haitzler ras...@rasterman.com: On Mon, 31 Oct 2011 19:27:25 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: is it just me... or are you actually helping out? :) Shhh. Less talking, more doing. hehehehe The fix should be in SVN now, r64588, try it now and see if that gets it fixed. On Mon, Oct 31, 2011 at 7:12 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.frwrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ 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 -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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 -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
Re: [E-devel] RFC: E17 Release
On Tue, 1 Nov 2011 00:46:19 -0200 Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/11/1 David Seikel onef...@gmail.com: On Tue, 1 Nov 2011 11:04:40 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 1 Nov 2011 11:38:11 +1000 David Seikel onef...@gmail.com said: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. Now who's being an arrogant arse hole? Well, the armchair expert does not WANT to help out anymore. You have reached the level of insults and really have gone beyond trying to make sense. Now all you are doing is hurling abuse in really long emails. You are doing precisely what you accuse raster of. If you really think that is not working for raster, why do you think it will work for you? You really need to chill out. You did not get your way RIGHT NOW, stop throwing your tantrum. thanks :) i'm baffled as to why people don't get that there is even a compromise available, i was swilling to see some items dropped. i am hoping that anyone who disagrees on dropped items speaks up and says their bit. but its still not setting a date. imho we can set a date... WHEN the list is done. what i AM now happy to see is... kakaroto is even now beginning to pitch in! awesome!!! :) I'm starting to pitch in again, but with the lowest priority stuff that no one cares about. lol Once lua is fleshed out a bit more, I think some people might start to care. If that will make you happy, then we won't. Make me happy? Depends. Would that be don't care about lua, so just commit your damn patches yourself onefang, or don't care for your patches at all, go back to fiddling with your emu module? Oh, I could implement lua IN the emu module. Muahahaha. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
/me eagerly waits for raster to write a book titled The path to Enlightenment :-) On Tuesday, November 1, 2011 9:38:17 AM UTC+8, The Rasterman Carsten Haitzler wrote: On Mon, 31 Oct 2011 17:19:17 -0400 Youness Alaoui kaka...@kakaroto.homelinux.net said: On Sun, Oct 30, 2011 at 10:50 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 15:35:01 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: On Sun, 30 Oct 2011, Carsten Haitzler (The Rasterman) wrote: we released efl 1.0 back at the start of the year... is there a massive rise in developers? :) the EFL without kick-ass apps, showing we can do more than the other similar libraries, are useless. So it's not really surprising. sure. Btw, there is not a massive amount of new devs / users, but some new ones appear. And there more people in IRC chans (#edevev and #e.fr) the last few months. Not sure if the 1.0 release (with the puplicity we tried to make) and this increase of devs/users are correlated, but my opinion is that it helped. you know what gets lots and lots of users and attention? going onto a major distribution as the primary desktop. a release wont make that happen. haha, sure it won't.. cause distros will take the svn snapshot... and sure, doing a release in itself will not bring any user or attention, it has to be part of a major distribution... what's your big plan on achieving that? it won't happen because we are not a sexy desktop environment. there is 1 big mistake i made back in 96/97 - it's that i wasn't all enthused by the desktop environment bandwagon - i thought that apps were apps and should work just fine under any wm. the desktop shell (which i didn't have a name for back then) was what i cared about and what i wanted e to become. e17 is very close to being that. but i made a fatal error. i didn't jump on the DE bandwagon and declare E's path to become a DE of its own to compete. that was a mistake. the big regret. as long as E isn't a DE it doesn't matter as it doesn't INTEGRATE to apps. Qt or GTK based apps just look odd under e. people don't want it. so unless E becomes a DE... this won't happen on any major distro. major meaning ubuntu/suse/fedora/debian levels - the DEFAULT DE they get without asking explicitly. Oh and btw, I heard that if you weren't so stubborn, redhat/fedora/gnome might still be using E as their primary WM. that's a nice vicious rumour either you are making up now or that has been spread. e only was shipped because of accident and that i worked at redhat and that i did my job. i can tell you that when i left redhat there was bad blood between me and redhat. we were not getting along well at all. partly because i was hired away for a better salary to silicon valley and redhat officially fired me because i had accepted an offer and was waiting for visa approvals that at the time were problematic and took time in the USA? lucky for me my new visa came through a few days after that (which is when i was going to put in my 1 month notice anyway). it was not possible to change companies in the US without re-applying for a visa... maybe you didn't know that? and all visa applications were a matter of public record and redhat was watching that so that's how they found out. so sure - use the wm written by the guy you fired because you were pissed off at him moving to a better company in a better location for a better salary? m yeah. sure! i see you also need a little history lesson on gnome way back when. let's roll back to 1997. i was working on enlightenment. it was up to 0.13 - it worked and looked... different. i was hired by redhat. they had this new gnome thing that miguel started. they wanted me to work on that. ok. i gave imlib a gdk front end to gtk/ apps could sanely use it. i argued on the gnome devel list that they needed a wm as you couldn't do a desktop without integration to one. miguel kept arguing they could do it just fine with all wm's. this went on for about 10 months. i was ready to make e do whatever gnome needed, but they were not interested, so i went my own way with e as gnome was going to work with al wm's and no integration. suddenly 10 months later it was oh halp we need wm integration. the realization dawned finally that you DId need WM integration for pany elements of gnome. i sighed and went ok - i can do it and so i plugged extra things into e that conflicted with e's own internal features to make gnome happy - because that was my job. the fact is gnome WANTED the wm to be a dumb wm slave. of course that has now changed with gnome 3 - they finally are doing what i was always doing with e - a highly integrated wm. when i left redhat e went its own way. it was not going to be a slave wm for gnome and simply throw out its pagers, menus,
Re: [E-devel] E SVN: discomfitor trunk/e/src/modules/mixer
On Sat, 29 Oct 2011 15:45:51 -0700 Enlightenment SVN
no-re...@enlightenment.org said:
eeek! this broke the ability to mute/unmute pulse! :(
Log:
lots of new pulse features:
*all sink operations now work on sources
*sources are now available for finding/watching
*ports are available
*active port is settable
Author: discomfitor
Date: 2011-10-29 15:45:50 -0700 (Sat, 29 Oct 2011)
New Revision: 64513
Trac: http://trac.enlightenment.org/e/changeset/64513
Modified:
trunk/e/src/modules/mixer/Pulse.h trunk/e/src/modules/mixer/pa.c
trunk/e/src/modules/mixer/pa.h trunk/e/src/modules/mixer/serial.c
trunk/e/src/modules/mixer/sink.c trunk/e/src/modules/mixer/sys_pulse.c
Modified: trunk/e/src/modules/mixer/Pulse.h
===
--- trunk/e/src/modules/mixer/Pulse.h 2011-10-29 18:45:43 UTC (rev
64512) +++ trunk/e/src/modules/mixer/Pulse.h 2011-10-29 22:45:50 UTC
(rev 64513) @@ -12,8 +12,15 @@
typedef struct Pulse Pulse;
typedef uint32_t Pulse_Tag_Id;
typedef struct Pulse_Sink Pulse_Sink;
+typedef struct Pulse_Sink Pulse_Source;
typedef void (*Pulse_Cb)(Pulse *, Pulse_Tag_Id, void *);
+typedef struct Pulse_Sink_Port_Info {
+const char *name; /** Name of this port */
+const char *description;/** Description of this port */
+uint32_t priority; /** The higher this value is the
more useful this port is as a default */ +} Pulse_Sink_Port_Info;
+
int pulse_init(void);
void pulse_shutdown(void);
@@ -23,9 +30,18 @@
void pulse_cb_set(Pulse *conn, uint32_t tagnum, Pulse_Cb cb);
uint32_t pulse_cards_get(Pulse *conn);
-uint32_t pulse_sinks_get(Pulse *conn);
-uint32_t pulse_sink_get(Pulse *conn, uint32_t idx);
-uint32_t pulse_sink_mute_set(Pulse *conn, uint32_t idx, Eina_Bool mute);
+#define pulse_sinks_get(conn) pulse_types_get((conn), EINA_FALSE)
+#define pulse_sources_get(conn) pulse_types_get((conn), EINA_TRUE)
+uint32_t pulse_types_get(Pulse *conn, Eina_Bool source);
+#define pulse_sink_get(conn, idx) pulse_type_get((conn), (idx), EINA_FALSE)
+#define pulse_source_get(conn, idx) pulse_type_get((conn), (idx), EINA_FALSE)
+uint32_t pulse_type_get(Pulse *conn, uint32_t idx, Eina_Bool source);
+#define pulse_sink_mute_set(conn, idx, mute) pulse_type_mute_set((conn),
(idx), (mute), EINA_FALSE) +#define pulse_source_mute_set(conn, idx, mute)
pulse_type_mute_set((conn), (idx), (mute), EINA_TRUE) +uint32_t
pulse_type_mute_set(Pulse *conn, uint32_t idx, Eina_Bool mute, Eina_Bool
source); +#define pulse_sink_volume_set(conn, idx, channels, vol)
pulse_type_volume_set((conn), (idx), (channels), (vol), EINA_FALSE) +#define
pulse_source_volume_set(conn, idx, channels, vol) pulse_type_volume_set
((conn), (idx), (channels), (vol), EINA_TRUE) +uint32_t pulse_type_volume_set
(Pulse *conn, uint32_t sink_num, uint8_t channels, double vol, Eina_Bool
source); void pulse_sink_free(Pulse_Sink *sink); const char
*pulse_sink_name_get(Pulse_Sink *sink); @@ -38,7 +54,11 @@ Eina_List
*pulse_sink_channel_names_get(Pulse_Sink *sink); Eina_Bool pulse_sinks_watch
(Pulse *conn);
+const Eina_List *pulse_sink_ports_get(Pulse_Sink *sink);
+const char *pulse_sink_port_active_get(Pulse_Sink *sink);
+#define pulse_source_channel_volume_set pulse_sink_channel_volume_set
uint32_t pulse_sink_channel_volume_set(Pulse *conn, Pulse_Sink *sink,
uint32_t id, double vol); +uint32_t pulse_sink_port_set(Pulse *conn,
Pulse_Sink *sink, const char *port); double pulse_sink_channel_volume_get
(Pulse_Sink *sink, unsigned int id); float pulse_sink_channel_balance_get
(Pulse_Sink *sink, unsigned int id); float pulse_sink_channel_depth_get
(Pulse_Sink *sink, unsigned int id);
Modified: trunk/e/src/modules/mixer/pa.c
===
--- trunk/e/src/modules/mixer/pa.c2011-10-29 18:45:43 UTC (rev 64512)
+++ trunk/e/src/modules/mixer/pa.c2011-10-29 22:45:50 UTC (rev 64513)
@@ -15,6 +15,7 @@
int PULSE_EVENT_DISCONNECTED = -1;
int PULSE_EVENT_CHANGE = -1;
Eina_Hash *pulse_sinks = NULL;
+Eina_Hash *pulse_sources = NULL;
void
pulse_fake_free(void *d __UNUSED__, void *d2 __UNUSED__)
@@ -390,11 +391,11 @@
}
uint32_t
-pulse_sink_get(Pulse *conn, uint32_t sink_num)
+pulse_type_get(Pulse *conn, uint32_t idx, Eina_Bool source)
{
Pulse_Tag *tag;
int read;
- uint32_t type = PA_COMMAND_GET_SINK_INFO;
+ uint32_t type = source ? PA_COMMAND_GET_SOURCE_INFO :
PA_COMMAND_GET_SINK_INFO;
EINA_SAFETY_ON_NULL_RETURN_VAL(conn, 0);
tag = calloc(1, sizeof(Pulse_Tag));
@@ -403,7 +404,7 @@
tag-data = malloc(tag-dsize);
tag-tag_count = conn-tag_count;
tag_simple_init(conn, tag, type, PA_TAG_U32);
- tag_uint32(tag, sink_num);
+ tag_uint32(tag, idx);
tag_string(tag, NULL);
tag_finish(tag);
read =
Re: [E-devel] RFC: E17 Release
2011/11/1 David Seikel onef...@gmail.com: On Tue, 1 Nov 2011 00:46:19 -0200 Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/11/1 David Seikel onef...@gmail.com: On Tue, 1 Nov 2011 11:04:40 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 1 Nov 2011 11:38:11 +1000 David Seikel onef...@gmail.com said: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. Now who's being an arrogant arse hole? Well, the armchair expert does not WANT to help out anymore. You have reached the level of insults and really have gone beyond trying to make sense. Now all you are doing is hurling abuse in really long emails. You are doing precisely what you accuse raster of. If you really think that is not working for raster, why do you think it will work for you? You really need to chill out. You did not get your way RIGHT NOW, stop throwing your tantrum. thanks :) i'm baffled as to why people don't get that there is even a compromise available, i was swilling to see some items dropped. i am hoping that anyone who disagrees on dropped items speaks up and says their bit. but its still not setting a date. imho we can set a date... WHEN the list is done. what i AM now happy to see is... kakaroto is even now beginning to pitch in! awesome!!! :) I'm starting to pitch in again, but with the lowest priority stuff that no one cares about. lol Once lua is fleshed out a bit more, I think some people might start to care. If that will make you happy, then we won't. Make me happy? Depends. Would that be don't care about lua, so just commit your damn patches yourself onefang, or don't care for your patches at all, go back to fiddling with your emu module? Oh, I could implement lua IN the emu module. Muahahaha. Back from non-sense (and time.. emu? damn it, that's old), I don't know anything about Lua. All I know is that the script only thing is probably not used widely enough to cause too much damage committing your patches. And they are probably right anyway. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 8:46 PM, hannes.janet...@gmail.com hannes.janet...@googlemail.com wrote: On Tue, Nov 1, 2011 at 12:35 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Mon, Oct 31, 2011 at 6:29 PM, hannes.janet...@gmail.com hannes.janet...@googlemail.com wrote: On Mon, Oct 31, 2011 at 10:15 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sun, Oct 30, 2011 at 9:58 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: i'm already working on taskbar. i've fixed horizontal sizing issues already. i need to fix theme up. t_unix has pending patches for xrandr multi-screen i have yet to look at - if someone wants a release them why not review those patches and try them out while i'm busy? otherwise this just takes longer. we can't set dates because so many people agree to do shit and then DONT DO IT.. in the end... i do most of it. look at: Ok that's cool, just let me know and I can stress test and report bugs on taskbar or any other module. I also need the multiscreen stuff, right now I have a script that uses xrandr, so I got the setup ready and I can test it for you. As for dates, yes, set a date, and if someone doesn't do shit, then too bad, the missing features will be missing features, it shouldn't mean a delay of another year. no - i'm not setting a date. i set a task list. Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to http://trac.enlightenment.org/e/wiki/Release of the list left the following could be dropped: * connman module ui improvement * config modules for missing e config vars the rest are not droppable. of the droppable ones the connman ui is more droppable. but thats MOOT right now as these are not the last 2 things left. We went through the list with Cedric and Gustavo, and this is the list with comments : - Fix EFM to be completely reliable/functional -- That's not a feature, those are bugs, and if they are not fixed by the time RC1 is fixed then it's not an issue to fix them between RC1 and final release. - Redo resolution settings module -- It is important, and I need it myself *but* people can live without it. Those who can't will just have to endure it or wait for the next release. Anyways, if this work has already been started (or not hard enough), then IF it can be done for RC1 then it can be included, otherwise too bad. - Randr config module/integration -- I don't really know what it means, so I can't comment both of the above are the same and i disagree. people can't live without. this decision was agreed on back in march.. actually before that we knew there was a real need. Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. - Keymap config -- Same as the resolution module, while it is necessary, people can live without it, otherwise, they'll endure it or wait. If it can be done by the time of RC1 release, then bugfixes can be added for the final release. disagree. alphas are meant to be feature complete. and so what? so what if we do an alpha now? what will that change? all it will do is encourage people to NOT finish things. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. - Get a default theme 100% ready to ship -- This is a no brainer, that extra polishing (what exactly is missing anyways?) can be done from RC1 to final. - Connman module ui needs to be improved -- I don't use it so not much to say about it, I use nm-applet with the systray module. But I guess it's the same as above, while it's needed, it's not something that will break the release. - Add config modules for all missing E config vars -- Same as above. if
Re: [E-devel] RFC: E17 Release
On Mon, 31 Oct 2011 19:56:57 -0700 (PDT) P Purkayastha ppu...@gmail.com wrote: /me eagerly waits for raster to write a book titled The path to Enlightenment :-) rofl -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Tue, 1 Nov 2011 01:00:26 -0200 Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/11/1 David Seikel onef...@gmail.com: On Tue, 1 Nov 2011 00:46:19 -0200 Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/11/1 David Seikel onef...@gmail.com: On Tue, 1 Nov 2011 11:04:40 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 1 Nov 2011 11:38:11 +1000 David Seikel onef...@gmail.com said: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. Now who's being an arrogant arse hole? Well, the armchair expert does not WANT to help out anymore. You have reached the level of insults and really have gone beyond trying to make sense. Now all you are doing is hurling abuse in really long emails. You are doing precisely what you accuse raster of. If you really think that is not working for raster, why do you think it will work for you? You really need to chill out. You did not get your way RIGHT NOW, stop throwing your tantrum. thanks :) i'm baffled as to why people don't get that there is even a compromise available, i was swilling to see some items dropped. i am hoping that anyone who disagrees on dropped items speaks up and says their bit. but its still not setting a date. imho we can set a date... WHEN the list is done. what i AM now happy to see is... kakaroto is even now beginning to pitch in! awesome!!! :) I'm starting to pitch in again, but with the lowest priority stuff that no one cares about. lol Once lua is fleshed out a bit more, I think some people might start to care. If that will make you happy, then we won't. Make me happy? Depends. Would that be don't care about lua, so just commit your damn patches yourself onefang, or don't care for your patches at all, go back to fiddling with your emu module? Oh, I could implement lua IN the emu module. Muahahaha. Back from non-sense (and time.. emu? damn it, that's old), I don't know anything about Lua. All I know is that the script only thing is probably not used widely enough to cause too much damage committing your patches. And they are probably right anyway. That's my thoughts on the matter to, but I do want rasters opinion on the general direction I'm heading in before I dig too deep. On the other hand a wait until after the next EFL release changes my personal game plan in a big way. But that's my problem, not yours. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 9:38 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 17:19:17 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sun, Oct 30, 2011 at 10:50 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 15:35:01 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: On Sun, 30 Oct 2011, Carsten Haitzler (The Rasterman) wrote: we released efl 1.0 back at the start of the year... is there a massive rise in developers? :) the EFL without kick-ass apps, showing we can do more than the other similar libraries, are useless. So it's not really surprising. sure. Btw, there is not a massive amount of new devs / users, but some new ones appear. And there more people in IRC chans (#edevev and #e.fr) the last few months. Not sure if the 1.0 release (with the puplicity we tried to make) and this increase of devs/users are correlated, but my opinion is that it helped. you know what gets lots and lots of users and attention? going onto a major distribution as the primary desktop. a release wont make that happen. haha, sure it won't.. cause distros will take the svn snapshot... and sure, doing a release in itself will not bring any user or attention, it has to be part of a major distribution... what's your big plan on achieving that? it won't happen because we are not a sexy desktop environment. there is 1 big mistake i made back in 96/97 - it's that i wasn't all enthused by the desktop environment bandwagon - i thought that apps were apps and should work just fine under any wm. the desktop shell (which i didn't have a name for back then) was what i cared about and what i wanted e to become. e17 is very close to being that. but i made a fatal error. i didn't jump on the DE bandwagon and declare E's path to become a DE of its own to compete. that was a mistake. the big regret. as long as E isn't a DE it doesn't matter as it doesn't INTEGRATE to apps. Qt or GTK based apps just look odd under e. people don't want it. so unless E becomes a DE... this won't happen on any major distro. major meaning ubuntu/suse/fedora/debian levels - the DEFAULT DE they get without asking explicitly. Ok.. so I don't understand, you're saying you'll get devs when it shipped as the default WM for a major distro, but you say it won't happen (kind of expected), so you're basically saying that the project is already doomed? Oh and btw, I heard that if you weren't so stubborn, redhat/fedora/gnome might still be using E as their primary WM. that's a nice vicious rumour either you are making up now or that has been spread. e only was shipped because of accident and that i worked at redhat and that i did my job. i can tell you that when i left redhat there was bad blood between me and redhat. we were not getting along well at all. partly because i was hired away for a better salary to silicon valley and redhat officially fired me because i had accepted an offer and was waiting for visa approvals that at the time were problematic and took time in the USA? lucky for me my new visa came through a few days after that (which is when i was going to put in my 1 month notice anyway). it was not possible to change companies in the US without re-applying for a visa... maybe you didn't know that? and all visa applications were a matter of public record and redhat was watching that so that's how they found out. so sure - use the wm written by the guy you fired because you were pissed off at him moving to a better company in a better location for a better salary? m yeah. sure! Nope, not a rumor I'm making up, but a rumor that I heard. I don't know (never bothered to ask) about any details to be honest, but the rumor was basically that indeed there was bad blood, and that you got fired. Never heard of the job/visa thing though, the rumor states that your vision and the vision of gnome/redhat/whatever was diverging.. you wanted to customize everything and they wanted very little customization but for it to do the right thing by default. Can't remember though if the rumor ended with then you got fired or then you left because of this disagreement. i see you also need a little history lesson on gnome way back when. let's roll back to 1997. i was working on enlightenment. it was up to 0.13 - it worked and looked... different. i was hired by redhat. they had this new gnome thing that miguel started. they wanted me to work on that. ok. i gave imlib a gdk front end to gtk/ apps could sanely use it. i argued on the gnome devel list that they needed a wm as you couldn't do a desktop without integration to one. miguel kept arguing they could do it just fine with all wm's. this went on for about 10 months. i was ready to make e do whatever gnome needed, but they were not interested, so i went my own way with e as gnome was going to work
Re: [E-devel] RFC: E17 Release
On Mon, 31 Oct 2011 23:12:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Mon, Oct 31, 2011 at 9:38 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 17:19:17 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: Ok.. so I don't understand, you're saying you'll get devs when it shipped as the default WM for a major distro, but you say it won't happen (kind of expected), so you're basically saying that the project is already doomed? no - there's another plan... why do u think there's so much focus on efl for embedded? :) Nope, not a rumor I'm making up, but a rumor that I heard. I don't know (never bothered to ask) about any details to be honest, but the rumor was basically that indeed there was bad blood, and that you got fired. Never yes - fired because i had accepted a competing job offer (pending legal visa paperwork of course). h1-b visas at the time were non-transferable. you had to re-apply for each new employer. i couldn't sensibly quit while waiting - it could take anywhere from a few weeks to months to get a h1-b and if it took too long i'd have to leave the country. thus i HAD to wait it out. heard of the job/visa thing though, the rumor states that your vision and the vision of gnome/redhat/whatever was diverging.. you wanted to customize everything and they wanted very little customization but for it to do the yes. i wanted customizations for everything that at all made sense to customise. right thing by default. Can't remember though if the rumor ended with then i don't see any problem with having BOTH. you have a DEFAULT config that's good for most people - and those that disagree can tweak. i still totally disagree with the model of no options, no tweaking, just 1 way of doing things for everyone. it's good that we diverged. you got fired or then you left because of this disagreement. which matches pretty much what i said - but i gave the details now. i was brought into a room with eric troan (then head of engineering) and asked if i had another job accepted/lined up (don't remember the exact words - this is a long time ago - but conversation to that effect). i said yes and was fired on the spot. yes - bad blood. i wasn't employed by someone else yet. of course that'd wait until i had done my notice period, but redhat decided it'd be good to fire me on the spot. it actually was a good thing. i got out of north carolina to silicon valley and man was silicon valley nicer. a real city (san francisco), and absolutely awesome offices at VA Linux. fantastic equipment, network and so much more. some history - VA linux talked to me while at linuxworld in san jose. the simple version was do you want to come work here in silicon valley on e and make an awesome desktop! we actually make hardware and desktops so this will ship. i had the chance to ensure the hardware was good and would run e well. somewhere along the way opengl was becoming a thing - it was bad grantham that pointed me to trying to use opengl for 2d. and it mostly made sense. all the advanced features were now going into 3d, not 2d accel. all the things i really wanted. i started toying with gl for 2d - frankly a lot of stagnation on e is due to this whole direction. i was writing a filemanager for e16 - efm... used imlib2 and lots of alpha channels everywhere. gl made so much sense. but at valinux we had precision insight as aprt of the company - the guys working on drm/dri originally. another guy worked on the nvida 2d drivers. he now works at nvidia itself. it all made so much sense and this was heading towards having a desktop with specifically chosen 3d hardware with good support that we could accelerate a fancy ui experience via opengl... at the time though opengl was an iffy prospect. so many things it just couldn't do right to get pixel-correct 2d. i tried playing with all sorts of games to get it to work. also back then max texture sizes were often 256x256 which didn't help - we had to tile stuff in the original evas code for opengl. but i couldn't commit to opengl totally. it wasn't quite there yet hardware and api-wise. evas HAD to have its software back end too. and to this day it still does and its maintained and optimized. anyway in 2001 or so the dot-com bubble burst. all the companies riding high on inflated stock prices - like va linux, had a hard time, and then no one was buying servers from va because of the dot com bust. that was their main income stream. va basically crumbled. sure - given a few years and maturity there'd be a solid smooth linux desktop with gpu acceleration, but it didn't happen. the market crash killed that. e development also took a tumble along with this. but i realized the desktop was way too hard a win. and just about then the first ports of linux to the 206mhz strong-arm (64m ram. 16m flash, qvga) ipaq turned up... and i went oooh... so this really CAN work on things like pda's... hell THIS is where the future is. ever
Re: [E-devel] itask, taskbar and engage
On Mon, 31 Oct 2011 22:56:03 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: Because I bumped into the problem myself so of course I'll try to debug it, and I didn't do it because you told me to. As for the fix, did you have a i can't order you to do anything - but you need to read what i wrote. as a summary, i said - help out and do things, instead of telling others what to do. if this had been done since the last major review of the todo list in march we'd be there already. you can tell others what to do all you like. they don't have to listen to a single word, just the same as you don't have to do anything either when i say help out. i'm using the release as a stick or a carrot to beat or bait people into helping out. i can't fire you or offer you a bonus or money, so those normal sticks and carrots are not able to be used, so i use a different one. i'm trying to use your own motivation for release. i wish your motivation would make you rise to the challenge rather than just have a release or bust view. open source works at a nuts and bolts level because people do things. projects start and move forward because someone does the hard yards. almost every open source project started life as a one-man project and it was that one man that got it up and running and to the point others might pitch in and scratch their itches or help even do things that are needed. it then became a team effort with no hard way to control the people working on it. projects offer carrots in the following ways: 1. name attached to project for bragging rights, 2. the ability to influence, control etc. something. 3. the satisfaction of a job well done in the end (seeing what u slaved on going gold), 4. if u are lucky the project may create a way to generate income from it for yourself. the sticks available are: 1. shaming people into doing things (guilt trips etc.), 2. ejection from privileges (like commit access, banning from irc, removal from mailing lists etc.). that's about it. i'm trying to use both a stick and a carrot. i'm trying to get you to accept some of the blame for a bad e17 release if you are the one pushing for it, as well as then getting some credit if it's good. right now you are pushing for what i believe is a slightly premature action. look? I'm not sure it's done properly, the 'needed' var seems a bit overkill to do the check (didn't have time figure it out properly). Also, I was wondering if there wouldn't be a better solution to do if no gadget is resizable. yes i looked. that was the first thing i did. along with counting it as your first commit to e17according to logs. actually its right in that the logic is right - i was only testing when i had 1 gadget or more being autoscrollable - thus resizable. i didnt remember about zero gadgets resizable and thus maybe getting that loop. my bad there. i was making taskbar usable. i'm running it myself right now even though i really despise having it on my screen to make sure it at least works for me :) On Mon, Oct 31, 2011 at 10:05 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 23:59:57 -0200 Iván Briano (Sachiel) sachi...@gmail.com said: 2011/10/31 Carsten Haitzler ras...@rasterman.com: On Mon, 31 Oct 2011 19:27:25 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: is it just me... or are you actually helping out? :) Shhh. Less talking, more doing. hehehehe The fix should be in SVN now, r64588, try it now and see if that gets it fixed. On Mon, Oct 31, 2011 at 7:12 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.frwrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 9:42 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to that list there on the release page was a result of a group of e devs getting together at cebit and refining the existing more vague list. it was not just me. i was there. Alright, if that TODO was a group effort, then my apologies on the specific parts where I stated your todo. I'd like to point out though that when I said that, I wasn't just referring to you wrote it, but rather on you decided what to put in it, those who disagreed got ignored. You always seem to have the final word, and that's why I consider it your todo. But yes, I was not there, so I cannot know, so againt, just a hypothesis. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. and yes i need to Sorry, this seems unclear, yes I need to? what do you mean? yes you need me to spell it out? or yes, you need those 3 things I listed == an alpha is needed ? It doesn't matter that they are at the same time, what does matter is to have a fixed date for it. I said at the same time as efl 1.1 because cedric suggested that (at the conference). And this isn't a sudden desire, it's a desire that's been there for years, you just don't want to see it. You need time to rest post efl 1.1 release, fine, but set a reasonable date. why does it have to BE A FIXED DATE? why do i have to repeat this question - what is so MAGIC about that date. i s The date itself is not magic, we're not saying december 25th, or january 1st, or whatever other 'special dates'. But what will A DATE create is a deadline, and the deadline in itself will drive the development. Not everyone works like that, for sure, but I believe that most people will get more shit done if they have a deadline rather than whenever you can. And I've experienced this so many times.. no commits for 6 months on amsn, then we say we'll release next week, start building packages then 100 or 200 commits get sent in that single week (seriously). A deadline is a motivational factor and you don't seem to get it. But more than that, a fixed date will force a release, and without that, it's like a it will never happen kind of deal. Get it out, then concentrate on the next release, then iterate. you are tired of the rudeness? well sorry about that! And I'm also pretty fucking tired of your condescending arrogant bullshit! Yeah yeah, I'm the new guy, I'm just a user, I haven't contributed anything worthy, so I should shut up, but you know what, I still have a voice, and I've heard so many 'rumors' about you, but now I believe them after I've actually experienced the rasterman ever since I joined. You talk in a condescending manner, you are arrogant, and you piss pretty much everybody off, I don't know how e17 lasted this long with you driving away everyone.. oh wait, yeah, people did leave the team, and maybe if you weren't being the dictator that you're trying to be, the community would be much much much larger. I have a lot of respect for your work, you definitely have a lot of skills that very few people have, but this does not mean you can be a tyrant dictator and do whatever you want, ignoring everyone's opinions. I understand E is basically your baby, and for sure your word is important but you need to listen to what people tell you and stop being so fucking stubborn (and I'm not saying this just about this thread btw)! While I'm on the subject, like what Gustavo said, someone emails and says he wants to help with something and all you could answer him is that he'll fail, how stupid is that? is that how you build a community ? you are if it's the website? then yes - i said that, as i've seen it happen before - several times. from memory he wanted to tear down the current site and rebuild and i said don't do that - it will go like others - it'll end up half done and we have a half done site then others are left to pick up and fix again. do it in parallel and when it's ready, we can shift over. you are indeed new. you may think it's all roses. over the decade+ i have many times relied on people who said i will do X. be that the website, or a piece of code, and countless times they vanish, never do it, do a tiny bit and give up, and then i, or others, are left holding the bag going so.. where is it?. we were expecting it. it didn't happen. or the quality of what was
Re: [E-devel] RFC: E17 Release
On Mon, 31 Oct 2011 23:01:59 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: Maybe the reason why raster is doing all the work and nobody works on that TODO is because this is an open source project, so everyone works on it on their own free time, which means they only do what they want, what motivates them. You forgot discomfitor and T_UNIX working (and having worked) on big tasks of the TODO. Then there are others fixing bugs which is also critical for release but not on the list. I didn't forget about them. I simply honestly don't know who is active i pointed people to this in this thread and several times over the past few months: http://trac.enlightenment.org/e/wiki/Release it lists who is assigned which task and what is done or not done. and how, I am still new here and haven't been following the internals too much. I do agree that my statement may have been untrue and based on hypothesis, but it was as a response to raster saying that he's doing everything himself (unless I misread that too). i never said everything - i explicitly mentioned discomfitor and t_unix - it's all there on that page. i have been doing the lions share though. if its the todo list u have an issue with it - work on it to get it done. i already said that 3 of those could be done after alpha. If everyone wanted those features, they would have finished working on them by now. And I don't want a release to happen earlier, I want releases to be planned and release dates to be set and work to be done to make it happen on time, I don't want to have a todo list dictate when the release should happen, and not knowing if it's in one week or one year. For initial release it is better to define the set of features that we want to provide and make sure that those work imo, especially after ten years of development. After that is done I'm all for having release cycles. Thanks, quite honestly the first 'sane' response I've seen here so far (from the opposition) as you are giving an actual argument to the immediate problem. I do agree with you on that, definitely a set of features is needed for the initial release. I don't agree though on the ones being listed in the todo as being blockers for the release. i guess the reason i don't discuss this is that this has been discussed before - many times. we can do more regular releases after e17 is out - but we have a high level to achieve for it to be credible. that's where i disagree with the dump everything excepting fixing efm and the strict dates - if we say release dec 1 and between now and dec 1 no one does ANYTHING and e is full of bugs - do you think we must then release dec 1 - mountains of bugs or not? i do not believe in that. i believe that you do all the major things first and fix all the nasties and then near the end make decisions on the more obscure bugs/features that u can live without or we can live with that bug as it really doesn't affects many people. but we are not at this point yet. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Tue, 1 Nov 2011 00:17:01 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Mon, Oct 31, 2011 at 9:42 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to that list there on the release page was a result of a group of e devs getting together at cebit and refining the existing more vague list. it was not just me. i was there. Alright, if that TODO was a group effort, then my apologies on the specific parts where I stated your todo. I'd like to point out though that when I said that, I wasn't just referring to you wrote it, but rather on you decided what to put in it, those who disagreed got ignored. You always seem to have the final word, and that's why I consider it your todo. But yes, I was not there, so I cannot know, so againt, just a hypothesis. actually others put things on that todo too - but yes i do act as final arbiter of it, but it most definitely was not entirely my todo just with others nodding their heads. yes - i did put a fair few items on that list. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. and yes i need to Sorry, this seems unclear, yes I need to? what do you mean? yes you need me to spell it out? or yes, you need those 3 things I listed == an alpha is needed ? yes - need a freeze before release. yes need to fix bugs. but we have a mountain of bugreports ALREADY! have u looked in trac? check the active tickets. :) 250 or so of them. It doesn't matter that they are at the same time, what does matter is to have a fixed date for it. I said at the same time as efl 1.1 because cedric suggested that (at the conference). And this isn't a sudden desire, it's a desire that's been there for years, you just don't want to see it. You need time to rest post efl 1.1 release, fine, but set a reasonable date. why does it have to BE A FIXED DATE? why do i have to repeat this question - what is so MAGIC about that date. i s The date itself is not magic, we're not saying december 25th, or january 1st, or whatever other 'special dates'. But what will A DATE create is a deadline, and the deadline in itself will drive the development. Not everyone works like that, for sure, but I believe that most people will get more shit done if they have a deadline rather than whenever you can. And I've experienced this so many times.. no commits for 6 months on amsn, then we say we'll release next week, start building packages then 100 or 200 commits get sent in that single week (seriously). A deadline is a i've seen the reverse. deadlines come, deadlines go. no action. motivational factor and you don't seem to get it. But more than that, a fixed date will force a release, and without that, it's like a it will never happen kind of deal. Get it out, then concentrate on the next release, then iterate. i can lie and invent dates and then keep rescheduling like most projects. i really hate doing that. when those todo things are done i feel confident calling an alpha and then maybe 4 weeks to beta (fix bugs). but that's assuming that todo is done (as i said - with the items for alpha - the worst of efm issues fixed like dnd, copy paste, tasks (done now), keymap, xrandr). as of today we only have randr, keymap, efm - keymap has been promised by quaker66 now since march. randr i just patched into my e today for some testing and looking around. i have to move over to an intel laptop to do this as i need randr working. so we're -||- that close to doing exactly what people want - an alpha then release after bugs are fixed. you are tired of the rudeness? well sorry about that! And I'm also pretty fucking tired of your condescending arrogant bullshit! Yeah yeah, I'm the new guy, I'm just a user, I haven't contributed anything worthy, so I should shut up, but you know what, I still have a voice, and I've heard so many 'rumors' about you, but now I believe them after I've actually experienced the rasterman ever since I joined. You talk in a condescending manner, you are arrogant, and you piss pretty much everybody off, I don't know how e17 lasted this long with you driving away everyone.. oh wait, yeah, people did leave the team, and maybe if you weren't being the dictator that you're trying to be, the community would be much much much larger. I have a lot of respect for your work, you definitely have a lot of
Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore_con
Wow. I entered into ecore AUTHORS.
Thanks!! ;-)
On Tue, Nov 1, 2011 at 11:25 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
From: Kim Yunhan spb...@gmail.com
Subject: [E-devel] Small patch with ecore_con_url.
When I tested with elementary map, there is too many logs on console.
It makes me difficult to distinguish normal logs that I want to debug.
:'-(
It's libcurl's internal log for representing progress bar like this.
-
downloaded : 343 / 363
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total Spent
Left
Speed
0 00 00 0 0 0 --:--:-- --:--:--
--:--:--
0
downloaded : 343 / 362
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total Spent
Left
Speed
0 00 00 0 0 0 --:--:-- --:--:--
--:--:--
0
downloaded : 343 / 361
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total Spent
Left
Speed
0 00 00 0 0 0 --:--:-- --:--:--
--:--:--
0
downloaded : 344 / 365
downloaded : 345 / 365
downloaded : 346 / 365
downloaded : 347 / 365
-
So, I want to remove this log.
And I look around ecore_con_url's code.
Then I found solution for it.
Author: raster
Date: 2011-10-31 19:25:14 -0700 (Mon, 31 Oct 2011)
New Revision: 64596
Trac: http://trac.enlightenment.org/e/changeset/64596
Modified:
trunk/ecore/AUTHORS trunk/ecore/src/lib/ecore_con/ecore_con_url.c
Modified: trunk/ecore/AUTHORS
===
--- trunk/ecore/AUTHORS 2011-11-01 01:41:09 UTC (rev 64595)
+++ trunk/ecore/AUTHORS 2011-11-01 02:25:14 UTC (rev 64596)
@@ -44,3 +44,4 @@
ChunEon Park her...@hermet.pe.kr
xlo...@igalia.com
Rafael Antognolli antogno...@profusion.mobi
+Kim Yunhan spb...@gmail.com
Modified: trunk/ecore/src/lib/ecore_con/ecore_con_url.c
===
--- trunk/ecore/src/lib/ecore_con/ecore_con_url.c 2011-11-01
01:41:09 UTC (rev 64595)
+++ trunk/ecore/src/lib/ecore_con/ecore_con_url.c 2011-11-01
02:25:14 UTC (rev 64596)
@@ -355,6 +355,7 @@
// FIXME: For an unknown reason, progress continue to arrive after
destruction
// this prevent any further call to the callback.
curl_easy_setopt(url_con-curl_easy, CURLOPT_PROGRESSFUNCTION,
NULL);
+curl_easy_setopt(url_con-curl_easy, CURLOPT_NOPROGRESS,
EINA_TRUE);
if (url_con-active)
{
--
RSAreg; Conference 2012
Save #36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
RSAreg; Conference 2012
Save #36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
