Re: [E-devel] E SVN: seoz trunk/elementary/src/lib
On Mon, 25 Jul 2011 23:07:54 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: elm genscroller: Fixed warnings while raster is not working on this :) hooray! lol! Author: seoz Date: 2011-07-25 23:07:54 -0700 (Mon, 25 Jul 2011) New Revision: 61727 Trac: http://trac.enlightenment.org/e/changeset/61727 Modified: trunk/elementary/src/lib/elm_genscroller.c someone buy this man a drink, ASAP. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] Elm_Label, Incompatible Widget Data Type
good job! Daniel Juyung Seo (SeoZ) 2011/7/26 ChunEon Park her...@naver.com: not bad. in svn. Thanks. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: cnooklt;kimci...@gmail.comgt; To: EFLlt;enlightenment-devel@lists.sourceforge.netgt; Cc: Sent: 11-07-26(화) 13:58:55 Subject: [E-devel] [Patch] Elm_Label, Incompatible Widget Data TypeHi All, The Elm_Wrap_Type have been added, and APIs have been changed also. But there are some remains have to be changed as the attached patch. Sincerely, Shinwoo Kim. -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] Elm_Label, Incompatible Widget Data Type
On 26/07/11 07:58, cnook wrote: Hi All, The Elm_Wrap_Type have been added, and APIs have been changed also. But there are some remains have to be changed as the attached patch. /me hides from the shame. Nice catch, thanks. -- Tom. -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore
backport to 1.0 ?
Vincent
On Tue, 26 Jul 2011, Enlightenment SVN wrote:
Log:
fix timer precision handling to do what it was meant to do to begin with
Author: raster
Date: 2011-07-26 00:01:55 -0700 (Tue, 26 Jul 2011)
New Revision: 61730
Trac: http://trac.enlightenment.org/e/changeset/61730
Modified:
trunk/ecore/ChangeLog trunk/ecore/src/lib/ecore/ecore_timer.c
Modified: trunk/ecore/ChangeLog
===
--- trunk/ecore/ChangeLog 2011-07-26 07:00:19 UTC (rev 61729)
+++ trunk/ecore/ChangeLog 2011-07-26 07:01:55 UTC (rev 61730)
@@ -263,3 +263,9 @@
2011-07-22 Mike Blumenkrantz
* Added ecore_con_url_url_get
+
+2011-07-26 Carsten Haitzler (The Rasterman)
+
+* Fix timer precision handling for grouping timer ticks so
+they actually do tick off together
+
Modified: trunk/ecore/src/lib/ecore/ecore_timer.c
===
--- trunk/ecore/src/lib/ecore/ecore_timer.c 2011-07-26 07:00:19 UTC (rev
61729)
+++ trunk/ecore/src/lib/ecore/ecore_timer.c 2011-07-26 07:01:55 UTC (rev
61730)
@@ -590,15 +590,17 @@
_ecore_timer_after_get(Ecore_Timer *base)
{
Ecore_Timer *timer = (Ecore_Timer *) EINA_INLIST_GET(base)-next;
+ Ecore_Timer *valid_timer = NULL;
double maxtime = base-at + precision;
- while ((timer) ((timer-delete_me) || (timer-just_added))
(timer-at = maxtime))
- timer = (Ecore_Timer *) EINA_INLIST_GET(timer)-next;
+ while ((timer) (timer-at maxtime))
+ {
+if (!((timer-delete_me) || (timer-just_added)))
+ valid_timer = timer;
+timer = (Ecore_Timer *) EINA_INLIST_GET(timer)-next;
+ }
- if ((!timer) || (timer-at maxtime))
- return NULL;
-
- return timer;
+ return valid_timer;
}
double
@@ -612,8 +614,7 @@
if (!first) return -1;
second = _ecore_timer_after_get(first);
- if (second)
- first = second;
+ if (second) first = second;
now = ecore_loop_time_get();
in = first-at - now;
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] Animation gif feature patch
1. why do you think *_animated_* is not proper name? long character or grammar problem (word class? Other reason?) ? *_animated_* is familiar to me, and there is no place related with this in evas , so I want to keep this name. But If this name is wrong or not acceptable name generally , I will consider to change API name. 2. yes . I already have elm_icon_anim_available_get API 3. elm_icon_anim_set means I will use animation mode currently or later. Elm_icon_anim_play_set is for real play of image. Thanks. -Original Message- From: Daniel Juyung Seo [mailto:seojuyu...@gmail.com] Sent: Monday, July 25, 2011 11:43 PM To: ChunEon Park Cc: Jiyoun Park; enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] [Patch] Animation gif feature patch 1) Frankely, I don't like *_animated_* Agreed. Choose either animation or anim and apply it to evas_object_image and elm_icon. I prefer anim :) 2) Eina_Bool elm_icon_anim_get (const Evas_Object *obj) - elm_icon_anim_available_get ... elm_icon_anim_available_get is already in Jiyoun's patch. 3) API names are not clear. For me 2 names are confusing. elm_icon_anim_set() elm_icon_anim_play_set() What's anim mode and anim play mode? Maybe I'm missing some animation image concept. Thanks. Daniel Juyung Seo (SeoZ) On Mon, Jul 25, 2011 at 8:20 PM, ChunEon Park her...@naver.com wrote: Frankely, I don't like *_animated_* How about just animation or anim? evas_object_image_animation_available_get evas_object_image_animation_frame_get ... and this API also. Eina_Bool elm_icon_anim_get (const Evas_Object *obj) - elm_icon_anim_available_get ... Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Jiyoun Parklt;jy0703.p...@samsung.comgt; To: enlightenment-devel@lists.sourceforge.net Cc: Sent: 11-07-25(월) 17:18:22 Subject: [E-devel] [Patch] Animation gif feature patchHello. I modified animated gif feature code according Mike’s advise. Added api Eina_Bool evas_object_image_animated_get (const Evas_Object *obj) int evas_object_image_animated_frame_num_get (const Evas_Object *obj) Evas_Image_Animated_Loop_Hint evas_object_image_animated_loop_type_get (const Evas_Object *obj) int evas_object_image_animated_loop_count_get (const Evas_Object *obj) double evas_object_image_animated_frame_duration_get (const Evas_Object *obj, int start_frame, int fram_num) void evas_object_image_animated_frame_set (Evas_Object *obj, int frame_num) Eina_Bool elm_icon_anim_available_get (const Evas_Object *obj) Void elm_icon_anim_set (Evas_Object *obj, Eina_Bool anim) Eina_Bool elm_icon_anim_get (const Evas_Object *obj) void elm_icon_anim_play_set (Evas_Object *obj, Eina_Bool play) Eina_Bool elm_icon_anim_play_get (const Evas_Object *obj) Todo 1. optimization 2. Test case to test several files Test_icon.c is for elm icon test. Change test_icon.c in elementary/src/bin to this. Thanks. -- Jiyoun Park Mobile S/W Platform Lab DMC RD Center SAMSUNG ELECTRONICS CO. ,LTD TEL: +82-31-279-0619 Mobile: +82-10-9871-0703 jy0703.p...@samsung.com -- -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] Elm_Label, Incompatible Widget Data Type
TAsn!!! But it's ok. It was a huge change. So anyone could miss some. Daniel Juyung Seo (SeoZ) On Tue, Jul 26, 2011 at 4:07 PM, Tom Hacohen tom.haco...@partner.samsung.com wrote: On 26/07/11 07:58, cnook wrote: Hi All, The Elm_Wrap_Type have been added, and APIs have been changed also. But there are some remains have to be changed as the attached patch. /me hides from the shame. Nice catch, thanks. -- Tom. -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Add some APIs for supporting virtual keyboard in Ecore_IMF
On Fri, 08 Jul 2011 14:58:19 +0900 Jihoon Kim jihoon48@samsung.com said: h ok - i have 2 questions. 1. why should the app CONTROL the effects for the input panel showing/hiding directly? the input panel should be a window managed by the wm and shown and hidden as the wm sees fit, if it animates or not is not the apps decision nor should it be. this really exposes too much direct control imho. 2. getting input panel geometry - this is done via other properties/hints already, why here? the other properties can in theory handle multiple overlayed windows not just keyboard (indicator too and softkey etc.). why should vkbd be different and add an api here? Hi, EFL developers. For supporting virtual keyboard, I'd like to add some APIs. The detail description of each API is written in the patch file as doxygen format. Would you please review this patch? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATH] e_module-notification - force timeout
On Thu, 07 Jul 2011 14:45:02 +0200 Libor Zoubek lzou...@jezzovo.net said: in svn! it's a 3rd party module no one is caring for.. so i see no harm. Hi, I've added a little feature/setting to notification module. It now allows to set timeout for all notifications (not only default). I've decided to do this because of xchat (and maybe others). xchat's notification lasts 20s and there is no way how to change it. So there is a new checkbox in notification module settings (default false) to enable forced timeout for all notifications. I've also enlarged maximal timeout value (slider) from 6.0 to 15s If you find it useful / safe, please apply it. Thanks regards, Libor -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] e_dbus notification
On Thu, 07 Jul 2011 14:30:58 +0200 Libor Zoubek lzou...@jezzovo.net said: I got your point, finally :-) I haven't thought about e_dbus notification to act as client (which would report notifications to other but e server). Attached patch v2 and.. finally in svn! thanks very muchly! :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] Add XIM module for ecore_imf
On Mon, 11 Jul 2011 08:43:28 -0300 Iván Briano (Sachiel) sachi...@gmail.com said: I know that everyone and their mothers will use Elm_Win or at least Ecore_Evas, but if this patch goes in, then we'll be saying that that's the only way to use Edje. Ideally, we need a way to keep Edje as ignorant as it is today of those details if you're not using ecore_evas.. you're 99.999% likely also not interested in ecore_imf :) i'd say that this patch is good. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] Add XIM module for ecore_imf
On Mon, 25 Jul 2011 10:25:47 -0300 Iván Briano (Sachiel) sachi...@gmail.com said: see my reply to your other mail. the ecore_evas way imho is fine. edje already requires ecore and evas - if you use these 2 and dont use ecore_evas... you're the only one in the world i would guess. :) if this makes ecore_evas an implicit requirement, then so be it. :) 2011/7/22 Jihoon Kim jihoon48@samsung.com: As for getting the right window in Edje, raster proposed an edje_object_window_set() that would be used for every Edje object that will receive keyboard input. Hello, raster. Do you have any idea to solve this portability issue? I have one. I didn't check if it's possible to fetch a window from whatever engine Evas is using, but if it's not, then we are in the same situation as we are now and we need to add a function somewhere to say This is the window we are using. Raster already suggested adding such a function to Edje and have programs or toolkits set the window id on the edje_object, but I don't like that. What we can do is ask Evas what the window is, and be it a new engine function that gets it from its own info or a new function to set the window for the canvas, in the end it could be much simpler and have Ecore_Evas already set it in one place. Resuming, I propose void * evas_window_id_get(const Evas *e); and maybe void evas_window_id_set(Evas *e, void *window_id); Names can be changed if you don't like them, maybe something like void * evas_gimme_da_window_yo(Evas *e); -Original Message- From: Iván Briano (Sachiel) [mailto:sachi...@gmail.com] Sent: Sunday, July 10, 2011 4:08 PM To: Jihoon Kim Cc: Naruto TAKAHASHI; Mike McCormack; enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] [Patch] Add XIM module for ecore_imf Hello people, Some bad-ass top-posting because I feel like it. These patches seem to be fine except for two things: 1.- Dead keys is broken and I'm not sure why, but let's forget about that for now. (dead keys is what makes some us type ' + a and get á) 2.- It doesn't work in any way with Elementary_Entry, or Edje_Entry for that matter. The thing is, it doesn't work because Edje_Entry is using Ecore_IMF wrong. ecore_imf_context_client_window_set() expects to receive whatever specifies the id of the window the canvas lives in. For most of us, that's an Ecore_X_Window, but it could also be an Ecore_Win32_Window or an Ecore_DirectFB_Window. Within Edje it shouldn't matter which is it for portability reasons and that's not really the problem, except we currently have no easy way of fetching this window in edje_entry.c The biggest problem I see now, however, is that all the work done by Samsung on this IMF thing tells me that it's working fine for you, even when Edje is calling this ecore_imf_context_client_window_set() function setting an Evas_Object as the window. This is *wrong* and once we decide what the right way for Edje to fetch the window to set there, everything you have that relies on the current usage will break. So, cooperation will be required to get this sorted out. Other than the patches sent for Edje and Ecore_IMF, we have nothing that tells us how Samsung is using this and the patches sent by Naruto Takahashi here, once Edje is fixed, would let everyone use Edje, Elementary and E17 with widely available input methods systems like SCIM and IBus. As for getting the right window in Edje, raster proposed an edje_object_window_set() that would be used for every Edje object that will receive keyboard input. For obvious reasons, I prefer something more automatic, but it may be the case that this is the only sane choice. Regards, Zombie Sachiel 2011/7/9 Naruto TAKAHASHI tnar...@gmail.com: Hi Mike. Thanks, feedback. I merged it to xim/Makefile.am. I attach a source code for using XIM module debug. This program can check a below behaviors. - toggle enable and disable XIM - commit string from XIM Another test, by using Desktop Entry Editor's text field. (Enlightenment Main-Settings-Settings Panel-New Application) When executing test program, set ECORE_IMF_MODULE=xim. Thanks. 2011/7/8 Mike McCormack mj.mccorm...@samsung.com: On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote: Hi, All. I attached some patches of XIM module of ecore_imf. As far as I know, EFL has not having official ecore_imf module in E repository. And ecore_x has XIM code but is unavailable condition. So I moved XIM code of ecore_x as ecore_imf module. please review this patches. Hello Naruto, Looks like nice work. I applied your patches to my ecore and built, but there was a build error (fix below): make[5]: Entering directory `/home/mike/git/e/ecore/src/modules/immodules/xim' CC xim_la-ecore_imf_xim.lo ecore_imf_xim.c:5:18: error: Evas.h: No such file or
Re: [E-devel] E SVN: discomfitor IN trunk/elementary/src: bin lib
On Tue, 26 Jul 2011 02:38:23 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: THE MOST ANTICIPATED COMMIT OF 2011: HUGENORMOUS TOOLTIPS!! these bad boys are so big and pixelthirsty they can't be constrained by a regular canvas or window, they use OVERRIDE REDIRECT WINDOWS. not only that, they totally exceed the boundaries of what a reasonable function name length could be. 50 character function name limit? puh-leeze. these guys don't care what side of the screen they're even on so long as they get to wade into the thick of the action and block out each and every crappy non-efl application behind them. and that's when they're in good moods. you don't even want to know what happens when you piss these guys off. Author: discomfitor Date: 2011-07-26 02:38:23 -0700 (Tue, 26 Jul 2011) New Revision: 61735 Trac: http://trac.enlightenment.org/e/changeset/61735 Modified: trunk/elementary/src/bin/test_tooltip.c trunk/elementary/src/lib/Elementary.h.in trunk/elementary/src/lib/elm_gengrid.c trunk/elementary/src/lib/elm_genlist.c trunk/elementary/src/lib/elm_list.c trunk/elementary/src/lib/elm_widget.c trunk/elementary/src/lib/elm_widget.h trunk/elementary/src/lib/els_tooltip.c when you piss them off they totally break tooltip api like they just did -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] Add XIM module for ecore_imf
On Mon, 11 Jul 2011 10:41:48 +0900 Jihoon Kim jihoon48@samsung.com said: this was the right thing to do. patch in svn. Hell, Briano and EFL people. It is because I misunderstood about the parameter of ecore_imf_context_client_window_set API. ATM, we haven’t used the parameter of ecore_imf_context_client_window_set as the important parameter We just use 'canvas (Evas *) information' of ecore_imf_context_client_canvas_set instead of 'client window' information. Therefore, it will not affect to our project. :) Thank you for your reporting and interest about IMF. I send the patch to fix this problem. Is there anyone to review this patch and apply in svn? -Original Message- From: Iván Briano (Sachiel) [mailto:sachi...@gmail.com] Sent: Sunday, July 10, 2011 4:08 PM To: Jihoon Kim Cc: Naruto TAKAHASHI; Mike McCormack; enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] [Patch] Add XIM module for ecore_imf Hello people, Some bad-ass top-posting because I feel like it. These patches seem to be fine except for two things: 1.- Dead keys is broken and I'm not sure why, but let's forget about that for now. (dead keys is what makes some us type ' + a and get á) 2.- It doesn't work in any way with Elementary_Entry, or Edje_Entry for that matter. The thing is, it doesn't work because Edje_Entry is using Ecore_IMF wrong. ecore_imf_context_client_window_set() expects to receive whatever specifies the id of the window the canvas lives in. For most of us, that's an Ecore_X_Window, but it could also be an Ecore_Win32_Window or an Ecore_DirectFB_Window. Within Edje it shouldn't matter which is it for portability reasons and that's not really the problem, except we currently have no easy way of fetching this window in edje_entry.c The biggest problem I see now, however, is that all the work done by Samsung on this IMF thing tells me that it's working fine for you, even when Edje is calling this ecore_imf_context_client_window_set() function setting an Evas_Object as the window. This is *wrong* and once we decide what the right way for Edje to fetch the window to set there, everything you have that relies on the current usage will break. So, cooperation will be required to get this sorted out. Other than the patches sent for Edje and Ecore_IMF, we have nothing that tells us how Samsung is using this and the patches sent by Naruto Takahashi here, once Edje is fixed, would let everyone use Edje, Elementary and E17 with widely available input methods systems like SCIM and IBus. As for getting the right window in Edje, raster proposed an edje_object_window_set() that would be used for every Edje object that will receive keyboard input. For obvious reasons, I prefer something more automatic, but it may be the case that this is the only sane choice. Regards, Zombie Sachiel 2011/7/9 Naruto TAKAHASHI tnar...@gmail.com: Hi Mike. Thanks, feedback. I merged it to xim/Makefile.am. I attach a source code for using XIM module debug. This program can check a below behaviors. - toggle enable and disable XIM - commit string from XIM Another test, by using Desktop Entry Editor's text field. (Enlightenment Main-Settings-Settings Panel-New Application) When executing test program, set ECORE_IMF_MODULE=xim. Thanks. 2011/7/8 Mike McCormack mj.mccorm...@samsung.com: On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote: Hi, All. I attached some patches of XIM module of ecore_imf. As far as I know, EFL has not having official ecore_imf module in E repository. And ecore_x has XIM code but is unavailable condition. So I moved XIM code of ecore_x as ecore_imf module. please review this patches. Hello Naruto, Looks like nice work. I applied your patches to my ecore and built, but there was a build error (fix below): make[5]: Entering directory `/home/mike/git/e/ecore/src/modules/immodules/xim' CC xim_la-ecore_imf_xim.lo ecore_imf_xim.c:5:18: error: Evas.h: No such file or directory ecore_imf_xim.c: In function ‘_ecore_x_event_reverse_locks’: ecore_imf_xim.c:359: warning: suggest braces around empty body in an ‘if’ statement ecore_imf_xim.c: In function ‘preedit_start_callback’: ecore_imf_xim.c:662: warning: unused parameter ‘xic’ ecore_imf_xim.c:664: warning: unused parameter ‘call_data’ How can I test it? thanks, Mike diff --git a/ecore/src/modules/immodules/xim/Makefile.am b/ecore/src/modules/immodules/xim/Makefile.am index 006035c..cc0682d 100644 --- a/ecore/src/modules/immodules/xim/Makefile.am +++ b/ecore/src/modules/immodules/xim/Makefile.am @@ -12,6 +12,7 @@ AM_CPPFLAGS = \ -I$(top_builddir)/src/lib/ecore_imf \ -DPACKAGE_LIB_DIR=\$(libdir)\ \ -DPACKAGE_DATA_DIR=\$(datadir)/$(PACKAGE)\ \ +@EVAS_CFLAGS@ \ @EINA_CFLAGS@ pkgdir = $(libdir)/ecore/immodules
Re: [E-devel] [Patch] Add XIM module for ecore_imf
On Sat, 23 Jul 2011 22:22:10 +0900 Jihoon Kim imfin...@gmail.com said: i fixed this one in svn already :) Hi, Naruto. I've tested in elementary_test entry menu after applying my edje patch related to client_window_set. However, I couldn't see the preedit string in the entry widget while I was typing. In addition, sometimes segmentation fault was occured. Here is backtrace of GDB. (gdb) bt #0 0x0030fb62 in eina_unicode_strlen (ustr=0x0) at eina_unicode.c:70 #1 0x003105dc in eina_unicode_unicode_to_utf8 (uni=0x0, _len=0xb184) at eina_unicode.c:331 #2 0x00efd7b3 in _ecore_imf_context_xim_preedit_string_get (ctx=0x8251b28, str=0xb1d8, cursor_pos=0xb1dc) at ecore_imf_xim.c:179 #3 0x004736d6 in ecore_imf_context_preedit_string_get (ctx=0x8251b28, str=0xb1d8, cursor_pos=0xb1dc) at ecore_imf_context.c:388 #4 0x004d4c44 in _edje_entry_imf_event_preedit_changed_cb (data=0x8333628, type=79, event=0x838f0b8) at edje_entry.c:2887 #5 0x00428ac6 in _ecore_event_call () at ecore_events.c:693 #6 0x0042f4d2 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:1750 #7 0x0042dc49 in ecore_main_loop_begin () at ecore_main.c:848 #8 0x001d08cc in elm_run () at elm_main.c:1075 #9 0x0805551b in elm_main (argc=1, argv=0xb3a4) at test.c:489 #10 0x0804 in main (argc=1, argv=0xb3a4) at test.c:498 2011/7/23 Naruto TAKAHASHI tnar...@gmail.com Hi JihoonKim, and EFL developers. I attach a patch for fixing some XIM module bugs. - fix showing previous preedit string bug. - delete compile warning(thanks JihoonKim) - fix some sequence issue to send preedit changed event and commit event.(thanks JihoonKim) Please review this patch? Regards. 2011年7月22日23:52 Naruto TAKAHASHI tnar...@gmail.com: Hi, JihoonKim. I talked to you how fix preedit draw callback direction on IRC. I repeat to talk this stuff for didn't see this talk. Your patch behavior is no problem. But Preedit Draw Callback needs insert, delete, and replace by referencing Preedit Draw Callback argument. (detail: http://static.cray-cyber.org/Documentation/NEC_SX_R10_1/G1AE02E/CHAP13.HTML#13.18.6 . Preedit Draw Callback) I'm trying to fix too easy routine by using Eina_UStrBuf, now. So, please wait this. Off course, I merge deleting comple warning of your patch with thanks. :) Thanks. 2011/7/17 Jihoon Kim imfin...@gmail.com: Hi, Naruto. As I told you last Friday on IRC, I guess there are some bugs in your xim immodule. For example, in case that I'd like to input '私の' (watasino), the preedit string was got from your immodule like below '私のしの'. In addition, there are some sequence issue to send preedit changed event and commit event. I've tried to fix this problem and send you the patch. (I've tested on elementary_test entry) If you don't mind uploading this patch to svn, I'll request Maintainers to upload this patch. Thanks. On Sun, Jul 10, 2011 at 2:51 AM, Naruto TAKAHASHI tnar...@gmail.com wrote: Hi Mike. Thanks, feedback. I merged it to xim/Makefile.am. I attach a source code for using XIM module debug. This program can check a below behaviors. - toggle enable and disable XIM - commit string from XIM Another test, by using Desktop Entry Editor's text field. (Enlightenment Main-Settings-Settings Panel-New Application) When executing test program, set ECORE_IMF_MODULE=xim. Thanks. 2011/7/8 Mike McCormack mj.mccorm...@samsung.com: On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote: Hi, All. I attached some patches of XIM module of ecore_imf. As far as I know, EFL has not having official ecore_imf module in E repository. And ecore_x has XIM code but is unavailable condition. So I moved XIM code of ecore_x as ecore_imf module. please review this patches. Hello Naruto, Looks like nice work. I applied your patches to my ecore and built, but there was a build error (fix below): make[5]: Entering directory `/home/mike/git/e/ecore/src/modules/immodules/xim' CC xim_la-ecore_imf_xim.lo ecore_imf_xim.c:5:18: error: Evas.h: No such file or directory ecore_imf_xim.c: In function ‘_ecore_x_event_reverse_locks’: ecore_imf_xim.c:359: warning: suggest braces around empty body in an ‘if’ statement ecore_imf_xim.c: In function ‘preedit_start_callback’: ecore_imf_xim.c:662: warning: unused parameter ‘xic’ ecore_imf_xim.c:664: warning: unused parameter ‘call_data’ How can I test it? thanks, Mike diff --git a/ecore/src/modules/immodules/xim/Makefile.am b/ecore/src/modules/immodules/xim/Makefile.am index 006035c..cc0682d 100644 --- a/ecore/src/modules/immodules/xim/Makefile.am +++ b/ecore/src/modules/immodules/xim/Makefile.am
Re: [E-devel] [Patch] Add XIM module for ecore_imf
On Sat, 23 Jul 2011 19:14:36 +0900 Naruto TAKAHASHI tnar...@gmail.com said: fixes patch in - warnings were already fixed :) Hi, Vencent. (I forgeted adding e-devel ML address to Cc. So send again.) split your patch in 3 patches (the 3 things above). Or at least 2 patches (one for the warnings, the other for the fixes). I split my patch to 2 paches. one for warnings, the other for fixes. Thanks. 2011/7/23 Vincent Torri vto...@univ-evry.fr: hey On Sat, 23 Jul 2011, Naruto TAKAHASHI wrote: Hi JihoonKim, and EFL developers. I attach a patch for fixing some XIM module bugs. - fix showing previous preedit string bug. - delete compile warning(thanks JihoonKim) - fix some sequence issue to send preedit changed event and commit event.(thanks JihoonKim) Please review this patch? split your patch in 3 patches (the 3 things above). Or at least 2 patches (one for the warnings, the other for the fixes). Vincent Regards. 2011年7月22日23:52 Naruto TAKAHASHI tnar...@gmail.com: Hi, JihoonKim. I talked to you how fix preedit draw callback direction on IRC. I repeat to talk this stuff for didn't see this talk. Your patch behavior is no problem. But Preedit Draw Callback needs insert, delete, and replace by referencing Preedit Draw Callback argument. (detail: http://static.cray-cyber.org/Documentation/NEC_SX_R10_1/G1AE02E/CHAP13.HTML#13.18.6. Preedit Draw Callback) I'm trying to fix too easy routine by using Eina_UStrBuf, now. So, please wait this. Off course, I merge deleting comple warning of your patch with thanks. :) Thanks. 2011/7/17 Jihoon Kim imfin...@gmail.com: Hi, Naruto. As I told you last Friday on IRC, I guess there are some bugs in your xim immodule. For example, in case that I'd like to input '私の' (watasino), the preedit string was got from your immodule like below '私のしの'. In addition, there are some sequence issue to send preedit changed event and commit event. I've tried to fix this problem and send you the patch. (I've tested on elementary_test entry) If you don't mind uploading this patch to svn, I'll request Maintainers to upload this patch. Thanks. On Sun, Jul 10, 2011 at 2:51 AM, Naruto TAKAHASHI tnar...@gmail.com wrote: Hi Mike. Thanks, feedback. I merged it to xim/Makefile.am. I attach a source code for using XIM module debug. This program can check a below behaviors. - toggle enable and disable XIM - commit string from XIM Another test, by using Desktop Entry Editor's text field. (Enlightenment Main-Settings-Settings Panel-New Application) When executing test program, set ECORE_IMF_MODULE=xim. Thanks. 2011/7/8 Mike McCormack mj.mccorm...@samsung.com: On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote: Hi, All. I attached some patches of XIM module of ecore_imf. As far as I know, EFL has not having official ecore_imf module in E repository. And ecore_x has XIM code but is unavailable condition. So I moved XIM code of ecore_x as ecore_imf module. please review this patches. Hello Naruto, Looks like nice work. I applied your patches to my ecore and built, but there was a build error (fix below): make[5]: Entering directory `/home/mike/git/e/ecore/src/modules/immodules/xim' CC xim_la-ecore_imf_xim.lo ecore_imf_xim.c:5:18: error: Evas.h: No such file or directory ecore_imf_xim.c: In function ‘_ecore_x_event_reverse_locks’: ecore_imf_xim.c:359: warning: suggest braces around empty body in an ‘if’ statement ecore_imf_xim.c: In function ‘preedit_start_callback’: ecore_imf_xim.c:662: warning: unused parameter ‘xic’ ecore_imf_xim.c:664: warning: unused parameter ‘call_data’ How can I test it? thanks, Mike diff --git a/ecore/src/modules/immodules/xim/Makefile.am b/ecore/src/modules/immodules/xim/Makefile.am index 006035c..cc0682d 100644 --- a/ecore/src/modules/immodules/xim/Makefile.am +++ b/ecore/src/modules/immodules/xim/Makefile.am @@ -12,6 +12,7 @@ AM_CPPFLAGS = \ -I$(top_builddir)/src/lib/ecore_imf \ -DPACKAGE_LIB_DIR=\$(libdir)\ \ -DPACKAGE_DATA_DIR=\$(datadir)/$(PACKAGE)\ \ +@EVAS_CFLAGS@ \ @EINA_CFLAGS@ pkgdir = $(libdir)/ecore/immodules -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Naruto TAKAHASHI tnar...@gmail.com
Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore
On Tue, 26 Jul 2011 09:11:54 +0200 (CEST) Vincent Torri vto...@univ-evry.fr
said:
i want 1.1 out in the very near future. waiting on some pending things like
improved docs to settle then we go on a 1.1 binge. i'm going through my backlog
atm though.
backport to 1.0 ?
Vincent
On Tue, 26 Jul 2011, Enlightenment SVN wrote:
Log:
fix timer precision handling to do what it was meant to do to begin with
Author: raster
Date: 2011-07-26 00:01:55 -0700 (Tue, 26 Jul 2011)
New Revision: 61730
Trac: http://trac.enlightenment.org/e/changeset/61730
Modified:
trunk/ecore/ChangeLog trunk/ecore/src/lib/ecore/ecore_timer.c
Modified: trunk/ecore/ChangeLog
===
--- trunk/ecore/ChangeLog 2011-07-26 07:00:19 UTC (rev 61729)
+++ trunk/ecore/ChangeLog 2011-07-26 07:01:55 UTC (rev 61730)
@@ -263,3 +263,9 @@
2011-07-22 Mike Blumenkrantz
* Added ecore_con_url_url_get
+
+2011-07-26 Carsten Haitzler (The Rasterman)
+
+* Fix timer precision handling for grouping timer ticks so
+they actually do tick off together
+
Modified: trunk/ecore/src/lib/ecore/ecore_timer.c
===
--- trunk/ecore/src/lib/ecore/ecore_timer.c 2011-07-26 07:00:19 UTC
(rev 61729) +++ trunk/ecore/src/lib/ecore/ecore_timer.c 2011-07-26
07:01:55 UTC (rev 61730) @@ -590,15 +590,17 @@
_ecore_timer_after_get(Ecore_Timer *base)
{
Ecore_Timer *timer = (Ecore_Timer *) EINA_INLIST_GET(base)-next;
+ Ecore_Timer *valid_timer = NULL;
double maxtime = base-at + precision;
- while ((timer) ((timer-delete_me) || (timer-just_added))
(timer-at = maxtime))
- timer = (Ecore_Timer *) EINA_INLIST_GET(timer)-next;
+ while ((timer) (timer-at maxtime))
+ {
+if (!((timer-delete_me) || (timer-just_added)))
+ valid_timer = timer;
+timer = (Ecore_Timer *) EINA_INLIST_GET(timer)-next;
+ }
- if ((!timer) || (timer-at maxtime))
- return NULL;
-
- return timer;
+ return valid_timer;
}
double
@@ -612,8 +614,7 @@
if (!first) return -1;
second = _ecore_timer_after_get(first);
- if (second)
- first = second;
+ if (second) first = second;
now = ecore_loop_time_get();
in = first-at - now;
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
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
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor IN trunk/elementary/src: bin lib
Stu!!! It's hard to figure out what you've broken with this big commit! Btw, I think elm_toolip/gengrid/genlist/list_size_restrict_disable should be changed. EAPI Eina_Bool elm_tooltip_size_restrict_disable(Evas_Object *obj, Eina_Bool disable) -- EAPI void elm_tooltip_size_restrict_disabled_set(Evas_Object *obj, Eina_Bool disabled) See other elm_xxx_disabled_set APIs. Thanks. Daniel Juyung Seo (SeoZ) On Tue, Jul 26, 2011 at 6:42 PM, Mike Blumenkrantz m...@zentific.com wrote: On Tue, 26 Jul 2011 02:38:23 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: THE MOST ANTICIPATED COMMIT OF 2011: HUGENORMOUS TOOLTIPS!! these bad boys are so big and pixelthirsty they can't be constrained by a regular canvas or window, they use OVERRIDE REDIRECT WINDOWS. not only that, they totally exceed the boundaries of what a reasonable function name length could be. 50 character function name limit? puh-leeze. these guys don't care what side of the screen they're even on so long as they get to wade into the thick of the action and block out each and every crappy non-efl application behind them. and that's when they're in good moods. you don't even want to know what happens when you piss these guys off. Author: discomfitor Date: 2011-07-26 02:38:23 -0700 (Tue, 26 Jul 2011) New Revision: 61735 Trac: http://trac.enlightenment.org/e/changeset/61735 Modified: trunk/elementary/src/bin/test_tooltip.c trunk/elementary/src/lib/Elementary.h.in trunk/elementary/src/lib/elm_gengrid.c trunk/elementary/src/lib/elm_genlist.c trunk/elementary/src/lib/elm_list.c trunk/elementary/src/lib/elm_widget.c trunk/elementary/src/lib/elm_widget.h trunk/elementary/src/lib/els_tooltip.c when you piss them off they totally break tooltip api like they just did -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Problem about the positon of candidate window in Ibus or SCIM
Hey, raster.
Like you told me, there is some problem that the candidate word window is
located on the wrong position
when ecore_imf works with xim immodule.
To solve this problem, I've tried to make the patch file, but it does not
work well at this moment.
I've made this patch referring to gtk xim module.
I've tested with GTK application, but GTK application also have same
problem.
This patch should be applied after applying the patch I sent
(http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg33
889.html)
If you have the XIM knowledge, would you please let me know the solution?
Index: ecore_imf_xim.c
===
--- ecore_imf_xim.c (revision 61754)
+++ ecore_imf_xim.c (working copy)
@@ -332,7 +332,38 @@ _ecore_imf_context_xim_use_preedit_set(Ecore_IMF_C
#endif
}
+static void
+_ecore_imf_context_xim_cursor_location_set (Ecore_IMF_Context *ctx,
+int x, int y, int w __UNUSED__,
int h)
+{
+ EINA_LOG_DBG(%s in, __FUNCTION__);
+
#ifdef ENABLE_XIM
+ Ecore_IMF_Context_Data *imf_context_data;
+ XIC ic;
+ XVaNestedList preedit_attr;
+ XPointspot;
+
+ imf_context_data = ecore_imf_context_data_get(ctx);
+ ic = imf_context_data-ic;
+ if (!ic)
+ return;
+
+ spot.x = x;
+ spot.y = y + h;
+
+ preedit_attr = XVaCreateNestedList (0,
+ XNSpotLocation, spot,
+ NULL);
+ XSetICValues (ic,
+ XNPreeditAttributes, preedit_attr,
+ NULL);
+
+ XFree(preedit_attr);
+#endif
+}
+
+#ifdef ENABLE_XIM
static unsigned int
_ecore_x_event_reverse_modifiers(unsigned int state)
{
@@ -585,7 +616,7 @@ static Ecore_IMF_Context_Class xim_class = {
.input_panel_layout_get = NULL,
.input_panel_language_set = NULL,
.input_panel_language_get = NULL,
- .cursor_location_set = NULL,
+ .cursor_location_set = _ecore_imf_context_xim_cursor_location_set,
};
static Ecore_IMF_Context *
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor IN trunk/elementary/src: bin lib
And one question. Tooltip file name is els_tooltip.c which means it's internal widget in elm. The APIs need to be open by other widget or as elm_object_tooltip_xxx. How do you think? I know there were elm_tooltip_delay_get/set() but this should be discussed. Thanks. Daniel Juyung Seo (SeoZ) On Tue, Jul 26, 2011 at 9:18 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote: Stu!!! It's hard to figure out what you've broken with this big commit! Btw, I think elm_toolip/gengrid/genlist/list_size_restrict_disable should be changed. EAPI Eina_Bool elm_tooltip_size_restrict_disable(Evas_Object *obj, Eina_Bool disable) -- EAPI void elm_tooltip_size_restrict_disabled_set(Evas_Object *obj, Eina_Bool disabled) See other elm_xxx_disabled_set APIs. Thanks. Daniel Juyung Seo (SeoZ) On Tue, Jul 26, 2011 at 6:42 PM, Mike Blumenkrantz m...@zentific.com wrote: On Tue, 26 Jul 2011 02:38:23 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: THE MOST ANTICIPATED COMMIT OF 2011: HUGENORMOUS TOOLTIPS!! these bad boys are so big and pixelthirsty they can't be constrained by a regular canvas or window, they use OVERRIDE REDIRECT WINDOWS. not only that, they totally exceed the boundaries of what a reasonable function name length could be. 50 character function name limit? puh-leeze. these guys don't care what side of the screen they're even on so long as they get to wade into the thick of the action and block out each and every crappy non-efl application behind them. and that's when they're in good moods. you don't even want to know what happens when you piss these guys off. Author: discomfitor Date: 2011-07-26 02:38:23 -0700 (Tue, 26 Jul 2011) New Revision: 61735 Trac: http://trac.enlightenment.org/e/changeset/61735 Modified: trunk/elementary/src/bin/test_tooltip.c trunk/elementary/src/lib/Elementary.h.in trunk/elementary/src/lib/elm_gengrid.c trunk/elementary/src/lib/elm_genlist.c trunk/elementary/src/lib/elm_list.c trunk/elementary/src/lib/elm_widget.c trunk/elementary/src/lib/elm_widget.h trunk/elementary/src/lib/els_tooltip.c when you piss them off they totally break tooltip api like they just did -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns IN trunk/ecore/src/lib/ecore_x: . xcb xlib
Hmm... I think this just broke my ecore_x. Having problems now like:
CC ecore_x_damage.lo
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c: In
function 'ecore_x_default_visual_get':
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c:1919:
error: array subscript is not an integer
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c: In
function 'ecore_x_default_colormap_get':
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c:1934:
error: array subscript is not an integer
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c: In
function 'ecore_x_default_depth_get':
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c:1949:
error: array subscript is not an integer
On Tue, Jul 26, 2011 at 8:19 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Ecore_X: Add some new api functions for getting default
Depth/Visual/Colormap of a given screen.
NB: Added these so that we can remove xlib specific calls in
ecore_evas and just generic ecore_x calls (so we are engine
independant).
Author: devilhorns
Date: 2011-07-26 04:19:55 -0700 (Tue, 26 Jul 2011)
New Revision: 61742
Trac: http://trac.enlightenment.org/e/changeset/61742
Modified:
trunk/ecore/src/lib/ecore_x/Ecore_X.h
trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c
trunk/ecore/src/lib/ecore_x/xlib/ecore_x.c
Modified: trunk/ecore/src/lib/ecore_x/Ecore_X.h
===
--- trunk/ecore/src/lib/ecore_x/Ecore_X.h 2011-07-26 11:18:48 UTC (rev
61741)
+++ trunk/ecore/src/lib/ecore_x/Ecore_X.h 2011-07-26 11:19:55 UTC (rev
61742)
@@ -1089,6 +1089,9 @@
EAPI Ecore_X_Screen * ecore_x_default_screen_get(void);
EAPI void ecore_x_screen_size_get(const Ecore_X_Screen
*screen, int *w, int *h);
EAPI int ecore_x_screen_count_get(void);
+EAPI int ecore_x_screen_index_get(const Ecore_X_Screen
*screen);
+EAPI Ecore_X_Screen * ecore_x_screen_get(int index);
+
EAPI void ecore_x_double_click_time_set(double t);
EAPI double ecore_x_double_click_time_get(void);
EAPI void ecore_x_flush(void);
@@ -1099,6 +1102,10 @@
EAPI Eina_Bool ecore_x_bell(int percent);
EAPI unsigned int ecore_x_visual_id_get(Ecore_X_Visual visual);
+EAPI Ecore_X_Visual ecore_x_default_visual_get(Ecore_X_Display
*disp, Ecore_X_Screen *screen);
+EAPI Ecore_X_Colormap ecore_x_default_colormap_get(Ecore_X_Display
*disp, Ecore_X_Screen *screen);
+EAPI int ecore_x_default_depth_get(Ecore_X_Display
*disp, Ecore_X_Screen *screen);
+
EAPI Ecore_X_Time ecore_x_current_time_get(void);
EAPI void ecore_x_error_handler_set(void (*func)(void
*data), const void *data);
Modified: trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c
===
--- trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c 2011-07-26 11:18:48 UTC (rev
61741)
+++ trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c 2011-07-26 11:19:55 UTC (rev
61742)
@@ -1058,9 +1058,9 @@
}
/**
- * Retrieves the number of screens.
+ * Retrieves the count of screens.
*
- * @return The count of the number of screens.
+ * @return The count of screens.
* @ingroup Ecore_X_Display_Attr_Group
*
* @since 1.1
@@ -1073,6 +1073,54 @@
return xcb_setup_roots_length(xcb_get_setup(_ecore_xcb_conn));
}
+/**
+ * Retrieves the index number of the given screen.
+ *
+ * @return The index number of the screen.
+ * @ingroup Ecore_X_Display_Attr_Group
+ *
+ * @since 1.1
+ */
+EAPI int
+ecore_x_screen_index_get(const Ecore_X_Screen *screen)
+{
+ xcb_screen_iterator_t iter;
+
+ iter =
+ xcb_setup_roots_iterator(xcb_get_setup((xcb_connection_t
*)_ecore_xcb_conn));
+ for (; iter.rem; xcb_screen_next(iter))
+ {
+ if (iter.data == (xcb_screen_t *)screen)
+ return iter.index;
+ }
+
+ return 0;
+}
+
+/**
+ * Retrieves the screen based on index number.
+ *
+ * @return The Ecore_X_Screen at this index.
+ * @ingroup Ecore_X_Display_Attr_Group
+ *
+ * @since 1.1
+ */
+EAPI Ecore_X_Screen *
+ecore_x_screen_get(int index)
+{
+ xcb_screen_iterator_t iter;
+
+ iter =
+ xcb_setup_roots_iterator(xcb_get_setup((xcb_connection_t
*)_ecore_xcb_conn));
+ for (; iter.rem; xcb_screen_next(iter))
+ {
+ if (iter.index == index)
+ return iter.data;
+ }
+
+ return NULL;
+}
+
EAPI unsigned int
ecore_x_visual_id_get(Ecore_X_Visual visual)
{
@@ -1080,6 +1128,72 @@
}
/**
+ * Retrieve the default Visual.
+ *
+ * @param disp The Display to get the Default Visual from
+ * @param screen The Screen.
+ *
+ * @return The default visual.
+ * @since 1.1.0
+ */
Re: [E-devel] E SVN: devilhorns IN trunk/ecore/src/lib/ecore_x: . xcb xlib
Don't see how any of that is possible. The newly added functions do not
use any arrays, so 'array subscript is not an integer' isn't even valid.
But I will try a rebuild w/ xlib version just to be sure.
1919: return DefaultVisual(disp, screen);
dh
On 07/26/11 09:03, Rafael Antognolli wrote:
Hmm... I think this just broke my ecore_x. Having problems now like:
*
CC ecore_x_damage.lo
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c: In
function 'ecore_x_default_visual_get':
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c:1919:
error: array subscript is not an integer
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c: In
function 'ecore_x_default_colormap_get':
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c:1934:
error: array subscript is not an integer
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c: In
function 'ecore_x_default_depth_get':
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c:1949:
error: array subscript is not an integer
On Tue, Jul 26, 2011 at 8:19 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Ecore_X: Add some new api functions for getting default
Depth/Visual/Colormap of a given screen.
NB: Added these so that we can remove xlib specific calls in
ecore_evas and just generic ecore_x calls (so we are engine
independant).
Author: devilhorns
Date: 2011-07-26 04:19:55 -0700 (Tue, 26 Jul 2011)
New Revision: 61742
Trac: http://trac.enlightenment.org/e/changeset/61742
Modified:
trunk/ecore/src/lib/ecore_x/Ecore_X.h
trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c
trunk/ecore/src/lib/ecore_x/xlib/ecore_x.c
Modified: trunk/ecore/src/lib/ecore_x/Ecore_X.h
===
--- trunk/ecore/src/lib/ecore_x/Ecore_X.h 2011-07-26 11:18:48 UTC (rev
61741)
+++ trunk/ecore/src/lib/ecore_x/Ecore_X.h 2011-07-26 11:19:55 UTC (rev
61742)
@@ -1089,6 +1089,9 @@
EAPI Ecore_X_Screen *ecore_x_default_screen_get(void);
EAPI voidecore_x_screen_size_get(const Ecore_X_Screen
*screen, int *w, int *h);
EAPI int ecore_x_screen_count_get(void);
+EAPI int ecore_x_screen_index_get(const Ecore_X_Screen
*screen);
+EAPI Ecore_X_Screen *ecore_x_screen_get(int index);
+
EAPI voidecore_x_double_click_time_set(double t);
EAPI double ecore_x_double_click_time_get(void);
EAPI voidecore_x_flush(void);
@@ -1099,6 +1102,10 @@
EAPI Eina_Bool ecore_x_bell(int percent);
EAPI unsigned intecore_x_visual_id_get(Ecore_X_Visual visual);
+EAPI Ecore_X_Visual ecore_x_default_visual_get(Ecore_X_Display
*disp, Ecore_X_Screen *screen);
+EAPI Ecore_X_Colormapecore_x_default_colormap_get(Ecore_X_Display
*disp, Ecore_X_Screen *screen);
+EAPI int ecore_x_default_depth_get(Ecore_X_Display
*disp, Ecore_X_Screen *screen);
+
EAPI Ecore_X_Timeecore_x_current_time_get(void);
EAPI voidecore_x_error_handler_set(void (*func)(void
*data), const void *data);
Modified: trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c
===
--- trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c 2011-07-26 11:18:48 UTC (rev
61741)
+++ trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c 2011-07-26 11:19:55 UTC (rev
61742)
@@ -1058,9 +1058,9 @@
}
/**
- * Retrieves the number of screens.
+ * Retrieves the count of screens.
*
- * @return The count of the number of screens.
+ * @return The count of screens.
* @ingroup Ecore_X_Display_Attr_Group
*
* @since 1.1
@@ -1073,6 +1073,54 @@
return xcb_setup_roots_length(xcb_get_setup(_ecore_xcb_conn));
}
+/**
+ * Retrieves the index number of the given screen.
+ *
+ * @return The index number of the screen.
+ * @ingroup Ecore_X_Display_Attr_Group
+ *
+ * @since 1.1
+ */
+EAPI int
+ecore_x_screen_index_get(const Ecore_X_Screen *screen)
+{
+ xcb_screen_iterator_t iter;
+
+ iter =
+ xcb_setup_roots_iterator(xcb_get_setup((xcb_connection_t
*)_ecore_xcb_conn));
+ for (; iter.rem; xcb_screen_next(iter))
+ {
+if (iter.data == (xcb_screen_t *)screen)
+ return iter.index;
+ }
+
+ return 0;
+}
+
+/**
+ * Retrieves the screen based on index number.
+ *
+ * @return The Ecore_X_Screen at this index.
+ * @ingroup Ecore_X_Display_Attr_Group
+ *
+ * @since 1.1
+ */
+EAPI Ecore_X_Screen *
+ecore_x_screen_get(int index)
+{
+ xcb_screen_iterator_t iter;
+
+ iter =
+ xcb_setup_roots_iterator(xcb_get_setup((xcb_connection_t
*)_ecore_xcb_conn));
+ for (; iter.rem; xcb_screen_next(iter))
+ {
+if (iter.index == index)
+ return
Re: [E-devel] E SVN: devilhorns IN trunk/ecore/src/lib/ecore_x: . xcb xlib
AHHH, you are correct. Will fix now.
dh
On 07/26/11 09:08, Christopher Michael wrote:
Don't see how any of that is possible. The newly added functions do not
use any arrays, so 'array subscript is not an integer' isn't even valid.
But I will try a rebuild w/ xlib version just to be sure.
1919: return DefaultVisual(disp, screen);
dh
On 07/26/11 09:03, Rafael Antognolli wrote:
Hmm... I think this just broke my ecore_x. Having problems now like:
*
CC ecore_x_damage.lo
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c: In
function 'ecore_x_default_visual_get':
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c:1919:
error: array subscript is not an integer
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c: In
function 'ecore_x_default_colormap_get':
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c:1934:
error: array subscript is not an integer
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c: In
function 'ecore_x_default_depth_get':
/home/antognolli/e17/git_e17/ecore/src/lib/ecore_x/xlib/ecore_x.c:1949:
error: array subscript is not an integer
On Tue, Jul 26, 2011 at 8:19 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Ecore_X: Add some new api functions for getting default
Depth/Visual/Colormap of a given screen.
NB: Added these so that we can remove xlib specific calls in
ecore_evas and just generic ecore_x calls (so we are engine
independant).
Author: devilhorns
Date: 2011-07-26 04:19:55 -0700 (Tue, 26 Jul 2011)
New Revision: 61742
Trac: http://trac.enlightenment.org/e/changeset/61742
Modified:
trunk/ecore/src/lib/ecore_x/Ecore_X.h
trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c
trunk/ecore/src/lib/ecore_x/xlib/ecore_x.c
Modified: trunk/ecore/src/lib/ecore_x/Ecore_X.h
===
--- trunk/ecore/src/lib/ecore_x/Ecore_X.h 2011-07-26 11:18:48 UTC
(rev 61741)
+++ trunk/ecore/src/lib/ecore_x/Ecore_X.h 2011-07-26 11:19:55 UTC
(rev 61742)
@@ -1089,6 +1089,9 @@
EAPI Ecore_X_Screen *ecore_x_default_screen_get(void);
EAPI voidecore_x_screen_size_get(const
Ecore_X_Screen *screen, int *w, int *h);
EAPI int ecore_x_screen_count_get(void);
+EAPI int ecore_x_screen_index_get(const Ecore_X_Screen
*screen);
+EAPI Ecore_X_Screen *ecore_x_screen_get(int index);
+
EAPI voidecore_x_double_click_time_set(double t);
EAPI double ecore_x_double_click_time_get(void);
EAPI voidecore_x_flush(void);
@@ -1099,6 +1102,10 @@
EAPI Eina_Bool ecore_x_bell(int percent);
EAPI unsigned intecore_x_visual_id_get(Ecore_X_Visual
visual);
+EAPI Ecore_X_Visual ecore_x_default_visual_get(Ecore_X_Display
*disp, Ecore_X_Screen *screen);
+EAPI Ecore_X_Colormapecore_x_default_colormap_get(Ecore_X_Display
*disp, Ecore_X_Screen *screen);
+EAPI int ecore_x_default_depth_get(Ecore_X_Display
*disp, Ecore_X_Screen *screen);
+
EAPI Ecore_X_Timeecore_x_current_time_get(void);
EAPI voidecore_x_error_handler_set(void (*func)(void
*data), const void *data);
Modified: trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c
===
--- trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c 2011-07-26 11:18:48 UTC
(rev 61741)
+++ trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb.c 2011-07-26 11:19:55 UTC
(rev 61742)
@@ -1058,9 +1058,9 @@
}
/**
- * Retrieves the number of screens.
+ * Retrieves the count of screens.
*
- * @return The count of the number of screens.
+ * @return The count of screens.
* @ingroup Ecore_X_Display_Attr_Group
*
* @since 1.1
@@ -1073,6 +1073,54 @@
return xcb_setup_roots_length(xcb_get_setup(_ecore_xcb_conn));
}
+/**
+ * Retrieves the index number of the given screen.
+ *
+ * @return The index number of the screen.
+ * @ingroup Ecore_X_Display_Attr_Group
+ *
+ * @since 1.1
+ */
+EAPI int
+ecore_x_screen_index_get(const Ecore_X_Screen *screen)
+{
+ xcb_screen_iterator_t iter;
+
+ iter =
+ xcb_setup_roots_iterator(xcb_get_setup((xcb_connection_t
*)_ecore_xcb_conn));
+ for (; iter.rem; xcb_screen_next(iter))
+ {
+if (iter.data == (xcb_screen_t *)screen)
+ return iter.index;
+ }
+
+ return 0;
+}
+
+/**
+ * Retrieves the screen based on index number.
+ *
+ * @return The Ecore_X_Screen at this index.
+ * @ingroup Ecore_X_Display_Attr_Group
+ *
+ * @since 1.1
+ */
+EAPI Ecore_X_Screen *
+ecore_x_screen_get(int index)
+{
+ xcb_screen_iterator_t iter;
+
+ iter =
+ xcb_setup_roots_iterator(xcb_get_setup((xcb_connection_t
Re: [E-devel] E SVN: devilhorns trunk/e/src/bin
need braces to compile this?
what's the difference?
Daniel Juyung Seo (SeoZ)
On Jul 26, 2011 11:04 PM, Enlightenment SVN no-re...@enlightenment.org
wrote:
Log:
E: Grrr, fix previous commit to actually compile.
Author: devilhorns
Date: 2011-07-26 07:04:14 -0700 (Tue, 26 Jul 2011)
New Revision: 61762
Trac: http://trac.enlightenment.org/e/changeset/61762
Modified:
trunk/e/src/bin/e_main.c
Modified: trunk/e/src/bin/e_main.c
===
--- trunk/e/src/bin/e_main.c 2011-07-26 14:00:54 UTC (rev 61761)
+++ trunk/e/src/bin/e_main.c 2011-07-26 14:04:14 UTC (rev 61762)
@@ -392,7 +392,9 @@
TS(E_Randr Init);
if (!e_randr_init())
- e_error_message_show(_(Enlightenment cannot initialize E_Randr!\n));
+ {
+ e_error_message_show(_(Enlightenment cannot initialize E_Randr!\n));
+ }
else
_e_main_shutdown_push(e_randr_shutdown);
TS(E_Randr Init Done);
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/e/src/bin
Heh yea :( pretty odd, but I haven't stopped to look into why yet :) I
just fixed it and moved on ;) Will look into 'why' later :)
dh
On 07/26/11 10:13, Daniel Juyung Seo wrote:
need braces to compile this?
what's the difference?
Daniel Juyung Seo (SeoZ)
On Jul 26, 2011 11:04 PM, Enlightenment SVNno-re...@enlightenment.org
wrote:
Log:
E: Grrr, fix previous commit to actually compile.
Author: devilhorns
Date: 2011-07-26 07:04:14 -0700 (Tue, 26 Jul 2011)
New Revision: 61762
Trac: http://trac.enlightenment.org/e/changeset/61762
Modified:
trunk/e/src/bin/e_main.c
Modified: trunk/e/src/bin/e_main.c
===
--- trunk/e/src/bin/e_main.c 2011-07-26 14:00:54 UTC (rev 61761)
+++ trunk/e/src/bin/e_main.c 2011-07-26 14:04:14 UTC (rev 61762)
@@ -392,7 +392,9 @@
TS(E_Randr Init);
if (!e_randr_init())
- e_error_message_show(_(Enlightenment cannot initialize E_Randr!\n));
+ {
+ e_error_message_show(_(Enlightenment cannot initialize E_Randr!\n));
+ }
else
_e_main_shutdown_push(e_randr_shutdown);
TS(E_Randr Init Done);
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] Animation gif feature patch
But we need to determine them everyone is familiar with here. but not ones you are familiar with. If you start with bad things in evas, next ones will be got stuck in the bad like *homogenous* And still wonder why names are different in evas and elementary? as you said animated is more familiar, then why does it not named to elm_icon_animated? Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Jiyoun Parklt;jy0703.p...@samsung.comgt; To: 'Daniel Juyung Seo'lt;seojuyu...@gmail.comgt;; 'ChunEon Park'lt;her...@naver.comgt; Cc: enlightenment-devel@lists.sourceforge.net Sent: 11-07-26(화) 16:25:45 Subject: RE: [E-devel] [Patch] Animation gif feature patch1. why do you think *_animated_* is not proper name? long character or grammar problem (word class? Other reason?) ? *_animated_* is familiar to me, and there is no place related with this in evas , so I want to keep this name. But If this name is wrong or not acceptable name generally , I will consider to change API name. 2. yes . I already have elm_icon_anim_available_get API 3. elm_icon_anim_set means I will use animation mode currently or later. Elm_icon_anim_play_set is for real play of image. Thanks. -Original Message- From: Daniel Juyung Seo [mailto:seojuyu...@gmail.com] Sent: Monday, July 25, 2011 11:43 PM To: ChunEon Park Cc: Jiyoun Park; enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] [Patch] Animation gif feature patch 1) Frankely, I don't like *_animated_* Agreed. Choose either animation or anim and apply it to evas_object_image and elm_icon. I prefer anim :) 2) Eina_Bool elm_icon_anim_get (const Evas_Object *obj) - elm_icon_anim_available_get ... elm_icon_anim_available_get is already in Jiyoun's patch. 3) API names are not clear. For me 2 names are confusing. elm_icon_anim_set() elm_icon_anim_play_set() What's anim mode and anim play mode? Maybe I'm missing some animation image concept. Thanks. Daniel Juyung Seo (SeoZ) On Mon, Jul 25, 2011 at 8:20 PM, ChunEon Park lt;her...@naver.comgt; wrote: Frankely, I don't like *_animated_* How about just animation or anim? evas_object_image_animation_available_get evas_object_image_animation_frame_get ... and this API also. Eina_Bool elm_icon_anim_get (const Evas_Object *obj) - elm_icon_anim_available_get ... Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Jiyoun Parklt;jy0703.p...@samsung.comgt; To: enlightenment-devel@lists.sourceforge.net Cc: Sent: 11-07-25(월) 17:18:22 Subject: [E-devel] [Patch] Animation gif feature patchHello. I modified animated gif feature code according Mike’s advise. Added api Eina_Bool evas_object_image_animated_get (const Evas_Object *obj) int evas_object_image_animated_frame_num_get (const Evas_Object *obj) Evas_Image_Animated_Loop_Hint evas_object_image_animated_loop_type_get (const Evas_Object *obj) int evas_object_image_animated_loop_count_get (const Evas_Object *obj) double evas_object_image_animated_frame_duration_get (const Evas_Object *obj, int start_frame, int fram_num) void evas_object_image_animated_frame_set (Evas_Object *obj, int frame_num) Eina_Bool elm_icon_anim_available_get (const Evas_Object *obj) Void elm_icon_anim_set (Evas_Object *obj, Eina_Bool anim) Eina_Bool elm_icon_anim_get (const Evas_Object *obj) void elm_icon_anim_play_set (Evas_Object *obj, Eina_Bool play) Eina_Bool elm_icon_anim_play_get (const Evas_Object *obj) Todo 1. optimization 2. Test case to test several files Test_icon.c is for elm icon test. Change test_icon.c in elementary/src/bin to this. Thanks. -- Jiyoun Park Mobile S/W Platform Lab DMC RD Center SAMSUNG ELECTRONICS CO. ,LTD TEL: +82-31-279-0619 Mobile: +82-10-9871-0703 jy0703.p...@samsung.com -- -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/
Re: [E-devel] E SVN: seoz trunk/edje/src/lib
2011/7/26 Enlightenment SVN no-re...@enlightenment.org: Log: edje Edje.h: Fixed documentation. Fixed wrong placed documentations. Removed some blank lines and added @brief tag. Many @brief tags are still missing. @brief is not really necessary. Author: seoz Date: 2011-07-26 03:09:16 -0700 (Tue, 26 Jul 2011) New Revision: 61737 Trac: http://trac.enlightenment.org/e/changeset/61737 Modified: trunk/edje/src/lib/Edje.h Modified: trunk/edje/src/lib/Edje.h === --- trunk/edje/src/lib/Edje.h 2011-07-26 10:03:07 UTC (rev 61736) +++ trunk/edje/src/lib/Edje.h 2011-07-26 10:09:16 UTC (rev 61737) @@ -1462,7 +1462,20 @@ * half-transparent white is 255 255 255 128. */ EAPI Eina_Bool edje_color_class_get (const char *color_class, int *r, int *g, int *b, int *a, int *r2, int *g2, int *b2, int *a2, int *r3, int *g3, int *b3, int *a3); - EAPI void edje_color_class_del (const char *color_class); + +/** + * @brief Delete the object color class. + * + * @param obj The edje object's reference. + * @param color_class The color class to be deleted. + * + * This function deletes any values at the object level for the + * specified object and color class. + * + * Deleting color emits a signal color_class,del with source being + * the given color. + */ +EAPI void edje_color_class_del (const char *color_class); EAPI Eina_List *edje_color_class_list (void); /** @@ -1478,24 +1491,32 @@ * @see edje_text_class_get(). * */ +EAPI Eina_Bool edje_text_class_set (const char *text_class, const char *font, Evas_Font_Size size); /** - * @brief Delete the object color class. + * @brief Delete the text class. * - * @param obj The edje object's reference. - * @param color_class The color class to be deleted. + * @param text_class The text class name string * - * This function deletes any values at the object level for the - * specified object and color class. + * This function deletes any values at the process level for the + * specified text class. * - * Deleting color emits a signal color_class,del with source being - * the given color. */ -EAPI Eina_Bool edje_text_class_set (const char *text_class, const char *font, Evas_Font_Size size); - EAPI void edje_text_class_del (const char *text_class); - EAPI Eina_List *edje_text_class_list (void); +EAPI void edje_text_class_del (const char *text_class); /** + * @brief List text classes. + * + * @return A list of text class names (strings). These strings are + * stringshares and the list must be free()'d by the caller. + * + * This function lists all text classes known about by the current + * process. + * + */ +EAPI Eina_List *edje_text_class_list (void); + +/** * @brief Set the object minimum size. * * @param obj A valid Evas_Object handle @@ -1557,7 +1578,7 @@ EAPI void edje_box_layout_register (const char *name, Evas_Object_Box_Layout func, void *(*layout_data_get)(void *), void (*layout_data_free)(void *), void (*free_data)(void *), void *data); /** - * Constructs the Edje object + * @brief Constructs the Edje object * @param evas A valid Evas handle * @return The Evas_Object pointer. * @@ -1592,7 +1613,7 @@ EAPI const char *edje_object_data_get (const Evas_Object *obj, const char *key); /** - * Sets the EET file and group to load @a obj from + * @brief Sets the EET file and group to load @a obj from * @param obj A valid Evas_Object handle * @param file The path to the EET file * @param group The group name in the Edje @@ -1606,7 +1627,7 @@ EAPI Eina_Bool edje_object_file_set (Evas_Object *obj, const char *file, const char *group); /** - * Get the file and group name that @a obj was loaded from + * @brief Get the file and group name that @a obj was loaded from * @param obj A valid Evas_Object handle * @param file A pointer to store a pointer to the filename in * @param group A pointer to store a pointer to the group name in @@ -1622,7 +1643,7 @@ EAPI void edje_object_file_get (const Evas_Object *obj, const char **file, const char **group); /** - * Gets the Edje load error + * @brief Gets the Edje load error * @param obj A valid Evas_Object handle * * @return The Edje load error:\n @@ -1639,8 +1660,8 @@ */ EAPI Edje_Load_Error edje_object_load_error_get (const Evas_Object *obj); -EAPI const char *edje_load_error_str (Edje_Load_Error error); -EAPI Eina_Bool edje_object_preload (Evas_Object *obj, Eina_Bool cancel); + EAPI const char *edje_load_error_str (Edje_Load_Error error); + EAPI Eina_Bool edje_object_preload (Evas_Object
Re: [E-devel] [Patch] Add XIM module for ecore_imf
Ya, thanks raster :) 2011/7/26 Carsten Haitzler ras...@rasterman.com: On Sat, 23 Jul 2011 22:22:10 +0900 Jihoon Kim imfin...@gmail.com said: i fixed this one in svn already :) Hi, Naruto. I've tested in elementary_test entry menu after applying my edje patch related to client_window_set. However, I couldn't see the preedit string in the entry widget while I was typing. In addition, sometimes segmentation fault was occured. Here is backtrace of GDB. (gdb) bt #0 0x0030fb62 in eina_unicode_strlen (ustr=0x0) at eina_unicode.c:70 #1 0x003105dc in eina_unicode_unicode_to_utf8 (uni=0x0, _len=0xb184) at eina_unicode.c:331 #2 0x00efd7b3 in _ecore_imf_context_xim_preedit_string_get (ctx=0x8251b28, str=0xb1d8, cursor_pos=0xb1dc) at ecore_imf_xim.c:179 #3 0x004736d6 in ecore_imf_context_preedit_string_get (ctx=0x8251b28, str=0xb1d8, cursor_pos=0xb1dc) at ecore_imf_context.c:388 #4 0x004d4c44 in _edje_entry_imf_event_preedit_changed_cb (data=0x8333628, type=79, event=0x838f0b8) at edje_entry.c:2887 #5 0x00428ac6 in _ecore_event_call () at ecore_events.c:693 #6 0x0042f4d2 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:1750 #7 0x0042dc49 in ecore_main_loop_begin () at ecore_main.c:848 #8 0x001d08cc in elm_run () at elm_main.c:1075 #9 0x0805551b in elm_main (argc=1, argv=0xb3a4) at test.c:489 #10 0x0804 in main (argc=1, argv=0xb3a4) at test.c:498 2011/7/23 Naruto TAKAHASHI tnar...@gmail.com Hi JihoonKim, and EFL developers. I attach a patch for fixing some XIM module bugs. - fix showing previous preedit string bug. - delete compile warning(thanks JihoonKim) - fix some sequence issue to send preedit changed event and commit event.(thanks JihoonKim) Please review this patch? Regards. 2011年7月22日23:52 Naruto TAKAHASHI tnar...@gmail.com: Hi, JihoonKim. I talked to you how fix preedit draw callback direction on IRC. I repeat to talk this stuff for didn't see this talk. Your patch behavior is no problem. But Preedit Draw Callback needs insert, delete, and replace by referencing Preedit Draw Callback argument. (detail: http://static.cray-cyber.org/Documentation/NEC_SX_R10_1/G1AE02E/CHAP13.HTML#13.18.6 . Preedit Draw Callback) I'm trying to fix too easy routine by using Eina_UStrBuf, now. So, please wait this. Off course, I merge deleting comple warning of your patch with thanks. :) Thanks. 2011/7/17 Jihoon Kim imfin...@gmail.com: Hi, Naruto. As I told you last Friday on IRC, I guess there are some bugs in your xim immodule. For example, in case that I'd like to input '私の' (watasino), the preedit string was got from your immodule like below '私のしの'. In addition, there are some sequence issue to send preedit changed event and commit event. I've tried to fix this problem and send you the patch. (I've tested on elementary_test entry) If you don't mind uploading this patch to svn, I'll request Maintainers to upload this patch. Thanks. On Sun, Jul 10, 2011 at 2:51 AM, Naruto TAKAHASHI tnar...@gmail.com wrote: Hi Mike. Thanks, feedback. I merged it to xim/Makefile.am. I attach a source code for using XIM module debug. This program can check a below behaviors. - toggle enable and disable XIM - commit string from XIM Another test, by using Desktop Entry Editor's text field. (Enlightenment Main-Settings-Settings Panel-New Application) When executing test program, set ECORE_IMF_MODULE=xim. Thanks. 2011/7/8 Mike McCormack mj.mccorm...@samsung.com: On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote: Hi, All. I attached some patches of XIM module of ecore_imf. As far as I know, EFL has not having official ecore_imf module in E repository. And ecore_x has XIM code but is unavailable condition. So I moved XIM code of ecore_x as ecore_imf module. please review this patches. Hello Naruto, Looks like nice work. I applied your patches to my ecore and built, but there was a build error (fix below): make[5]: Entering directory `/home/mike/git/e/ecore/src/modules/immodules/xim' CC xim_la-ecore_imf_xim.lo ecore_imf_xim.c:5:18: error: Evas.h: No such file or directory ecore_imf_xim.c: In function ‘_ecore_x_event_reverse_locks’: ecore_imf_xim.c:359: warning: suggest braces around empty body in an ‘if’ statement ecore_imf_xim.c: In function ‘preedit_start_callback’: ecore_imf_xim.c:662: warning: unused parameter ‘xic’ ecore_imf_xim.c:664: warning: unused parameter ‘call_data’ How can I test it? thanks, Mike diff --git a/ecore/src/modules/immodules/xim/Makefile.am b/ecore/src/modules/immodules/xim/Makefile.am index 006035c..cc0682d 100644 ---
Re: [E-devel] [Patch] Add XIM module for ecore_imf
2011年7月26日13:52 Naruto TAKAHASHI tnar...@gmail.com: Ya, thanks raster :) Now we are missing the E17 IM settings to set ECORE_IMF_MODULE properly. With my locale it's not loading the xim one by default when I run Elementary. 2011/7/26 Carsten Haitzler ras...@rasterman.com: On Sat, 23 Jul 2011 22:22:10 +0900 Jihoon Kim imfin...@gmail.com said: i fixed this one in svn already :) Hi, Naruto. I've tested in elementary_test entry menu after applying my edje patch related to client_window_set. However, I couldn't see the preedit string in the entry widget while I was typing. In addition, sometimes segmentation fault was occured. Here is backtrace of GDB. (gdb) bt #0 0x0030fb62 in eina_unicode_strlen (ustr=0x0) at eina_unicode.c:70 #1 0x003105dc in eina_unicode_unicode_to_utf8 (uni=0x0, _len=0xb184) at eina_unicode.c:331 #2 0x00efd7b3 in _ecore_imf_context_xim_preedit_string_get (ctx=0x8251b28, str=0xb1d8, cursor_pos=0xb1dc) at ecore_imf_xim.c:179 #3 0x004736d6 in ecore_imf_context_preedit_string_get (ctx=0x8251b28, str=0xb1d8, cursor_pos=0xb1dc) at ecore_imf_context.c:388 #4 0x004d4c44 in _edje_entry_imf_event_preedit_changed_cb (data=0x8333628, type=79, event=0x838f0b8) at edje_entry.c:2887 #5 0x00428ac6 in _ecore_event_call () at ecore_events.c:693 #6 0x0042f4d2 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:1750 #7 0x0042dc49 in ecore_main_loop_begin () at ecore_main.c:848 #8 0x001d08cc in elm_run () at elm_main.c:1075 #9 0x0805551b in elm_main (argc=1, argv=0xb3a4) at test.c:489 #10 0x0804 in main (argc=1, argv=0xb3a4) at test.c:498 2011/7/23 Naruto TAKAHASHI tnar...@gmail.com Hi JihoonKim, and EFL developers. I attach a patch for fixing some XIM module bugs. - fix showing previous preedit string bug. - delete compile warning(thanks JihoonKim) - fix some sequence issue to send preedit changed event and commit event.(thanks JihoonKim) Please review this patch? Regards. 2011年7月22日23:52 Naruto TAKAHASHI tnar...@gmail.com: Hi, JihoonKim. I talked to you how fix preedit draw callback direction on IRC. I repeat to talk this stuff for didn't see this talk. Your patch behavior is no problem. But Preedit Draw Callback needs insert, delete, and replace by referencing Preedit Draw Callback argument. (detail: http://static.cray-cyber.org/Documentation/NEC_SX_R10_1/G1AE02E/CHAP13.HTML#13.18.6 . Preedit Draw Callback) I'm trying to fix too easy routine by using Eina_UStrBuf, now. So, please wait this. Off course, I merge deleting comple warning of your patch with thanks. :) Thanks. 2011/7/17 Jihoon Kim imfin...@gmail.com: Hi, Naruto. As I told you last Friday on IRC, I guess there are some bugs in your xim immodule. For example, in case that I'd like to input '私の' (watasino), the preedit string was got from your immodule like below '私のしの'. In addition, there are some sequence issue to send preedit changed event and commit event. I've tried to fix this problem and send you the patch. (I've tested on elementary_test entry) If you don't mind uploading this patch to svn, I'll request Maintainers to upload this patch. Thanks. On Sun, Jul 10, 2011 at 2:51 AM, Naruto TAKAHASHI tnar...@gmail.com wrote: Hi Mike. Thanks, feedback. I merged it to xim/Makefile.am. I attach a source code for using XIM module debug. This program can check a below behaviors. - toggle enable and disable XIM - commit string from XIM Another test, by using Desktop Entry Editor's text field. (Enlightenment Main-Settings-Settings Panel-New Application) When executing test program, set ECORE_IMF_MODULE=xim. Thanks. 2011/7/8 Mike McCormack mj.mccorm...@samsung.com: On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote: Hi, All. I attached some patches of XIM module of ecore_imf. As far as I know, EFL has not having official ecore_imf module in E repository. And ecore_x has XIM code but is unavailable condition. So I moved XIM code of ecore_x as ecore_imf module. please review this patches. Hello Naruto, Looks like nice work. I applied your patches to my ecore and built, but there was a build error (fix below): make[5]: Entering directory `/home/mike/git/e/ecore/src/modules/immodules/xim' CC xim_la-ecore_imf_xim.lo ecore_imf_xim.c:5:18: error: Evas.h: No such file or directory ecore_imf_xim.c: In function ‘_ecore_x_event_reverse_locks’: ecore_imf_xim.c:359: warning: suggest braces around empty body in an ‘if’ statement ecore_imf_xim.c: In function ‘preedit_start_callback’: ecore_imf_xim.c:662: warning: unused parameter ‘xic’ ecore_imf_xim.c:664: warning: unused parameter ‘call_data’ How can I test it? thanks,
Re: [E-devel] E SVN: discomfitor IN trunk/elementary/src: bin lib
On Tue, 26 Jul 2011 21:18:34 +0900 Daniel Juyung Seo seojuyu...@gmail.com wrote: Stu!!! It's hard to figure out what you've broken with this big commit! Btw, I think elm_toolip/gengrid/genlist/list_size_restrict_disable should be changed. EAPI Eina_Bool elm_tooltip_size_restrict_disable(Evas_Object *obj, Eina_Bool disable) -- EAPI void elm_tooltip_size_restrict_disabled_set(Evas_Object *obj, Eina_Bool disabled) See other elm_xxx_disabled_set APIs. Thanks. Daniel Juyung Seo (SeoZ) On Tue, Jul 26, 2011 at 6:42 PM, Mike Blumenkrantz m...@zentific.com wrote: On Tue, 26 Jul 2011 02:38:23 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: THE MOST ANTICIPATED COMMIT OF 2011: HUGENORMOUS TOOLTIPS!! these bad boys are so big and pixelthirsty they can't be constrained by a regular canvas or window, they use OVERRIDE REDIRECT WINDOWS. not only that, they totally exceed the boundaries of what a reasonable function name length could be. 50 character function name limit? puh-leeze. these guys don't care what side of the screen they're even on so long as they get to wade into the thick of the action and block out each and every crappy non-efl application behind them. and that's when they're in good moods. you don't even want to know what happens when you piss these guys off. Author: discomfitor Date: 2011-07-26 02:38:23 -0700 (Tue, 26 Jul 2011) New Revision: 61735 Trac: http://trac.enlightenment.org/e/changeset/61735 Modified: trunk/elementary/src/bin/test_tooltip.c trunk/elementary/src/lib/Elementary.h.in trunk/elementary/src/lib/elm_gengrid.c trunk/elementary/src/lib/elm_genlist.c trunk/elementary/src/lib/elm_list.c trunk/elementary/src/lib/elm_widget.c trunk/elementary/src/lib/elm_widget.h trunk/elementary/src/lib/els_tooltip.c when you piss them off they totally break tooltip api like they just did -- Mike Blumenkrantz Zentific: Coding in binary since '10. The Elm_Tooltip_Content_Cb callback has another param now, and this is the param to which the content must be added. I don't disagree that the api names should be changed, but I don't know what to rename them to. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] European Tour -- BEERS?
Hi European dudes, how are you doing? As some IRC folks know, I'll be in Europe for a series of events and would like to meet you for a beer night (I have meetings during the day). Let me know what can be arranged on the following dates (all in August): Paris: - Arrival: 3, afternoon - Departure: 5, afternoon Berlin: there to represent Enlightenment in the Desktop Summit 2011, yay! - Arrival: 5, night - Departure: 9, night Munich: - Arrival: 9, night - Departure: 11, afternoon Venice: (unconfirmed) - Arrival: 11, afternoon - Departure: 13, morning Anyway, it's a busy schedule but I'm pretty sure we can enjoy. Don't forget I'm a foreigner and although I know these cities (except Berlin), I'd love to see the touristic places and all :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] header size...
On Sun, 17 Jul 2011 21:39:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sat, 16 Jul 2011 09:23:45 -0400 Mike Blumenkrantz m...@zentific.com said: With the recent infusion (profusion?) of documentation, our header sizes have become, imo, WAAY too big. They are entirely impossible to navigate, and this is a problem that will only get worse. As an example, the elm .h file is over 10k lines already, and I have to scroll quite a bit to find something when I am looking for it (since all the doxygen tags break scintilla as it is...). Something must be done! Bring back the readable headers!!! you could just strip all comments from the headers and use them but i thought you use geany and ctags files.. so why would you need to read them? this was hashed over. we are required to put some of the doxy docs in the headers anyway - enums structs, macros for example. so this means our docs are split between private and public files. if we put them all in public headers we c an generate docs from installed headers. also people have expressed a desire for the docs there so they can read the docs in the .h file. if u want a quick ref, this can be generated just removing all comments (a bit of sed work methinks could do the job). in all seriousness, this is a problem. elm's header is approaching 20k lines and that's really not acceptable for a header. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] header size...
2011/7/26 Mike Blumenkrantz m...@zentific.com: On Sun, 17 Jul 2011 21:39:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sat, 16 Jul 2011 09:23:45 -0400 Mike Blumenkrantz m...@zentific.com said: With the recent infusion (profusion?) of documentation, our header sizes have become, imo, WAAY too big. They are entirely impossible to navigate, and this is a problem that will only get worse. As an example, the elm .h file is over 10k lines already, and I have to scroll quite a bit to find something when I am looking for it (since all the doxygen tags break scintilla as it is...). Something must be done! Bring back the readable headers!!! you could just strip all comments from the headers and use them but i thought you use geany and ctags files.. so why would you need to read them? this was hashed over. we are required to put some of the doxy docs in the headers anyway - enums structs, macros for example. so this means our docs are split between private and public files. if we put them all in public headers we c an generate docs from installed headers. also people have expressed a desire for the docs there so they can read the docs in the .h file. if u want a quick ref, this can be generated just removing all comments (a bit of sed work methinks could do the job). in all seriousness, this is a problem. elm's header is approaching 20k lines and that's really not acceptable for a header. wc -l /usr/include/* ... 83002 /usr/include/ppl.hh ... Granted, it's a C++ header, but maybe we can get to 40k -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] header size...
On 07/26/11 17:42, Mike Blumenkrantz wrote: On Sun, 17 Jul 2011 21:39:50 +0900 Carsten Haitzler (The Rasterman)ras...@rasterman.com wrote: On Sat, 16 Jul 2011 09:23:45 -0400 Mike Blumenkrantzm...@zentific.com said: With the recent infusion (profusion?) of documentation, our header sizes have become, imo, WAAY too big. They are entirely impossible to navigate, and this is a problem that will only get worse. As an example, the elm .h file is over 10k lines already, and I have to scroll quite a bit to find something when I am looking for it (since all the doxygen tags break scintilla as it is...). Something must be done! Bring back the readable headers!!! you could just strip all comments from the headers and use them but i thought you use geany and ctags files.. so why would you need to read them? this was hashed over. we are required to put some of the doxy docs in the headers anyway - enums structs, macros for example. so this means our docs are split between private and public files. if we put them all in public headers we c an generate docs from installed headers. also people have expressed a desire for the docs there so they can read the docs in the .h file. if u want a quick ref, this can be generated just removing all comments (a bit of sed work methinks could do the job). in all seriousness, this is a problem. elm's header is approaching 20k lines and that's really not acceptable for a header. +1 I went trying to find a function in that header this morning ... ugg, thought I was going to get lost without a roadmap. There has to be a better way dh -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] header size...
I still prefer to divide the header file separated by widgets. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Christopher Michaellt;cpmicha...@comcast.netgt; To: enlightenment-devel@lists.sourceforge.net Cc: Sent: 11-07-27(수) 06:57:43 Subject: Re: [E-devel] header size...On 07/26/11 17:42, Mike Blumenkrantz wrote: On Sun, 17 Jul 2011 21:39:50 +0900 Carsten Haitzler (The Rasterman)lt;ras...@rasterman.comgt; wrote: On Sat, 16 Jul 2011 09:23:45 -0400 Mike Blumenkrantzlt;m...@zentific.comgt; said: With the recent infusion (profusion?) of documentation, our header sizes have become, imo, WAAY too big. They are entirely impossible to navigate, and this is a problem that will only get worse. As an example, the elm .h file is over 10k lines already, and I have to scroll quite a bit to find something when I am looking for it (since all the doxygen tags break scintilla as it is...). Something must be done! Bring back the readable headers!!! you could just strip all comments from the headers and use them but i thought you use geany and ctags files.. so why would you need to read them? this was hashed over. we are required to put some of the doxy docs in the headers anyway - enums structs, macros for example. so this means our docs are split between private and public files. if we put them all in public headers we c an generate docs from installed headers. also people have expressed a desire for the docs there so they can read the docs in the .h file. if u want a quick ref, this can be generated just removing all comments (a bit of sed work methinks could do the job). in all seriousness, this is a problem. elm's header is approaching 20k lines and that's really not acceptable for a header. +1 I went trying to find a function in that header this morning ... ugg, thought I was going to get lost without a roadmap. There has to be a better way dh -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib
To support elm_object_item_blah_blah_blah... APIs, I think we need to provide an interface such as Elm_Object_Item. If you all agree with it, I will dig them in a hurry. Thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: ChunEon Parklt;her...@naver.comgt; To: Gustavo Sverzut Barblt;barbi...@profusion.mobigt; Cc: Tom Hacohenlt;tom.haco...@partner.samsung.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-18(월) 14:16:44 Subject: RE: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib Ok, I will do. thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Gustavo Sverzut Barbierilt;barbi...@profusion.mobigt; To: Tom Hacohenlt;tom.haco...@partner.samsung.comgt; Cc: ChunEon Parklt;her...@naver.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-15(금) 02:38:42 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Thu, Jul 14, 2011 at 12:58 PM, Tom Hacohen lt;tom.haco...@partner.samsung.comgt; wrote: On 14/07/11 18:52, Gustavo Sverzut Barbieri wrote: 2011/7/13 ChunEon Parklt;her...@naver.comgt;: elm_naviframe_item_text_part_set/get() or something like that. - Yes. it looks not bad for me. But it will cause more mistakes of users since they should pass the part name, (I don't like it from that point of view although.) And some widgets have the item_label_set now. Need to keep the consistency if everyone agree with. Yes, Daniel is right and the current item_label_set() are more like unconverted legacy. They must be fixed and new APIs must be correct from start. Unfortunately, because those are not elm_widgets, calling elm_object_text_set won't work. We really need to find a solution to this one. Possibly another API that allows passing additional data? elm_object_text_subitem_set or something like that? check what we did for tooltips and others, they have some kind of interface in the items, if you follow you have generic functions to operate on them. but all in all I'd go for actual interfaces (in classes, not instances -- partial infra for Evas_Object is there, but lacks for generic items) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib
Looks good to me. Go go go ! Do it! Daniel Juyung Seo (SeoZ) 2011/7/27 ChunEon Park her...@naver.com: To support elm_object_item_blah_blah_blah... APIs, I think we need to provide an interface such as Elm_Object_Item. If you all agree with it, I will dig them in a hurry. Thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: ChunEon Parklt;her...@naver.comgt; To: Gustavo Sverzut Barblt;barbi...@profusion.mobigt; Cc: Tom Hacohenlt;tom.haco...@partner.samsung.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-18(월) 14:16:44 Subject: RE: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib Ok, I will do. thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Gustavo Sverzut Barbierilt;barbi...@profusion.mobigt; To: Tom Hacohenlt;tom.haco...@partner.samsung.comgt; Cc: ChunEon Parklt;her...@naver.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-15(금) 02:38:42 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Thu, Jul 14, 2011 at 12:58 PM, Tom Hacohen lt;tom.haco...@partner.samsung.comgt; wrote: On 14/07/11 18:52, Gustavo Sverzut Barbieri wrote: 2011/7/13 ChunEon Parklt;her...@naver.comgt;: elm_naviframe_item_text_part_set/get() or something like that. - Yes. it looks not bad for me. But it will cause more mistakes of users since they should pass the part name, (I don't like it from that point of view although.) And some widgets have the item_label_set now. Need to keep the consistency if everyone agree with. Yes, Daniel is right and the current item_label_set() are more like unconverted legacy. They must be fixed and new APIs must be correct from start. Unfortunately, because those are not elm_widgets, calling elm_object_text_set won't work. We really need to find a solution to this one. Possibly another API that allows passing additional data? elm_object_text_subitem_set or something like that? check what we did for tooltips and others, they have some kind of interface in the items, if you follow you have generic functions to operate on them. but all in all I'd go for actual interfaces (in classes, not instances -- partial infra for Evas_Object is there, but lacks for generic items) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib
anyone else? Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Daniel Juyung Seolt;seojuyu...@gmail.comgt; To: ChunEon Parklt;her...@naver.comgt; Cc: enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-27(수) 11:23:20 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libLooks good to me. Go go go ! Do it! Daniel Juyung Seo (SeoZ) 2011/7/27 ChunEon Park lt;her...@naver.comgt;: To support elm_object_item_blah_blah_blah... APIs, I think we need to provide an interface such as Elm_Object_Item. If you all agree with it, I will dig them in a hurry. Thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: ChunEon Parklt;her...@naver.comgt; To: Gustavo Sverzut Barblt;barbi...@profusion.mobigt; Cc: Tom Hacohenlt;tom.haco...@partner.samsung.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-18(월) 14:16:44 Subject: RE: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib Ok, I will do. thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Gustavo Sverzut Barbierilt;barbi...@profusion.mobigt; To: Tom Hacohenlt;tom.haco...@partner.samsung.comgt; Cc: ChunEon Parklt;her...@naver.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-15(금) 02:38:42 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Thu, Jul 14, 2011 at 12:58 PM, Tom Hacohen lt;tom.haco...@partner.samsung.comgt; wrote: On 14/07/11 18:52, Gustavo Sverzut Barbieri wrote: 2011/7/13 ChunEon Parklt;her...@naver.comgt;: elm_naviframe_item_text_part_set/get() or something like that. - Yes. it looks not bad for me. But it will cause more mistakes of users since they should pass the part name, (I don't like it from that point of view although.) And some widgets have the item_label_set now. Need to keep the consistency if everyone agree with. Yes, Daniel is right and the current item_label_set() are more like unconverted legacy. They must be fixed and new APIs must be correct from start. Unfortunately, because those are not elm_widgets, calling elm_object_text_set won't work. We really need to find a solution to this one. Possibly another API that allows passing additional data? elm_object_text_subitem_set or something like that? check what we did for tooltips and others, they have some kind of interface in the items, if you follow you have generic functions to operate on them. but all in all I'd go for actual interfaces (in classes, not instances -- partial infra for Evas_Object is there, but lacks for generic items) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/e/src/bin
On 07/26/2011 11:23 PM, Christopher Michael wrote: Heh yea :( pretty odd, but I haven't stopped to look into why yet :) I just fixed it and moved on ;) Will look into 'why' later :) Hopefully SVN @61783 will fix it. thanks, Mike -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] header size...
On Tue, 26 Jul 2011 17:42:26 -0400 Mike Blumenkrantz m...@zentific.com said: docs in headers stay there and get expanded. On Sun, 17 Jul 2011 21:39:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sat, 16 Jul 2011 09:23:45 -0400 Mike Blumenkrantz m...@zentific.com said: With the recent infusion (profusion?) of documentation, our header sizes have become, imo, WAAY too big. They are entirely impossible to navigate, and this is a problem that will only get worse. As an example, the elm .h file is over 10k lines already, and I have to scroll quite a bit to find something when I am looking for it (since all the doxygen tags break scintilla as it is...). Something must be done! Bring back the readable headers!!! you could just strip all comments from the headers and use them but i thought you use geany and ctags files.. so why would you need to read them? this was hashed over. we are required to put some of the doxy docs in the headers anyway - enums structs, macros for example. so this means our docs are split between private and public files. if we put them all in public headers we c an generate docs from installed headers. also people have expressed a desire for the docs there so they can read the docs in the .h file. if u want a quick ref, this can be generated just removing all comments (a bit of sed work methinks could do the job). in all seriousness, this is a problem. elm's header is approaching 20k lines and that's really not acceptable for a header. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ 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 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][Evil] evil_string has strcasestr
On Fri, 8 Jul 2011 21:27:21 +0900 cnook kimci...@gmail.com said: sure - and as i said... if and when you have a widget ready that needs it... then re-submit the patch for evil - you'll be showing how it's used and needed. (or not) :) Thanks for your response! I'm not sure other codes(languages? difference set?) need the strcasestr();. Even though the strcasestr(); is meaningless, it would work as strstr(); Anyhow, I will check strcasestr(); is really necessary or not. Have a good time! 2011/7/5 Carsten Haitzler ras...@rasterman.com On Fri, 1 Jul 2011 10:15:21 +0900 cnook kimci...@gmail.com said: now... that looks technically ok... but why are you using strcasestr. manual page is pretty specific: The strcasestr() function is a nonstandard extension. so it's non-standard and.. well mingw and other os's might definitely not have it. we tend to stick to standard functions as much as we can. if you want to put this patch in as PART of submitting a new widget - i'm happy to look at it then in the context of the new widget and why it needs it. you do know that you may have to make this unicode friendly depending on usage? it the code you have there does just ascii (or the ascii portion of utf8 - skipping toupper/lower of anything beyond ascii) Hi :-] Your review comments in the attached patch. Thanks for your response always. Sincerely, Shinwoo Kim. 2011/6/29 Vincent Torri vto...@univ-evry.fr On Wed, 29 Jun 2011, cnook wrote: Oh I see, I got the point. Thanks for your response. Wherever the strcasestr() is used using previous patch, would be changed as bellow. #ifdef HAVE_STRCASESTR strcase(h, n); #else _elm_util_strcasestr(h, n); #endif better: #ifdef HAVE_STRCASESTR # define _elm_util_strcasestr(h, n) strcase((h), (n)) #endif and always use _elm_util_strcasestr() instead of strcasestr() Vincent Anyhow, I have refined the previous patch and attached. Then, wherever the strcasestr() is used, should be changed just as bellow _elm_util_strcasestr(h, n); Sincerely, Shinwoo Kim. 2011/6/29 Vincent Torri vto...@univ-evry.fr what he means is: * using AC_CHECK_FUNCS([strcasestr]) in configure.ac defined HAVE_STRCASESTR in config.h * in the code, you use the macro HAVE_STRCASESTR to use the glibc version of strcase, or to use your own version Vincent On Wed, 29 Jun 2011, cnook wrote: Hi Thanks for your response. I have no enough idea when it comes to E16. Actually this patch comes because of the Evil Windows environments - strcasestr does not exist. If strcasestr alternative - Estrcasestr - is on the E16, Should I install the E16 also or not? Sincerely, Shinwoo Kim. 2011/6/29 Hyoyoung Chang hyoyoung.ch...@samsung.com I think it's a nice patch if glibc's strcasestr can be used How about to add statements like below? #ifdef HAVE_STRCASESTR #define Estrcasestr(haystack, needle) strcasestr(haystack, needle) #else const char *Estrcasestr(const char *haystack, const char *needle); #endif In E16/e/src/util.h From: cnook [mailto:kimci...@gmail.com] Sent: Tuesday, June 28, 2011 3:58 PM To: Hyoyoung Chang Cc: Daniel Juyung Seo; enlightenment-devel@lists.**so**urceforge.net http://sourceforge.net enlightenment-**de...@lists.sourceforge.net enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] [Patch][Evil] evil_string has strcasestr Dear All, Hi~ Here is the patch added on the elementary. :-] Sincerely, Shinwoo Kim. 2011/6/22 Hyoyoung Chang hyoyoung.ch...@samsung.com As I know strcasestr is not standard function. It's a glibc extension. CONFORMING TO The strstr() function conforms to C89 and C99. The strcasestr() funcÿÿ tion is a nonstandard extension. -- man page of strcasestr Is it only used in elementary? If then how about add to check routine in configure and add in elm_util.c? Or is it widely used in e project, it can be added in other module. PS. I google about strcasestr. It's contained in LSB 3.1 http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-** generic/LSB-Core-generihttp:/**/refspecs.freestandards.org/** LSB_3.1.1/LSB-Core-generic/**LSB-Core-generi http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generi c/baselib-strcasestr.html -Original Message- From: cnook [mailto:kimci...@gmail.com] Sent: Wednesday, June 22, 2011 5:56 PM To: Daniel Juyung Seo Cc:
