Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib

[The Rasterman]

On Wed, 27 Jul 2011 09:02:56 +0900 ChunEon Park said:

there already are generic item apis' for several things - you just need to
make sure naviframe uses the generic ones where they exist, and if you need to
- extend the generic item api.

> 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 Park" 
> To: "Gustavo Sverzut Barb"
> Cc: "Tom Hacohen";
> 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
> Barbieri"
> To: "Tom Hacohen"
> Cc: "ChunEon Park";
> 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
>  wrote:
> > On 14/07/11 18:52, Gustavo Sverzut Barbieri wrote:
> >>
> >> 2011/7/13 ChunEon Park:
> >>>
> >>> 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


-- 
- 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] elm_diskselector

[The Rasterman]

On Mon, 25 Jul 2011 21:25:36 +0900 cnook  said:

> Hi All,
> 
> I have attached elm_diskselector patch for resolving dynamic theme change
> issue.
> Previously, the item label did not display when them theme had changed while
> elm_diskselector displayed.

hmm this patch shows something disturbing... why is diskselector storing parent
on creation? thats really bad. in fact...  why get geometry og parent AS
wd->minw? this makes no sense if disckselectro created initially as a child
of win.. u'll be getting window geometry and setting that size to minw. thats
wrong. if this were to actually use the current parent (which it does actually)
then the parent width becomes the selectors min width.. this is wrong. imagine
its in a horizontal box with 2 things horizontally.. this cant make logical
sense. so i've removed the whole getting parent width for min width from the
widget. it should be using the min_width data if set (i don't like this much..
but its not as bad as the parent thing).. the sizing_eval in the end calculates
a min size which is right using the minw/h from theme data.. if it exists.

-- 
- 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] new APIs about page

[Nicolas Aguirre]

2011/7/25 Jaehwan Kim :
> Dear all,
>
> I want to add new APIs for the page of the scroller.
> The APIs are,
> elm_scroller_current_page_get(Evas_Object, int *page_x, int *page_y)
> elm_scroller_page_show(Evas_Object, int page_x, int page_y)
> elm_scroller_page_bring_in(Evas_Object, int page_x, int page_y)
>
> elm_scroller_current_page_get
> -> It can get the current page number not pixel.
> elm_scroller_page_show
> -> It can show the page (page_x, page_y). page_x,y are the page number also.
> elm_scroller_page_bring_in
> -> It works same elm_scroller_page_show except the scroll animation.
>
> These APIs are useful for page function.
> I want to take your opinion.
>
> Thanks.
> --
> 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
>

I would like to have this function for Elfe !

-- 
Nicolas Aguirre
Mail: aguirre.nico...@gmail.com
Web: http://enna.geexbox.org
Blog: http://dev.enlightenment.fr/~captainigloo/

--
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] new APIs about page

[The Rasterman]

On Mon, 25 Jul 2011 06:22:09 + (GMT) Jaehwan Kim 
said:

> Dear all,
> 
> I want to add new APIs for the page of the scroller.
> The APIs are,
> elm_scroller_current_page_get(Evas_Object, int *page_x, int *page_y)
> elm_scroller_page_show(Evas_Object, int page_x, int page_y)
> elm_scroller_page_bring_in(Evas_Object, int page_x, int page_y)

hmmm so is this meant to divide the scorllable child into pages like the
paginated scrolling does and now address content by page instead of full
location? i assume that is what you mean by page? if so - then i have no
problem with these being added.

> elm_scroller_current_page_get 
> -> It can get the current page number not pixel.
> elm_scroller_page_show
> -> It can show the page (page_x, page_y). page_x,y are the page number also.
> elm_scroller_page_bring_in
> -> It works same elm_scroller_page_show except the scroll animation.
> 
> These APIs are useful for page function.
> I want to take your opinion.
> 
> Thanks.
> --
> 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
> 


-- 
- 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] elm cnp bugs remaining

[The Rasterman]

On Sun, 24 Jul 2011 17:57:48 -0400 Mike Blumenkrantz  said:

> I'm not claiming that I'll fix any/all of them, but at the least we should
> compile an actual list of all the cnp bugs that people have noticed. Since
> I've fixed a ton of them over the past couple days, I'll start:
> 
> * newlines are not respected

how are newlines not respected. i'm copy & pasting between gtk apps with
editors (my mail client), and my xterms and an entry in elm entry.. and the
newlines are there as expected. can you come up with some good reproducible
examples? maybe it's converting to utf8 and using ps's and the other end isnt
handling it well or something else. i DO notice that it's keeping the html-like
@quot; insetad of using the ' when its converting.

> * middle mouse paste (primary) always overwrites selected text instead of
>   respecting cursor position

i actually find the "paste where i middle click" incredibly annoying. elm does
what x has always done on middle click - paste AT the cursor... i suggest you
try out xedit... which long preceded anything in gtk... and x11 defined the
standard for middle button pasting as this. so elm follows that. it's also what
happens when u middle-paste in an editor in your xterm etc. too, so it's
consistent behavior. if gtk has decided to diverge.. well... it's going against
the grain of your terminals and the old middle paste rules defined by Xt (see
xedit).

> ?
> 
> -- 
> 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
> 


-- 
- 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] segfault of edje_cc during compilation of elementary

[The Rasterman]

On Sat, 23 Jul 2011 11:44:25 +0200 Tomas Cech  said:

i've added more error printing on engines not being found. fyi buffer enigne
is considered a default part of evas. it is always compiled as it has no
dependencies, thus using buffer enigne pretty much should never have an
error... well unless you mis-package evas like what happened to you :) well for
you buffer engine didn't load because a dependency (software generic - also
always compiled and installed as its required for buffer engine) wasn't
there. :)

> It also explains where 'image_colorspace_get' is defined when not
> redefined in engine.
> 
> After adding 'evas-module_engine_software_generic' to Requires field
> in the spec file problem vanished. I'll recheck which engines need
> this dependency and fix it too.
> 
> I'd suggest to print some error message when such condition happen and
> add check for not accessing NULL pointer there.
> 
> Thanks for your help!
> 
> Best regards,
> 
> Tomas Cech
> Sleep_Walker
> 
> --
> 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
> 


-- 
- 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] notify immodule to know the cursor location

[The Rasterman]

On Thu, 21 Jul 2011 19:22:14 +0900 Jihoon Kim  said:

hmm. patch didn't apply cleanly, so I had to manually patch in a lot of
rejections (12 of them), but I've put it in and fixed a warning as well. thanks
very much! :)

> Hi, EFL developers.
> 
> In immodule, the cursor location is needed to move the word candidate
> window.
> In this patch, calling ecore_imf_context_cursor_location_set lets immodule
> know the cursor location.
> 
> Would you please review this patch?
> 


-- 
- 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] header size...

[ChunEon Park]

+1
I do preper that method. I think user could find the groups easier .

Let's run together for the best moment!
 -Regards, Hermet-
 
-Original Message-
From: "Bruno Dilly" 
To: "Mike Blumenkrantz"
Cc: enlightenment-devel@lists.sourceforge.net
Sent: 11-07-29(금) 09:37:44
Subject: Re: [E-devel] header size...On Thu, Jul 28, 2011 at 7:53 PM, Mike 
Blumenkrantz  wrote:
> On Fri, 29 Jul 2011 00:38:50 +0200
> Hugo Camboulive  wrote:
>
>> Really you're worried about the approaching 20k lines of a header?
>> Please have a look at the 37k lines of the default.edc... that baby is 1.1MB
>> of raw text, and contains every possible elementary widget. (there's a
>> little difference with the header though : this one is made of very few
>> comments) :-D
> yeah, but nobody is arguing that default.edc is terrible. we all agree on that
> point.
it could be a edc file for each widget, and default would be just a
bunch of includes.
>>
>> Having had to modify one to fit to our style for ONE widget (hoversel, we
>> only use edje for the rest), I can tell you it was quite a nightmare. :-)
>>
>> On Thu, Jul 28, 2011 at 8:07 PM, David Seikel  
>> wrote:
>>
>> > As per Mikes request, moving the discussion part to this thread.
>> >
>> > > On 28/07/11 19:42, Mike Blumenkrantz wrote:
>> > > > This is a community project, so we can do stuff like having polls
>> > > > and taking votes right? Okay then, since there's been some
>> > > > disagreement with strong opinions on either side we're voting on a
>> > > > super important issue - header size. Specifically, the Elementary.h
>> > > > header.
>> > > >
>> > > > As with any serious vote, here is your ballot:
>> > > >
>> > > > 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
>> > > > 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
>> > > > 3) OTHER (Explain)
>> > > >
>> > > > This thread is for voting ONLY. Reply with your vote, no logical
>> > > > reasoning required. Any discussion can continue in the
>> > > > recently-made thread.
>> > >
>> > > I don't know why you guys care, it's not like you should ever open
>> > > that header...
>> >
>> > Um, I DO need to open the headers, so I know how to use it. Not
>> > everything is documented (well), and sometimes you have to use the
>> > source Luke.
>> >
>> > --
>> > A big old stinking pile of genius that no one wants
>> > coz there are too many silver coated monkeys in the world.
>> >
>> >
>> > --
>> > 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
>
>
> --
> 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
>
-- 
Bruno Dilly
Senior Developer
ProFUSION embedded systems
http://profusion.mobi
--
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

Re: [E-devel] [PATCH] XIM patch for generating preedit changed event

[Naruto TAKAHASHI]

oh... I forgot to add change event to preedit_draw callback function.
thanks to add this. :)

2011/7/29 WooHyun Jung :
> I tested this patch ~ and checked that it worked well : )
>
> In svn 61876 !!
>
>
> --
> 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
>



-- 
Naruto TAKAHASHI
tnar...@gmail.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

[E-devel] [PATCH] XIM patch for generating preedit changed event

[WooHyun Jung]

I tested this patch ~ and checked that it worked well : )

In svn 61876 !!


--
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] ecore: Add basic thread safety

[Vincent Torri]

On Fri, 29 Jul 2011, Mike McCormack wrote:

> On 07/28/2011 09:31 PM, Cedric BAIL wrote:
>
>> Before providing a benchmark, please revert your broken code and
>> provide a working solution based on my discussion with gustavo (using
>> Ecore_Pipe). Right know, and before doing benchmark, your solution
>> doesn't work in all case and that's a no go for me. It's already
>> painfull for us when we use thread that I don't want to dig why some
>> user have weird behaviour due to this half working solution.
>
> Hi Cedric,
>
> I haven't gotten any mail to Gustavo from you.  Please resend it.
>
> What is broken?  Which case does it not work for?
>
> My code adds a single mutex, which only ecore can see.
>
> The rules for use are fairly simple:
> * lock the mutex on entering ecore code
> * unlock the mutex on leaving ecore code
> * don't call functions that lock the mutex from within ecore
>
> Secondly, this code is disabled, so it shouldn't affect anything right now.
> As I understand, it's normal in EFL development to add code that is disabled,
> debug it, then enable it later when it works.

no. It's not normal at all.

Vincent

--
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

[E-devel] [PATCH] check NULL parameter in edje entry

[Jihoon Kim]

Hi, EFL developers.

This simple patch is for checking NULL parameter in the callback functions
related to input method framework.
I think it is necessary for safety.

Would you please apply this patch?


Index: edje_entry.c
===
--- edje_entry.c(revision 61874)
+++ edje_entry.c(working copy)
@@ -2801,7 +2801,7 @@ _edje_entry_imf_event_commit_cb(void *data, int ty
Evas_Textblock_Cursor *tc;
Eina_Bool cursor_move = EINA_FALSE;
 
-   if (!rp) return ECORE_CALLBACK_PASS_ON;
+   if ((!rp) || (!ev) || (!ev->str)) return ECORE_CALLBACK_PASS_ON;
 
en = rp->entry_data;
if ((!en) || (rp->part->type != EDJE_PART_TYPE_TEXTBLOCK) ||
@@ -2885,7 +2885,7 @@ _edje_entry_imf_event_preedit_changed_cb(void *dat
int i;
Eina_Bool preedit_end_state = EINA_FALSE;
 
-   if (!rp) return ECORE_CALLBACK_PASS_ON;
+   if ((!rp) || (!ev)) return ECORE_CALLBACK_PASS_ON;
 
en = rp->entry_data;
if ((!en) || (rp->part->type != EDJE_PART_TYPE_TEXTBLOCK) ||
@@ -2980,7 +2980,7 @@ _edje_entry_imf_event_delete_surrounding_cb(void *
Evas_Textblock_Cursor *del_start, *del_end;
int cursor_pos;
 
-   if (!rp) return ECORE_CALLBACK_PASS_ON;
+   if ((!rp) || (!ev)) return ECORE_CALLBACK_PASS_ON;
en = rp->entry_data;
if ((!en) || (rp->part->type != EDJE_PART_TYPE_TEXTBLOCK) ||
(rp->part->entry_mode < EDJE_ENTRY_EDIT_MODE_SELECTABLE))

--
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] ecore: Add basic thread safety

[Mike McCormack]

On 07/28/2011 10:35 PM, Cedric BAIL wrote:
> As I don't want the grumpy guy that don't help. You now have
> ecore_main_loop_thread_safe_call that should be the base for your
> patch. And I am still not convinced that we need more than that.
> People should just use that function when they are doing thread stuff
> and we should advertise it in our thread spanking message.

OK, thanks for spending the time to write this.

If you know you're writing code that's in a thread your function is
great.  Call it, and then schedule some work in the main loop, it's 
good.

But for a library writer:

1) assume thread safety (1 line):

ecore_event_add(LIB_EVENT, e, my_event_free, NULL);


2) Using ecore_main_loop_thread_safe_call (5 lines)

static void _event_main_loop_callback(void *data)
{
   ecore_event_add(LIB_EVENT, e, my_event_free, NULL);
}

/* will always be marshalled through pipe, even when not necessary */
ecore_main_loop_thread_safe_call(&_event_main_loop_callback, NULL);


3) Using ecore_main_loop_thread_safe_call, trying to be a bit more
   efficient (8 lines)

static void _event_main_loop_callback(void *data)
{
   ecore_event_add(LIB_EVENT, e, my_event_free, NULL);
}

if (!ecore_is_main_loop_thread())  /* assuming this function exists */
  ecore_main_loop_thread_safe_call(&_event_main_loop_callback, NULL);
else
  _event_main_loop_callback();

Case 2 & 3 are more verbose, and you need to add such code for *every* 
call to ecore (in a library).

So you end up pushing responsibilities to the library writers and 
applications that are better handled in Ecore itself.

IOW, it makes writing ecore code with threads a pain in the butt,
and reduces the potential audience of EFL.

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

[E-devel] [PATCH] XIM patch for generating preedit changed event

[Jihoon Kim]

Hi, EFL developers.

In XIM immodule, it doesn't generate preedit changed event in
preedit_draw_callback func at this moment.

This patch will solve this problem.

After I apply this patch, I verified Korean and Japanese preedit string is
inserted well.
Would you please review and apply this patch?

Index: ecore_imf_xim.c
===
--- ecore_imf_xim.c (revision 61874)
+++ ecore_imf_xim.c (working copy)
@@ -821,6 +821,8 @@ preedit_draw_callback(XIC
   eina_ustrbuf_string_steal(preedit_bufs);
   imf_context_data->preedit_length =
   eina_unicode_strlen(imf_context_data->preedit_chars);
+
+  ecore_imf_context_preedit_changed_event_add(ctx);
}
 
free(new_text);

--
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: mike_m IN trunk/ecore: . src/lib/ecore

[Mike McCormack]

On 07/28/2011 09:19 PM, Vincent Torri wrote:

> like cedric, i'm against such feature. Are you (or samsung ?) just 
> ignoring the opinions of other devs ?

Well, I have to say it's a bit frustrating that you guys take the attitude
that it's forbidden to add a feature that some guys think is beneficial.

True, this feature changes the rules a bit.

I don't think it's as harmful to performance as Cedric believes, or
difficult to debug, or obfuscates the code.

I added the code so you guys can see what I've done, review it, build it,
test it, and comment on it.  It's not enabled.  That is the EFL way.

I'm not a fan of threaded programming, and I avoid threads in my own 
programs, however I don't think forcing non-threaded style on everybody
is cool.

Recommend against threads, and don't use them -> GOOD
Prohibit use, and make sure that nobody can ever use a thread with Ecore -> BAD

Nobody in Samsung has pushed me to do this.  I have spent a lot of time
(>1 year) on main loop issues (integration with glib, recommending best
practices for main loops, etc) in Samsung, and based on that I created
this patch.

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] [PATCH] ecore: Add basic thread safety

[Mike McCormack]

On 07/28/2011 09:31 PM, Cedric BAIL wrote:

> Before providing a benchmark, please revert your broken code and
> provide a working solution based on my discussion with gustavo (using
> Ecore_Pipe). Right know, and before doing benchmark, your solution
> doesn't work in all case and that's a no go for me. It's already
> painfull for us when we use thread that I don't want to dig why some
> user have weird behaviour due to this half working solution.

Hi Cedric,

I haven't gotten any mail to Gustavo from you.  Please resend it.

What is broken?  Which case does it not work for?

My code adds a single mutex, which only ecore can see.

The rules for use are fairly simple:
* lock the mutex on entering ecore code
* unlock the mutex on leaving ecore code
* don't call functions that lock the mutex from within ecore

Secondly, this code is disabled, so it shouldn't affect anything right now.
As I understand, it's normal in EFL development to add code that is disabled,
debug it, then enable it later when it works.

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...

[Bruno Dilly]

On Thu, Jul 28, 2011 at 7:53 PM, Mike Blumenkrantz  wrote:
> On Fri, 29 Jul 2011 00:38:50 +0200
> Hugo Camboulive  wrote:
>
>> Really you're worried about the approaching 20k lines of a header?
>> Please have a look at the 37k lines of the default.edc... that baby is 1.1MB
>> of raw text, and contains every possible elementary widget. (there's a
>> little difference with the header though : this one is made of very few
>> comments) :-D
> yeah, but nobody is arguing that default.edc is terrible. we all agree on that
> point.

it could be a edc file for each widget, and default would be just a
bunch of includes.

>>
>> Having had to modify one to fit to our style for ONE widget (hoversel, we
>> only use edje for the rest), I can tell you it was quite a nightmare. :-)
>>
>> On Thu, Jul 28, 2011 at 8:07 PM, David Seikel  wrote:
>>
>> > As per Mikes request, moving the discussion part to this thread.
>> >
>> > > On 28/07/11 19:42, Mike Blumenkrantz wrote:
>> > > > This is a community project, so we can do stuff like having polls
>> > > > and taking votes right? Okay then, since there's been some
>> > > > disagreement with strong opinions on either side we're voting on a
>> > > > super important issue - header size. Specifically, the Elementary.h
>> > > > header.
>> > > >
>> > > > As with any serious vote, here is your ballot:
>> > > >
>> > > > 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
>> > > > 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
>> > > > 3) OTHER (Explain)
>> > > >
>> > > > This thread is for voting ONLY. Reply with your vote, no logical
>> > > > reasoning required. Any discussion can continue in the
>> > > > recently-made thread.
>> > >
>> > > I don't know why you guys care, it's not like you should ever open
>> > > that header...
>> >
>> > Um, I DO need to open the headers, so I know how to use it.  Not
>> > everything is documented (well), and sometimes you have to use the
>> > source Luke.
>> >
>> > --
>> > A big old stinking pile of genius that no one wants
>> > coz there are too many silver coated monkeys in the world.
>> >
>> >
>> > --
>> > 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
>
>
> --
> 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
>



-- 
Bruno Dilly
Senior Developer
ProFUSION embedded systems
http://profusion.mobi

--
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] ecore: Add basic thread safety

[Mike McCormack]

On 07/28/2011 08:18 PM, Vincent Torri wrote:

>> I have already added code to print warnings.  It helps, but the response is
>> usually, "but why isn't EFL thread safe?"
> 
> tell them to read the preamble there :
> 
> http://docs.enlightenment.org/auto/ecore/Ecore_Main_Loop_Page.html

Well, after repeating myself N times, it's reasonable to wonder
whether we're violating the principle of least surprise, then go
fix/remove the surprise.

If you want me to run benchmarks to show performance impact of the
change, let me know which ones will be appropriate.

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 POLL

[Brian Wang]

On Fri, Jul 29, 2011 at 12:42 AM, Mike Blumenkrantz  wrote:
> This is a community project, so we can do stuff like having polls and taking
> votes right? Okay then, since there's been some disagreement with strong
> opinions on either side we're voting on a super important issue - header size.
> Specifically, the Elementary.h header.
>
> As with any serious vote, here is your ballot:
>
> 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
> 3) OTHER (Explain)

#2. (me as an active Elementary user.)
(forgot to reply all)

>
> This thread is for voting ONLY. Reply with your vote, no logical reasoning
> required. Any discussion can continue in the recently-made thread.
>
> PS. I expect all active developers to vote on this, even if you do not have a
> strong opinion. I WILL grep through the devs/ directory and email each of you
> individually if I have to.
> --
> 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
>



-- 
brian
--

Cool-Karaoke - The smallest recording studio, in your palm, open-sourced
http://cool-idea.com.tw/

iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe

--
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...

[Mike Blumenkrantz]

On Fri, 29 Jul 2011 00:38:50 +0200
Hugo Camboulive  wrote:

> Really you're worried about the approaching 20k lines of a header?
> Please have a look at the 37k lines of the default.edc... that baby is 1.1MB
> of raw text, and contains every possible elementary widget. (there's a
> little difference with the header though : this one is made of very few
> comments) :-D
yeah, but nobody is arguing that default.edc is terrible. we all agree on that
point.
> 
> Having had to modify one to fit to our style for ONE widget (hoversel, we
> only use edje for the rest), I can tell you it was quite a nightmare. :-)
> 
> On Thu, Jul 28, 2011 at 8:07 PM, David Seikel  wrote:
> 
> > As per Mikes request, moving the discussion part to this thread.
> >
> > > On 28/07/11 19:42, Mike Blumenkrantz wrote:
> > > > This is a community project, so we can do stuff like having polls
> > > > and taking votes right? Okay then, since there's been some
> > > > disagreement with strong opinions on either side we're voting on a
> > > > super important issue - header size. Specifically, the Elementary.h
> > > > header.
> > > >
> > > > As with any serious vote, here is your ballot:
> > > >
> > > > 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> > > > 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
> > > > 3) OTHER (Explain)
> > > >
> > > > This thread is for voting ONLY. Reply with your vote, no logical
> > > > reasoning required. Any discussion can continue in the
> > > > recently-made thread.
> > >
> > > I don't know why you guys care, it's not like you should ever open
> > > that header...
> >
> > Um, I DO need to open the headers, so I know how to use it.  Not
> > everything is documented (well), and sometimes you have to use the
> > source Luke.
> >
> > --
> > A big old stinking pile of genius that no one wants
> > coz there are too many silver coated monkeys in the world.
> >
> >
> > --
> > 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


-- 
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...

[Hugo Camboulive]

Really you're worried about the approaching 20k lines of a header?
Please have a look at the 37k lines of the default.edc... that baby is 1.1MB
of raw text, and contains every possible elementary widget. (there's a
little difference with the header though : this one is made of very few
comments) :-D

Having had to modify one to fit to our style for ONE widget (hoversel, we
only use edje for the rest), I can tell you it was quite a nightmare. :-)

On Thu, Jul 28, 2011 at 8:07 PM, David Seikel  wrote:

> As per Mikes request, moving the discussion part to this thread.
>
> > On 28/07/11 19:42, Mike Blumenkrantz wrote:
> > > This is a community project, so we can do stuff like having polls
> > > and taking votes right? Okay then, since there's been some
> > > disagreement with strong opinions on either side we're voting on a
> > > super important issue - header size. Specifically, the Elementary.h
> > > header.
> > >
> > > As with any serious vote, here is your ballot:
> > >
> > > 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> > > 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
> > > 3) OTHER (Explain)
> > >
> > > This thread is for voting ONLY. Reply with your vote, no logical
> > > reasoning required. Any discussion can continue in the
> > > recently-made thread.
> >
> > I don't know why you guys care, it's not like you should ever open
> > that header...
>
> Um, I DO need to open the headers, so I know how to use it.  Not
> everything is documented (well), and sometimes you have to use the
> source Luke.
>
> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
>
>
> --
> 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] #define in Edje

[Tom Hacohen]

On 28/07/11 23:52, Andreas Volz wrote:
> Am Thu, 28 Jul 2011 20:17:03 +0900 schrieb Carsten Haitzler (The
> Rasterman):
> 
> I found it while playing with the clock theme
> (trunk/THEMES/darkness/modules/clock.edc)
> 
> See here my changes as minimal example:
> 
>#if PROFILE == HIGH
> x
> buf[0] = 0;
> if (v < 10) {snprintf(buf, 10, "0%i", v);}
> else{snprintf(buf, 10, "%i", v);}
> set_state(PART:"seconds", buf, 0.0);
>#endif
> 
> 
> This #if ends always in "true". You see it because edje fails (the "x")
> not interesting if -DPROFILE=HIGH or anything else or nothing.
> 
>#if PROFILE != HIGH
> x
> buf[0] = 0;
> if (v < 10) {snprintf(buf, 10, "0%i", v);}
> else{snprintf(buf, 10, "%i", v);}
> set_state(PART:"seconds", buf, 0.0);
>#endif
> 
> This #if ends always in "false". Also not depending on -DPROFILE.
> 
> These are at least my experiments.

Should that even work? I tried with "cpp" and it doesn't work unless I
#define HIGH 24324234 (some number).
and then doing -DPROFILE=HIGH works as expected.

To me, that's the expected result, to be honest, I was surprised cpp
didn't fail with #if PROFILE == HIGH without defining what they expand
to, because they should just expand to:
#if ==
which is bad.

Anyhow, I think it's better to just do: -DPROFILE_HIGH and check if
that's defined using #ifdef or #if defined().

Maybe I'm missing something, dunno, but from what I know, and from what
I've just tested with both epp and cpp, you are just using macros wrong.

--
Tom.

--
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] #define in Edje

[Andreas Volz]

Am Thu, 28 Jul 2011 20:17:03 +0900 schrieb Carsten Haitzler (The
Rasterman):

I found it while playing with the clock theme
(trunk/THEMES/darkness/modules/clock.edc)

See here my changes as minimal example:

   #if PROFILE == HIGH
x
buf[0] = 0;
if (v < 10) {snprintf(buf, 10, "0%i", v);}
else{snprintf(buf, 10, "%i", v);}
set_state(PART:"seconds", buf, 0.0);
   #endif


This #if ends always in "true". You see it because edje fails (the "x")
not interesting if -DPROFILE=HIGH or anything else or nothing.

   #if PROFILE != HIGH
x
buf[0] = 0;
if (v < 10) {snprintf(buf, 10, "0%i", v);}
else{snprintf(buf, 10, "%i", v);}
set_state(PART:"seconds", buf, 0.0);
   #endif

This #if ends always in "false". Also not depending on -DPROFILE.

These are at least my experiments.

regards
Andreas

> On Mon, 18 Jul 2011 23:31:43 +0200 Andreas Volz 
> said:
> 
> do you have an example?
> 
> you mean:
> 
> #if A != 10
> hello
> #endif
> 
> or something else?
> 
> > Hello,
> > 
> > it seems the ! and != operator in #define macros in EDC aren't
> > working. I tried various tests and only == was working nice.
> > 
> > Revision is 60268. Yes, a little old, but like to know if this bug
> > is still in latest sources.
> > 
> > regards
> > Andreas
> > 
> > -- 
> > Technical Blog 
> > 
> > --
> > 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
> > 
> 
> 
> -- 
> - 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
> 


-- 
Technical Blog 

--
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: cedric trunk/elementary/src/lib

[Rafael Antognolli]

On Thu, Jul 28, 2011 at 1:44 PM, Enlightenment SVN
 wrote:
> Log:
> elementary: fix fileselector expandable mode with eio.

I think you just broke it *without* eio...

> Author:       cedric
> Date:         2011-07-28 09:44:10 -0700 (Thu, 28 Jul 2011)
> New Revision: 61864
> Trac:         http://trac.enlightenment.org/e/changeset/61864
>
> Modified:
>  trunk/elementary/src/lib/elc_fileselector.c
>
> Modified: trunk/elementary/src/lib/elc_fileselector.c
> ===
> --- trunk/elementary/src/lib/elc_fileselector.c 2011-07-28 16:43:15 UTC (rev 
> 61863)
> +++ trunk/elementary/src/lib/elc_fileselector.c 2011-07-28 16:44:10 UTC (rev 
> 61864)
> @@ -649,9 +649,14 @@
>    _signal_first(wr);
>
>    if (wr->wd->mode == ELM_FILESELECTOR_LIST)
> -     elm_genlist_item_direct_sorted_insert(wr->wd->files_list, 
> eio_file_associate_find(handler, "type/list"),
> -                                           
> eina_stringshare_ref(eio_file_associate_find(handler, "filename")),
> -                                           wr->parent, 
> ELM_GENLIST_ITEM_NONE, _file_list_cmp, NULL, NULL);
> +     {
> +        Eina_Bool is_dir = (eio_file_associate_find(handler, "type/list") == 
> &list_itc[ELM_DIRECTORY]);
> +
> +        elm_genlist_item_direct_sorted_insert(wr->wd->files_list, 
> eio_file_associate_find(handler, "type/list"),
> +                                              
> eina_stringshare_ref(eio_file_associate_find(handler, "filename")),
> +                                              wr->parent, wr->wd->expand && 
> is_dir ? ELM_GENLIST_ITEM_SUBITEMS : ELM_GENLIST_ITEM_NONE,
> +                                              _file_list_cmp, NULL, NULL);
> +     }
>    else if (wr->wd->mode == ELM_FILESELECTOR_GRID)
>      elm_gengrid_item_direct_sorted_insert(wr->wd->files_grid, 
> eio_file_associate_find(handler, "type/grid"),
>                                            
> eina_stringshare_ref(eio_file_associate_find(handler, "filename")),
> @@ -675,9 +680,7 @@
>
>    _signal_first(wr);
>
> -#ifdef HAVE_EIO
>    wr->wd->current = NULL;
> -#endif
>    _widget_request_cleanup(wr);
>  }
>
> @@ -686,10 +689,8 @@
>  {
>    Widget_Request *wr = data;
>
> -#ifdef HAVE_EIO
>    if (wr->wd->current == handler)
>      wr->wd->current = NULL;
> -#endif
>    _widget_request_cleanup(wr);
>  }
>
> @@ -711,6 +712,7 @@
>  #endif
>
>    if (!wd) return;
 +   if (wd->expand && wd->current) return ;

And the above line seems to be the problem (won't change it though,
since I'm not digging into the problem).

>  #ifndef HAVE_EIO
>    if (!ecore_file_is_dir(path)) return ;
>    it = eina_file_stat_ls(path);
>
>
> --
> 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-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>



-- 
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi

--
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 POLL

[Christopher Michael]

On 07/28/2011 12:42 PM, Mike Blumenkrantz wrote:
> This is a community project, so we can do stuff like having polls and taking
> votes right? Okay then, since there's been some disagreement with strong
> opinions on either side we're voting on a super important issue - header size.
> Specifically, the Elementary.h header.
>
> As with any serious vote, here is your ballot:
>
> 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA

# 2 :)

or a good #3...Vincent's #3 would be acceptable ;)

dh


> 3) OTHER (Explain)
>
> This thread is for voting ONLY. Reply with your vote, no logical reasoning
> required. Any discussion can continue in the recently-made thread.
>
> PS. I expect all active developers to vote on this, even if you do not have a
> strong opinion. I WILL grep through the devs/ directory and email each of you
> individually if I have to.


--
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 POLL

[Vincent Torri]

On Thu, 28 Jul 2011, Mike Blumenkrantz wrote:

> This is a community project, so we can do stuff like having polls and taking
> votes right? Okay then, since there's been some disagreement with strong
> opinions on either side we're voting on a super important issue - header size.
> Specifically, the Elementary.h header.
>
> As with any serious vote, here is your ballot:
>
> 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
> 3) OTHER (Explain)

3)

In .h : only API doc. everything else should be moved outside the 
header. I'm not against 2).

Vincent

>
> This thread is for voting ONLY. Reply with your vote, no logical reasoning
> required. Any discussion can continue in the recently-made thread.
>
> PS. I expect all active developers to vote on this, even if you do not have a
> strong opinion. I WILL grep through the devs/ directory and email each of you
> individually if I have to.
> -- 
> 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 POLL

[Sachiel]

Since this subject is annoying, I will also be annoying by top-posting.

I like my docs in the .c files, and keep in the .h whatever is needed to
be there only. If needed, doxygen even supports having docs in some
other random file, but I like headers to be as small and packed as possible
so the entire list of functions fits in one terminal window.

2011/7/28 Mike Blumenkrantz :
> On Thu, 28 Jul 2011 20:22:51 +0300
> Tom Hacohen  wrote:
>
>> On 28/07/11 19:42, Mike Blumenkrantz wrote:
>> > This is a community project, so we can do stuff like having polls and 
>> > taking
>> > votes right? Okay then, since there's been some disagreement with strong
>> > opinions on either side we're voting on a super important issue - header
>> > size. Specifically, the Elementary.h header.
>> >
>> > As with any serious vote, here is your ballot:
>> >
>> > 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
>> > 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
>> > 3) OTHER (Explain)
>> >
>> > This thread is for voting ONLY. Reply with your vote, no logical reasoning
>> > required. Any discussion can continue in the recently-made thread.
>> >
>> > PS. I expect all active developers to vote on this, even if you do not have
>> > a strong opinion. I WILL grep through the devs/ directory and email each of
>> > you individually if I have to.
>>
>> I don't know why you guys care, it's not like you should ever open that
>> header... I personally think eina's separation is a bit annoying, but I
>> don't care either way. If you twist my arm and force me to choose one, I
>> guess 2 makes more sense (As long as I don't have to do anything to
>> support it).
>>
>> But can you summarize all points brought up by both camps?
> no, you can read through the header threads for that.
> THIS THREAD IS ONLY FOR VOTING. READ.
>>
>> --
>> Tom.
>
>
> --
> 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 POLL

[Mike Blumenkrantz]

On Thu, 28 Jul 2011 20:22:51 +0300
Tom Hacohen  wrote:

> On 28/07/11 19:42, Mike Blumenkrantz wrote:
> > This is a community project, so we can do stuff like having polls and taking
> > votes right? Okay then, since there's been some disagreement with strong
> > opinions on either side we're voting on a super important issue - header
> > size. Specifically, the Elementary.h header.
> > 
> > As with any serious vote, here is your ballot:
> > 
> > 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> > 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
> > 3) OTHER (Explain)
> > 
> > This thread is for voting ONLY. Reply with your vote, no logical reasoning
> > required. Any discussion can continue in the recently-made thread.
> > 
> > PS. I expect all active developers to vote on this, even if you do not have
> > a strong opinion. I WILL grep through the devs/ directory and email each of
> > you individually if I have to.
> 
> I don't know why you guys care, it's not like you should ever open that
> header... I personally think eina's separation is a bit annoying, but I
> don't care either way. If you twist my arm and force me to choose one, I
> guess 2 makes more sense (As long as I don't have to do anything to
> support it).
> 
> But can you summarize all points brought up by both camps?
no, you can read through the header threads for that.
THIS THREAD IS ONLY FOR VOTING. READ.
> 
> --
> Tom.


-- 
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...

[David Seikel]

As per Mikes request, moving the discussion part to this thread.

> On 28/07/11 19:42, Mike Blumenkrantz wrote:
> > This is a community project, so we can do stuff like having polls
> > and taking votes right? Okay then, since there's been some
> > disagreement with strong opinions on either side we're voting on a
> > super important issue - header size. Specifically, the Elementary.h
> > header.
> > 
> > As with any serious vote, here is your ballot:
> > 
> > 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> > 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
> > 3) OTHER (Explain)
> > 
> > This thread is for voting ONLY. Reply with your vote, no logical
> > reasoning required. Any discussion can continue in the
> > recently-made thread.
> 
> I don't know why you guys care, it's not like you should ever open
> that header...

Um, I DO need to open the headers, so I know how to use it.  Not
everything is documented (well), and sometimes you have to use the
source Luke.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
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 POLL

[Tom Hacohen]

On 28/07/11 19:42, Mike Blumenkrantz wrote:
> This is a community project, so we can do stuff like having polls and taking
> votes right? Okay then, since there's been some disagreement with strong
> opinions on either side we're voting on a super important issue - header size.
> Specifically, the Elementary.h header.
> 
> As with any serious vote, here is your ballot:
> 
> 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
> 3) OTHER (Explain)
> 
> This thread is for voting ONLY. Reply with your vote, no logical reasoning
> required. Any discussion can continue in the recently-made thread.
> 
> PS. I expect all active developers to vote on this, even if you do not have a
> strong opinion. I WILL grep through the devs/ directory and email each of you
> individually if I have to.

I don't know why you guys care, it's not like you should ever open that
header... I personally think eina's separation is a bit annoying, but I
don't care either way. If you twist my arm and force me to choose one, I
guess 2 makes more sense (As long as I don't have to do anything to
support it).

But can you summarize all points brought up by both camps?

--
Tom.

--
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 POLL

[David Seikel]

On Thu, 28 Jul 2011 12:42:32 -0400 Mike Blumenkrantz
 wrote:

> 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
> 3) OTHER (Explain)

2 gets my vote.

> PS. I expect all active developers to vote on this, even if you do
> not have a strong opinion. I WILL grep through the devs/ directory
> and email each of you individually if I have to.

I committed a couple of times this year, guess that makes me active.
B-)

BTW, I am actively using elementary in a paid for project, my vote might
count as an active user to.  Certainly the outcome will impact me.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
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 POLL

[Cedric BAIL]

On Thu, Jul 28, 2011 at 6:42 PM, Mike Blumenkrantz  wrote:
> This is a community project, so we can do stuff like having polls and taking
> votes right? Okay then, since there's been some disagreement with strong
> opinions on either side we're voting on a super important issue - header size.
> Specifically, the Elementary.h header.
>
> As with any serious vote, here is your ballot:
>
> 1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
> 2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
> 3) OTHER (Explain)
>
> This thread is for voting ONLY. Reply with your vote, no logical reasoning
> required. Any discussion can continue in the recently-made thread.

I vote for number 2.

> PS. I expect all active developers to vote on this, even if you do not have a
> strong opinion. I WILL grep through the devs/ directory and email each of you
> individually if I have to.

Hehehe ! Have fun :-)
-- 
Cedric BAIL

--
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

[E-devel] HEADER SIZE POLL

[Mike Blumenkrantz]

This is a community project, so we can do stuff like having polls and taking
votes right? Okay then, since there's been some disagreement with strong
opinions on either side we're voting on a super important issue - header size.
Specifically, the Elementary.h header.

As with any serious vote, here is your ballot:

1) LEAVE AS-IS, CONTINUE ADDING DOCS TO Elementary.h
2) SPLIT INTO WIDGET HEADERS SIMILAR TO EINA
3) OTHER (Explain)

This thread is for voting ONLY. Reply with your vote, no logical reasoning
required. Any discussion can continue in the recently-made thread.

PS. I expect all active developers to vote on this, even if you do not have a
strong opinion. I WILL grep through the devs/ directory and email each of you
individually if I have to.
-- 
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] E SVN: mike_m IN trunk/ecore: . src/lib/ecore

[Mike Blumenkrantz]

On Thu, 28 Jul 2011 10:16:40 -0300
Iván Briano (Sachiel)  wrote:

> 2011/7/28 Vincent Torri :
> >
> > like cedric, i'm against such feature. Are you (or samsung ?) just
> > ignoring the opinions of other devs ?
> >
> > Also, i would like to know raster's opinion.
> >
> > I'm tempted to revert that commit
> >
> > Vincent
> >
> 
> I'm against too but I've been accused of being a grumpy old man
> that doesn't move on with the times.
> 
> Yet, I think not making my opinion heard adds to the "no one complained,
> so it must be fine" that we should also try to avoid.
+1
> 
> > On Thu, 28 Jul 2011, Enlightenment SVN wrote:
> >
> >> Log:
> >> ecore: Add main loop thread safety
> >>
> >>  Thread safety is disabled by default.
> >>  Enable it with --enable-thread-safety
> >>
> >>  Should cover timers, events, animators, idlers and fd handlers.
> >>
> >>  Tested with Enlightenment and elementary_test.
> >>
> >>  Signed-off-by: Mike McCormack 
> >>
> >> Author:       mike_m
> >> Date:         2011-07-28 05:01:16 -0700 (Thu, 28 Jul 2011)
> >> New Revision: 61851
> >> Trac:         http://trac.enlightenment.org/e/changeset/61851
> >>
> >> Modified:
> >>  trunk/ecore/configure.ac trunk/ecore/src/lib/ecore/ecore_anim.c
> >> trunk/ecore/src/lib/ecore/ecore_events.c
> >> trunk/ecore/src/lib/ecore/ecore_idle_enterer.c
> >> trunk/ecore/src/lib/ecore/ecore_idle_exiter.c
> >> trunk/ecore/src/lib/ecore/ecore_idler.c
> >> trunk/ecore/src/lib/ecore/ecore_main.c
> >> trunk/ecore/src/lib/ecore/ecore_private.h
> >> trunk/ecore/src/lib/ecore/ecore_signal.c
> >> trunk/ecore/src/lib/ecore/ecore_thread.c
> >> trunk/ecore/src/lib/ecore/ecore_timer.c
> >>

-- 
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] elm tooltip api changes

[Mike Blumenkrantz]

On Thu, 28 Jul 2011 09:55:53 -0300
Rafael Antognolli  wrote:

> On Wed, Jul 27, 2011 at 1:40 PM, Mike Blumenkrantz  wrote:
> > Currently the elm tooltip api is mismatched and confusing. I propose the
> > following steps:
> >
> > 1) Remove all list/genlist/gengrid/etc tooltip calls
> > 2) Add Evas_Object *elm_object_tooltip_add(Evas_Object *parent) to affix
> > tooltips to objects and return the tooltip object
> > 3) Change current tooltip api to use above object
> > 4) Rename tooltip api to elm_tooltip_*
> >
> > Thoughts?
> 
> Same set of APIs to elm_object_item_tooltip_* ? Or you think it's
> possible to handle that with only one API?
> 
I hadn't thought about that, but now that I have I think it's doable.

-- 
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] E SVN: cedric IN trunk/ecore: . src/lib/ecore

[Vincent Torri]

@since

On Thu, 28 Jul 2011, Enlightenment SVN wrote:

> Log:
> ecore: add ecore_main_loop_thread_safe_call.
>
>  NOTE: that's for you mike.
>
>
> Author:   cedric
> Date: 2011-07-28 06:33:14 -0700 (Thu, 28 Jul 2011)
> New Revision: 61857
> Trac: http://trac.enlightenment.org/e/changeset/61857
>
> Modified:
>  trunk/ecore/ChangeLog trunk/ecore/src/lib/ecore/Ecore.h 
> trunk/ecore/src/lib/ecore/ecore.c
>
> Modified: trunk/ecore/ChangeLog
> ===
> --- trunk/ecore/ChangeLog 2011-07-28 13:00:39 UTC (rev 61856)
> +++ trunk/ecore/ChangeLog 2011-07-28 13:33:14 UTC (rev 61857)
> @@ -263,9 +263,13 @@
> 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
>
> +2011-07-28  Cedric Bail
> +
> + * Add ecore_main_loop_thread_safe_call.
> +
>
> Modified: trunk/ecore/src/lib/ecore/Ecore.h
> ===
> --- trunk/ecore/src/lib/ecore/Ecore.h 2011-07-28 13:00:39 UTC (rev 61856)
> +++ trunk/ecore/src/lib/ecore/Ecore.h 2011-07-28 13:33:14 UTC (rev 61857)
> @@ -737,6 +737,22 @@
>EAPI void*ecore_main_win32_handler_del(Ecore_Win32_Handler 
> *win32_handler);
>
>   /**
> +   * @brief Call callback in the main loop.
> +   *
> +   * @param callback The callback to call in the main loop
> +   * @param data The data to give to that call back
> +   *
> +   * For all call that need to happen in the main loop (most EFL functions 
> do),
> +   * this helper function provide the infrastructure needed to do it safely
> +   * by avoind dead lock, race condition and properly wake up the main loop.
> +   *
> +   * Remember after that function call, you should never touch again the @p 
> data
> +   * in the thread, it is owned by the main loop and you callback should take
> +   * care of freeing it if necessary.
> +   */
> +   EAPI void ecore_main_loop_thread_safe_call(Ecore_Cb 
> callback, void *data);
> +
> +  /**
>* @}
>*/
>
>
> Modified: trunk/ecore/src/lib/ecore/ecore.c
> ===
> --- trunk/ecore/src/lib/ecore/ecore.c 2011-07-28 13:00:39 UTC (rev 61856)
> +++ trunk/ecore/src/lib/ecore/ecore.c 2011-07-28 13:33:14 UTC (rev 61857)
> @@ -53,6 +53,17 @@
> int _ecore_log_dom = -1;
> int _ecore_fps_debug = 0;
>
> +typedef struct _Ecore_Safe_Call Ecore_Safe_Call;
> +struct _Ecore_Safe_Call
> +{
> +   Ecore_Cb cb;
> +   void *data;
> +};
> +
> +static void _thread_callback(void *data, void *buffer, unsigned int nbyte);
> +static Ecore_Pipe *_thread_call = NULL;
> +static Eina_Lock _thread_safety;
> +
> /** OpenBSD does not define CODESET
>  * FIXME ??
>  */
> @@ -126,6 +137,9 @@
>_ecore_job_init();
>_ecore_time_init();
>
> +   eina_lock_new(&_thread_safety);
> +   _thread_call = ecore_pipe_add(_thread_callback, NULL);
> +
> #if HAVE_MALLINFO
>if (getenv("ECORE_MEM_STAT"))
>  {
> @@ -165,6 +179,9 @@
>if (--_ecore_init_count != 0)
>  return _ecore_init_count;
>
> +   ecore_pipe_del(_thread_call);
> +   eina_lock_free(&_thread_safety);
> +
>if (_ecore_fps_debug) _ecore_fps_debug_shutdown();
>_ecore_poller_shutdown();
>_ecore_animator_shutdown();
> @@ -203,6 +220,22 @@
>return _ecore_init_count;
> }
>
> +EAPI void
> +ecore_main_loop_thread_safe_call(Ecore_Cb callback, void *data)
> +{
> +   Ecore_Safe_Call *order;
> +
> +   order = malloc(sizeof (Ecore_Safe_Call));
> +   if (!order) return ;
> +
> +   order->cb = callback;
> +   order->data = data;
> +
> +   eina_lock_take(&_thread_safety);
> +   ecore_pipe_write(_thread_call, &order, sizeof (Ecore_Safe_Call*));
> +   eina_lock_release(&_thread_safety);
> +}
> +
> /**
>  * @}
>  */
> @@ -428,3 +461,18 @@
> }
>
> #endif
> +
> +static void
> +_thread_callback(void *data __UNUSED__, void *buffer, unsigned int nbyte)
> +{
> +   Ecore_Safe_Call *call = buffer;
> +
> +   while (nbyte >= sizeof (Ecore_Safe_Call*))
> + {
> +call->cb(call->data);
> +free(call);
> +
> +call++;
> +nbyte -= sizeof (Ecore_Safe_Call*);
> + }
> +}
>
>
> --
> 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-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll 

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[Cedric BAIL]

As I don't want the grumpy guy that don't help. You now have
ecore_main_loop_thread_safe_call that should be the base for your
patch. And I am still not convinced that we need more than that.
People should just use that function when they are doing thread stuff
and we should advertise it in our thread spanking message.

On Thu, Jul 28, 2011 at 2:31 PM, Cedric BAIL  wrote:
> GRUMBL !!!
>
> On Thu, Jul 28, 2011 at 1:13 PM, Mike McCormack
>  wrote:
>> On 07/28/2011 07:32 PM, Cedric BAIL wrote:
>>> Maybe stable, but the rendered scene will not make sense and be highly
>>> difficult to debug. So spank and point people to the right solution.
>>
>> This is ecore, not evas.  Adding timers from a thread makes sense to me.
>>
>> I'm not proposing this as a solution for Evas.  Perhaps adding a thread
>> check is better there... I haven't looked at it closely.
>>
 * nobody complained when I added checks to show that ecore calls are coming
  from the same thread, even though the performance "impact" would be 
 comparable.
  (See ECORE_MAIN_LOOP_ASSERT)
>>>
>>> Because if needed, we can turn it off without breaking application or
>>> any behaviour. Something that was working with it on will work with it
>>> off. It something that we could use in a development build and remove
>>> from the production build without the need to worry about it at all.
>>
>> If you're worried about this, how about I add a function call that
>> can set the _ecore_lock() and _ecore_unlock() functions.  If they are
>> NULL, the won't be called.
>>
>> Also, if you worry so much about performance, please let me know what
>> benchmarking you want done to show the overhead.
>
> Before providing a benchmark, please revert your broken code and
> provide a working solution based on my discussion with gustavo (using
> Ecore_Pipe). Right know, and before doing benchmark, your solution
> doesn't work in all case and that's a no go for me. It's already
> painfull for us when we use thread that I don't want to dig why some
> user have weird behaviour due to this half working solution.
>
>>> I thing that this will get confusing and people will introduce more
>>> bug, because the barrier with thread safety will be blured, some
>>> function call will work, some won't. At the end, I think you are
>>> increasing the complexity of the EFL without any benefit, you will
>>> have more and more complex code to debug (because every thing will not
>>> be thread safe). I really am more for a macro that display a spank
>>> with backtrace and do nothing in all efl function call (including
>>> evas, edje and elementary), that point to Ecore_Thread documentation.
>>> In fact halt of that code is already provided by eina, I can provide
>>> it quickly if that feat your need. This will put the burden of the fix
>>> on the developer and not you. They will know exactly where and how to
>>> fix it.
>>
>> I have already added code to print warnings.  It helps, but the response is
>> usually, "but why isn't EFL thread safe?"
>
> Because it's not Java and most people don't understand thread. From my
> own experience what ever you try to do, people will mess with thread.
> Not a single student coming out of school will get thread right and it
> will take them a lot of time before they can effectivly use it safely
> and in a more efficient way than just using a callback/state machine
> as the ecore main loop. That's why we have Ecore_Thread, to put a
> clear barier where you use thread only for your calc and blocking
> operation and go back into the main loop for any UI related operation.
> It's here to help every developper including us.
>
>> Adding thread safety means:
>>
>> * one whole class of API misuse and potential problems is gone
>
> And one whole class of new bug to dig in harder is in.
>
>> * people who think they know what they're doing can use threads without
>>  worrying that ecore is a source of problems
>
> If they know thread, then ecore wouldn't be the source of problems.
>
>> * we offer the same features to 3rd parties as we want to use inside EFL.
>>
>> It's a bit hypocritical to say "Well, the EVAS code can use threads,
>> because we're E-lite developers, but users of our API should never be able
>> to use threads, and should get spanked for doing so."
>
> No it's not. Maybe we're E-lite developer, but our thread code is
> starting to be fine only since a few month (and i wouldn't bet on it).
> That's why we provide infra with Ecore_Thread to minimize the risk of
> race condition and other nice dead lock. It's also why we will
> certainly use Ecore to do the sharing ressource daemon for next
> generation of pipeline rendering, to avoid going into the async mess
> again.
>   And I agree, we provide the same infra for 3rd parties as we want
> to use inside EFL, that's called Ecore_Thread. To be really clear from
> my point of view, thread should only be used for blocking operation
> and heavy computational task. Trying to advertise more than that wi

Re: [E-devel] [Patch] Add XIM module for ecore_imf

[Sachiel]

2011/7/28 Naruto TAKAHASHI :
> Thanks, raster!
>
> BTW, where is iBus config? :)
>

It's not there, but the imc files used by E are just plain Eet.
It should be easy to decode one to use as a base for the ibus one.

> 2011/7/28 Carsten Haitzler :
>> On Tue, 26 Jul 2011 13:57:05 -0300 Iván Briano (Sachiel) 
>> said:
>>
>> and that's now set up with the scim, uim and iimf configs for input methods 
>> in
>> e17. :)
>>
>>> 2011年7月26日13:52 Naruto TAKAHASHI :
>>> > 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 :
>>> >> On Sat, 23 Jul 2011 22:22:10 +0900 Jihoon Kim  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 
>>> >>>
>>> >>> > 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 :
>>> >>> > > 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 :
>>> >>> > >> 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 
>>> >>> > >> 
>>> >>> > 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.
>>> >>> > >>> (

Re: [E-devel] [Patch] Add XIM module for ecore_imf

[Naruto TAKAHASHI]

Thanks, raster!

BTW, where is iBus config? :)

2011/7/28 Carsten Haitzler :
> On Tue, 26 Jul 2011 13:57:05 -0300 Iván Briano (Sachiel) 
> said:
>
> and that's now set up with the scim, uim and iimf configs for input methods in
> e17. :)
>
>> 2011年7月26日13:52 Naruto TAKAHASHI :
>> > 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 :
>> >> On Sat, 23 Jul 2011 22:22:10 +0900 Jihoon Kim  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 
>> >>>
>> >>> > 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 :
>> >>> > > 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 :
>> >>> > >> 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 
>> >>> > >> 
>> >>> > 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 :
>> >>> > >>> > On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote:
>> >>> > >>> >> H

[E-devel] New important textblock formats - Esp. for theme designers

[Tom Hacohen]

Dear all,

Today I added two new important textblock formats:
font_weight and font_style.
These two let us override just weight (e.g bold) or style (e.g italic) 
of the font, solving two big problems we had:
1. The ///etc. tags were font specific (Sans in the default 
theme).
2. You couldn't mix  and  for example, because one would override 
the other.

Those two formats solve the above two issues.

In order to use them by default, theme designers should adjust their 
elementary themes as I did in commit 61856 to elementary.

Cheers,
Tom.

--
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] elm tooltip api changes

[Rafael Antognolli]

On Wed, Jul 27, 2011 at 1:40 PM, Mike Blumenkrantz  wrote:
> Currently the elm tooltip api is mismatched and confusing. I propose the
> following steps:
>
> 1) Remove all list/genlist/gengrid/etc tooltip calls
> 2) Add Evas_Object *elm_object_tooltip_add(Evas_Object *parent) to affix
> tooltips to objects and return the tooltip object
> 3) Change current tooltip api to use above object
> 4) Rename tooltip api to elm_tooltip_*
>
> Thoughts?

Same set of APIs to elm_object_item_tooltip_* ? Or you think it's
possible to handle that with only one API?

-- 
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi

--
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] ecore: Add basic thread safety

[Cedric BAIL]

GRUMBL !!!

On Thu, Jul 28, 2011 at 1:13 PM, Mike McCormack
 wrote:
> On 07/28/2011 07:32 PM, Cedric BAIL wrote:
>> Maybe stable, but the rendered scene will not make sense and be highly
>> difficult to debug. So spank and point people to the right solution.
>
> This is ecore, not evas.  Adding timers from a thread makes sense to me.
>
> I'm not proposing this as a solution for Evas.  Perhaps adding a thread
> check is better there... I haven't looked at it closely.
>
>>> * nobody complained when I added checks to show that ecore calls are coming
>>>  from the same thread, even though the performance "impact" would be 
>>> comparable.
>>>  (See ECORE_MAIN_LOOP_ASSERT)
>>
>> Because if needed, we can turn it off without breaking application or
>> any behaviour. Something that was working with it on will work with it
>> off. It something that we could use in a development build and remove
>> from the production build without the need to worry about it at all.
>
> If you're worried about this, how about I add a function call that
> can set the _ecore_lock() and _ecore_unlock() functions.  If they are
> NULL, the won't be called.
>
> Also, if you worry so much about performance, please let me know what
> benchmarking you want done to show the overhead.

Before providing a benchmark, please revert your broken code and
provide a working solution based on my discussion with gustavo (using
Ecore_Pipe). Right know, and before doing benchmark, your solution
doesn't work in all case and that's a no go for me. It's already
painfull for us when we use thread that I don't want to dig why some
user have weird behaviour due to this half working solution.

>> I thing that this will get confusing and people will introduce more
>> bug, because the barrier with thread safety will be blured, some
>> function call will work, some won't. At the end, I think you are
>> increasing the complexity of the EFL without any benefit, you will
>> have more and more complex code to debug (because every thing will not
>> be thread safe). I really am more for a macro that display a spank
>> with backtrace and do nothing in all efl function call (including
>> evas, edje and elementary), that point to Ecore_Thread documentation.
>> In fact halt of that code is already provided by eina, I can provide
>> it quickly if that feat your need. This will put the burden of the fix
>> on the developer and not you. They will know exactly where and how to
>> fix it.
>
> I have already added code to print warnings.  It helps, but the response is
> usually, "but why isn't EFL thread safe?"

Because it's not Java and most people don't understand thread. From my
own experience what ever you try to do, people will mess with thread.
Not a single student coming out of school will get thread right and it
will take them a lot of time before they can effectivly use it safely
and in a more efficient way than just using a callback/state machine
as the ecore main loop. That's why we have Ecore_Thread, to put a
clear barier where you use thread only for your calc and blocking
operation and go back into the main loop for any UI related operation.
It's here to help every developper including us.

> Adding thread safety means:
>
> * one whole class of API misuse and potential problems is gone

And one whole class of new bug to dig in harder is in.

> * people who think they know what they're doing can use threads without
>  worrying that ecore is a source of problems

If they know thread, then ecore wouldn't be the source of problems.

> * we offer the same features to 3rd parties as we want to use inside EFL.
>
> It's a bit hypocritical to say "Well, the EVAS code can use threads,
> because we're E-lite developers, but users of our API should never be able
> to use threads, and should get spanked for doing so."

No it's not. Maybe we're E-lite developer, but our thread code is
starting to be fine only since a few month (and i wouldn't bet on it).
That's why we provide infra with Ecore_Thread to minimize the risk of
race condition and other nice dead lock. It's also why we will
certainly use Ecore to do the sharing ressource daemon for next
generation of pipeline rendering, to avoid going into the async mess
again.
   And I agree, we provide the same infra for 3rd parties as we want
to use inside EFL, that's called Ecore_Thread. To be really clear from
my point of view, thread should only be used for blocking operation
and heavy computational task. Trying to advertise more than that will
just end with more bug to fix in user application. Some time, it's
better not to provide to much, just to be sure that most people take
the wrong path. As a side note, when I want student to hit a wall, I
just lure them into using thread, none of them ever get anything
working properly with it in any sane amount of time.
   I personnally thing that Grand Central Dispatch from Apple is the
right design when we are speaking about thread
(http://en.wikipedia.org/wiki/Grand_Central_Dispatch) 

Re: [E-devel] E SVN: mike_m IN trunk/ecore: . src/lib/ecore

[Vincent Torri]

like cedric, i'm against such feature. Are you (or samsung ?) just 
ignoring the opinions of other devs ?

Also, i would like to know raster's opinion.

I'm tempted to revert that commit

Vincent

On Thu, 28 Jul 2011, Enlightenment SVN wrote:

> Log:
> ecore: Add main loop thread safety
>
>  Thread safety is disabled by default.
>  Enable it with --enable-thread-safety
>
>  Should cover timers, events, animators, idlers and fd handlers.
>
>  Tested with Enlightenment and elementary_test.
>
>  Signed-off-by: Mike McCormack 
>
> Author:   mike_m
> Date: 2011-07-28 05:01:16 -0700 (Thu, 28 Jul 2011)
> New Revision: 61851
> Trac: http://trac.enlightenment.org/e/changeset/61851
>
> Modified:
>  trunk/ecore/configure.ac trunk/ecore/src/lib/ecore/ecore_anim.c 
> trunk/ecore/src/lib/ecore/ecore_events.c 
> trunk/ecore/src/lib/ecore/ecore_idle_enterer.c 
> trunk/ecore/src/lib/ecore/ecore_idle_exiter.c 
> trunk/ecore/src/lib/ecore/ecore_idler.c 
> trunk/ecore/src/lib/ecore/ecore_main.c 
> trunk/ecore/src/lib/ecore/ecore_private.h 
> trunk/ecore/src/lib/ecore/ecore_signal.c 
> trunk/ecore/src/lib/ecore/ecore_thread.c 
> trunk/ecore/src/lib/ecore/ecore_timer.c
>
> Modified: trunk/ecore/configure.ac
> ===
> --- trunk/ecore/configure.ac  2011-07-28 12:01:04 UTC (rev 61850)
> +++ trunk/ecore/configure.ac  2011-07-28 12:01:16 UTC (rev 61851)
> @@ -1161,6 +1161,22 @@
>],
>[have_threads="no"])
>
> +### enable thread safety if we have threads, unless specifically asked not to
> +if test "x${have_threads}" = "xno"
> +then
> +  want_thread_safety="no"
> +else
> +  want_thread_safety="no"  # to be changed to yes when ready
> +  AC_ARG_ENABLE(thread-safety,
> +AC_HELP_STRING([--enable-thread-safety], [enable or disable thread 
> safety]),
> +[want_thread_safety=$enableval])
> +fi
> +
> +if test "x${want_thread_safety}" = "xyes"
> +then
> +   AC_DEFINE([HAVE_THREAD_SAFETY], [1], [Define to enable thread safety])
> +fi
> +
> ### Checks for types
> AC_CHECK_SIZEOF(int, 4)
> AC_CHECK_SIZEOF(long, 4)
> @@ -1706,6 +1722,7 @@
> echo
> echo "  Ecore: always"
> echo "Thread support.: $have_threads"
> +echo "Thread safety..: $want_thread_safety"
> echo "GLib support...: $have_glib"
> echo "Always integrate GLib..: $want_glib_integration_always"
> echo "Use g_main_loop: $want_g_main_loop"
>
> Modified: trunk/ecore/src/lib/ecore/ecore_anim.c
> ===
> --- trunk/ecore/src/lib/ecore/ecore_anim.c2011-07-28 12:01:04 UTC (rev 
> 61850)
> +++ trunk/ecore/src/lib/ecore/ecore_anim.c2011-07-28 12:01:16 UTC (rev 
> 61851)
> @@ -54,10 +54,10 @@
>  double t_loop = ecore_loop_time_get();
>  double sync_0 = 0.0;
>  double d = -fmod(t_loop - sync_0, animators_frametime);
> -
> - timer = ecore_timer_loop_add(animators_frametime,
> -  _ecore_animator, NULL);
> - ecore_timer_delay(timer, d);
> +
> + timer = _ecore_timer_loop_add(animators_frametime,
> +_ecore_animator, NULL);
> + _ecore_timer_delay(timer, d);
>   }
> break;
>   case ECORE_ANIMATOR_SOURCE_CUSTOM:
> @@ -78,7 +78,7 @@
>   case ECORE_ANIMATOR_SOURCE_TIMER:
> if (timer)
>   {
> - ecore_timer_del(timer);
> + _ecore_timer_del(timer);
>  timer = NULL;
>   }
> break;
> @@ -99,7 +99,17 @@
>  {
> if (!animator->delete_me && !animator->suspended)
>   {
> - if (!animator->func(animator->data))
> + Ecore_Task_Cb func;
> + void *data;
> + Eina_Bool ret;
> +
> + func = animator->func;
> + data = animator->data;
> + _ecore_unlock();
> + ret = func(data);
> + _ecore_lock();
> +
> + if (!ret)
>{
>   animator->delete_me = EINA_TRUE;
>   animators_delete_me++;
> @@ -136,18 +146,19 @@
> EAPI Ecore_Animator *
> ecore_animator_add(Ecore_Task_Cb func, const void *data)
> {
> -   Ecore_Animator *animator;
> +   Ecore_Animator *animator = NULL;
>
> -   ECORE_MAIN_LOOP_ASSERT();
> -
> -   if (!func) return NULL;
> +   _ecore_lock();
> +   if (!func) goto unlock;
>animator = calloc(1, sizeof(Ecore_Animator));
> -   if (!animator) return NULL;
> +   if (!animator) goto unlock;
>ECORE_MAGIC_SET(animator, ECORE_MAGIC_ANIMATOR);
>animator->func = func;
>animator->data = (void *)data;
>animators = (Ecore_Animator 
> *)eina_inlist_append(EINA_INLIST_GET(animators), EINA_INLIST_GET(animator));
>_begin_tick();
> +unlock:
> +   _ecore_unlock();
>return animator;
> }
>
> @@ -156,8 +167,7 @@
> {

Re: [E-devel] [Patch] Add XIM module for ecore_imf

[Sachiel]

2011/7/28 Carsten Haitzler :
> On Tue, 26 Jul 2011 13:57:05 -0300 Iván Briano (Sachiel) 
> said:
>
> and that's now set up with the scim, uim and iimf configs for input methods in
> e17. :)
>

YY!

Jeffdameth! Fix Everything so it works with SCIM!

>> 2011年7月26日13:52 Naruto TAKAHASHI :
>> > 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 :
>> >> On Sat, 23 Jul 2011 22:22:10 +0900 Jihoon Kim  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 
>> >>>
>> >>> > 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 :
>> >>> > > 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 :
>> >>> > >> 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 
>> >>> > >> 
>> >>> > 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 :
>> >>> > >>> > On 07/08/2011 03:15 PM, Naru

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[David Seikel]

On Thu, 28 Jul 2011 12:45:14 +1000 David Seikel 
wrote:

> On Wed, 27 Jul 2011 15:08:21 +0200 Cedric BAIL 
> wrote:
> 
> > On Wed, Jul 27, 2011 at 1:17 PM, Mike McCormack
> >  wrote:
> > > This patch adds some level of thread safety to ecore.
> > > It does not add thread awareness (i.e. adding a timer from a
> > > thread will not wake a sleeping main loop).
> > 
> > So it will most of the time work, but in some racy case, not. Sounds
> > to me like this doesn't change much from the current behaviour. I
> > agree, it will work more often than previously, but still hidding
> > bug until it's to late.
> > 
> > > In my experience, developers either are ignorant of the problems
> > > of threads, or expect libraries to magically work with threads.
> > 
> > People should never use things they don't understand... and so few
> > people understand threads. Just one question, do they use
> > ecore_thread or there own stuff ?
> > 
> > > I understand that some people think that thread safety is not
> > > necessary, but IMO, the performance cost and complexity is easily
> > > outweighed by the benefit of meeting developer expectation.
> > 
> > You can't make it work sanely, how are you planning to synchronize
> > the rendering state with your request from a thread. It's just not
> > possible, you are adding stuff to make it work more often, but
> > that's not thread safety and will lead to more complex issue to
> > debug in the futur. I would prefer that we advocate the use of
> > ecore thread and use eina thread debugging property to prevent efl
> > call from outside of the main loop by either asserting, displaying
> > a backtrace or just spanking (stuff that could turned on and off at
> > compile time and help provide development build or production
> > build).
> > 
> > I clearly disagree on that patch going in (and I am still not
> > discussing the issue of performance here).
> 
> I agree with Cedric to disagree, purely on principle.  Er, meaning I
> disagree with this patch.
> 
> > > the performance cost and complexity is easily outweighed by the
> > > benefit of meeting developer expectation.
> 
> That's the slippery slope that lead to most of todays software being
> so bloated.
> 
> /me stops his early morning rant and gets breakfast.

OK, now that I'm awake, and had brekky...

Ah, thread SAFETY.  Some amount of thread safety is OK so long as it
does not impact on the other core values in general.  Speed and
lightness should be the hallmarks of EFL.  So long as those are
achieved, and it just happens to be thread safe to, then all is good.
Still should just tell people that thread safety is not guaranteed, and
hardly needed.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
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] New Server available / Suggestions

[Nicolas Aguirre]

2011/7/14 Michael Taubert :
> Hi list!
>
> It took a while, but with today I've got a new OBS instance running to 
> provide EFL packages for OpenSUSE 11.4/11.3.
>
> As I'm not that experienced RPM packager, I thought about adapting the kind 
> of packaging like in http://download.enlightenment.org/releases/RHEL6/x86_64/
> as long as it doesn't conflict with Suse's guidelines/specifications. 
> Currently I've just added the old packages to see wether it's building at all 
> or not.
>
> The primary use for these packages will be to provide OpenSUSE packages of 
> 'enna'. Well, at least for my private development efforts. And when I got a
> connection to the Packman OBS, or a local clone of their repository running. 
> I think that enna's lack of publicity depends on 'easy availability' and
> I couldn't find any pre-compiled package, some time ago. As it's the only 
> media center solution that runs on my Zotac MAG in a suitable performance, I 
> will
> spend some time in its development.
>
> I will update these packages on an occasional basis, but try to keep them 
> updated. So within the next few days I will update all packages to the latest
> releases that I can find at http://download.enlightenment.org/releases/.
>
> You can get the packages at http://repos.dev.4kit.de/
>
> What do you think?
>
> Regards
>
>
> --
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

I don't know if enna is working well with latest SVN changes neither
with the 1.0.1 stable release, but i would be happy to push your
patches and fix stuff if need.

Recently, I built Meego packages (which are also based on RPM ) with
the meego OBS. Maybe we could join efforts here.
https://build.pub.meego.com/project/repository_state?project=home%3Acaptianigloo&repository=MeeGo_Trunk_standard

I used .spec files present in efl packages as a start.

Regards,
Nicolas

-- 
Nicolas Aguirre
Mail: aguirre.nico...@gmail.com
Web: http://enna.geexbox.org
Blog: http://dev.enlightenment.fr/~captainigloo/

--
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] ecore: Add basic thread safety

[Vincent Torri]

On Thu, 28 Jul 2011, Mike McCormack wrote:

> On 07/28/2011 07:32 PM, Cedric BAIL wrote:
>
>> Maybe stable, but the rendered scene will not make sense and be highly
>> difficult to debug. So spank and point people to the right solution.
>
> This is ecore, not evas.  Adding timers from a thread makes sense to me.
>
> I'm not proposing this as a solution for Evas.  Perhaps adding a thread
> check is better there... I haven't looked at it closely.
>
>>> * nobody complained when I added checks to show that ecore calls are coming
>>>  from the same thread, even though the performance "impact" would be 
>>> comparable.
>>>  (See ECORE_MAIN_LOOP_ASSERT)
>>
>> Because if needed, we can turn it off without breaking application or
>> any behaviour. Something that was working with it on will work with it
>> off. It something that we could use in a development build and remove
>> from the production build without the need to worry about it at all.
>
> If you're worried about this, how about I add a function call that
> can set the _ecore_lock() and _ecore_unlock() functions.  If they are
> NULL, the won't be called.
>
> Also, if you worry so much about performance, please let me know what
> benchmarking you want done to show the overhead.
>
>> I thing that this will get confusing and people will introduce more
>> bug, because the barrier with thread safety will be blured, some
>> function call will work, some won't. At the end, I think you are
>> increasing the complexity of the EFL without any benefit, you will
>> have more and more complex code to debug (because every thing will not
>> be thread safe). I really am more for a macro that display a spank
>> with backtrace and do nothing in all efl function call (including
>> evas, edje and elementary), that point to Ecore_Thread documentation.
>> In fact halt of that code is already provided by eina, I can provide
>> it quickly if that feat your need. This will put the burden of the fix
>> on the developer and not you. They will know exactly where and how to
>> fix it.
>
> I have already added code to print warnings.  It helps, but the response is
> usually, "but why isn't EFL thread safe?"

tell them to read the preamble there :

http://docs.enlightenment.org/auto/ecore/Ecore_Main_Loop_Page.html

Vincent

>
> Adding thread safety means:
>
> * one whole class of API misuse and potential problems is gone
> * people who think they know what they're doing can use threads without
>  worrying that ecore is a source of problems
> * we offer the same features to 3rd parties as we want to use inside EFL.
>
> It's a bit hypocritical to say "Well, the EVAS code can use threads,
> because we're E-lite developers, but users of our API should never be able
> to use threads, and should get spanked for doing so."
>
> 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
>
>

--
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] #define in Edje

[The Rasterman]

On Mon, 18 Jul 2011 23:31:43 +0200 Andreas Volz  said:

do you have an example?

you mean:

#if A != 10
hello
#endif

or something else?

> Hello,
> 
> it seems the ! and != operator in #define macros in EDC aren't working.
> I tried various tests and only == was working nice.
> 
> Revision is 60268. Yes, a little old, but like to know if this bug is
> still in latest sources.
> 
> regards
>   Andreas
> 
> -- 
> Technical Blog 
> 
> --
> 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
> 


-- 
- 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] E SVN: bdilly IN trunk/elementary: doc doc/img/screenshots src/examples src/lib

[The Rasterman]

On Mon, 18 Jul 2011 14:08:14 -0300 Bruno Dilly  said:

yes! that's right! you nailed it. only thing that got me was the intial example
didnt use conformant at all and i had to read all the way to the bottom and get
example 02 to see it in use inside the code. 

may i suggest putting the 2nd example up at the start, THEN go dissect it
starting with the base, and making it "conformant".

> Hey people,
> 
> I've written an example of usage of elm_conformant, but I would be
> glad if somebody that developed it or that knows this widget better
> than I could check my example and see if there is some use more
> relevant to be cited / exemplified.
> 
> http://docs.enlightenment.org/auto/elementary/conformant_example.html
> 
> API documentation at:
> http://docs.enlightenment.org/auto/elementary/group__Conformant.html
> 
> Thanks in advance.
> 
> On Mon, Jul 18, 2011 at 11:00 AM, Enlightenment SVN
>  wrote:
> > Log:
> > Elementary: Conformant Documentation
> >
> >
> >
> > Author:       bdilly
> > Date:         2011-07-18 07:00:36 -0700 (Mon, 18 Jul 2011)
> > New Revision: 61479
> > Trac:         http://trac.enlightenment.org/e/changeset/61479
> >
> > Added:
> >  trunk/elementary/doc/img/screenshots/conformant_example_01.eps
> > trunk/elementary/doc/img/screenshots/conformant_example_01.png
> > trunk/elementary/doc/img/screenshots/conformant_example_02.eps
> > trunk/elementary/doc/img/screenshots/conformant_example_02.png
> > trunk/elementary/doc/img/screenshots/conformant_example_03.eps
> > trunk/elementary/doc/img/screenshots/conformant_example_03.png
> > trunk/elementary/doc/img/screenshots/conformant_example_04.eps
> > trunk/elementary/doc/img/screenshots/conformant_example_04.png
> > trunk/elementary/src/examples/conformant_example_01.c
> > trunk/elementary/src/examples/conformant_example_02.c Modified:
> > trunk/elementary/doc/examples.dox trunk/elementary/src/examples/Makefile.am
> > trunk/elementary/src/lib/Elementary.h.in
> > trunk/elementary/src/lib/elm_conform.c
> >
> > Modified: trunk/elementary/doc/examples.dox
> > ===
> > --- trunk/elementary/doc/examples.dox   2011-07-18 11:25:54 UTC (rev 61478)
> > +++ trunk/elementary/doc/examples.dox   2011-07-18 14:00:36 UTC (rev 61479)
> > @@ -2189,6 +2189,79 @@
> >  */
> >
> >  /**
> > + * @page conformant_example Conformant Example.
> > + *
> > + * In this example we'll explain how to create applications to work
> > + * with illume, considering space required for virtual keyboards.
> > + *
> > + * Illume is a module for Enlightenment that modifies the user interface
> > + * to work cleanly and nicely on a mobile device. It has support for
> > + * virtual keyboard, among other nice features.
> > + *
> > + * Let's start creating a very simple window with a vertical box
> > + * with multi-line entry between two buttons.
> > + * This entry will expand filling all space on window not used by buttons.
> > + *
> > + * @dontinclude conformant_example_01.c
> > + * @skipline elm_main
> > + * @until }
> > + *
> > + * For information about how to create windows, boxes, buttons or entries,
> > + * look for documentation for these widgets.
> > + *
> > + * It will looks fine when you don't need a virtual keyboard, as you
> > + * can see on the following image:
> > + *
> > + * @image html screenshots/conformant_example_01.png
> > + * @image latex screenshots/conformant_example_01.eps
> > + *
> > + * But if you call a virtual keyboard, the window will resize, changing
> > + * widgets size and position. All the content will shrink.
> > + * The window will look like this:
> > + *
> > + * @image html screenshots/conformant_example_02.png
> > + * @image latex screenshots/conformant_example_02.eps
> > + *
> > + * If you don't want such behaviour, you
> > + * will need a conformant to account for space taken up by the indicator,
> > + * virtual keyboard and softkey windows.
> > + *
> > + * In this case, using the conformant in a proper way, you will have
> > + * a window like the following when the virtual keyboard is hidden:
> > + *
> > + * @image html screenshots/conformant_example_03.png
> > + * @image latex screenshots/conformant_example_03.eps
> > + *
> > + * As you can see, it guess the space that will be required by the
> > keyboard.
> > + * Verify how perfectly it fits when keyboard is visible:
> > + *
> > + * @image html screenshots/conformant_example_04.png
> > + * @image latex screenshots/conformant_example_04.eps
> > + *
> > + * So, let's study each step required to transform our initial example on
> > + * the second one.
> > + *
> > + * First of all, we need to set the window as an illume conformant window:
> > + * @dontinclude conformant_example_02.c
> > + * @skipline elm_win_conformant_set
> > + *
> > + * Next, we'll add a conformant widget, and set it to resize with the
> > window,
> > + * instead of the box.
> > + * @skipline conform
> > + * @until evas_object_show
> > + *
> > + * Finally, we'll set the

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[Mike McCormack]

On 07/28/2011 07:32 PM, Cedric BAIL wrote:

> Maybe stable, but the rendered scene will not make sense and be highly
> difficult to debug. So spank and point people to the right solution.

This is ecore, not evas.  Adding timers from a thread makes sense to me.

I'm not proposing this as a solution for Evas.  Perhaps adding a thread
check is better there... I haven't looked at it closely.

>> * nobody complained when I added checks to show that ecore calls are coming
>>  from the same thread, even though the performance "impact" would be 
>> comparable.
>>  (See ECORE_MAIN_LOOP_ASSERT)
> 
> Because if needed, we can turn it off without breaking application or
> any behaviour. Something that was working with it on will work with it
> off. It something that we could use in a development build and remove
> from the production build without the need to worry about it at all.

If you're worried about this, how about I add a function call that
can set the _ecore_lock() and _ecore_unlock() functions.  If they are
NULL, the won't be called.

Also, if you worry so much about performance, please let me know what
benchmarking you want done to show the overhead.

> I thing that this will get confusing and people will introduce more
> bug, because the barrier with thread safety will be blured, some
> function call will work, some won't. At the end, I think you are
> increasing the complexity of the EFL without any benefit, you will
> have more and more complex code to debug (because every thing will not
> be thread safe). I really am more for a macro that display a spank
> with backtrace and do nothing in all efl function call (including
> evas, edje and elementary), that point to Ecore_Thread documentation.
> In fact halt of that code is already provided by eina, I can provide
> it quickly if that feat your need. This will put the burden of the fix
> on the developer and not you. They will know exactly where and how to
> fix it.

I have already added code to print warnings.  It helps, but the response is
usually, "but why isn't EFL thread safe?"

Adding thread safety means:

* one whole class of API misuse and potential problems is gone
* people who think they know what they're doing can use threads without 
  worrying that ecore is a source of problems
* we offer the same features to 3rd parties as we want to use inside EFL.

It's a bit hypocritical to say "Well, the EVAS code can use threads, 
because we're E-lite developers, but users of our API should never be able
to use threads, and should get spanked for doing so."

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] [Patch] Add XIM module for ecore_imf

[The Rasterman]

On Tue, 26 Jul 2011 13:57:05 -0300 Iván Briano (Sachiel) 
said:

and that's now set up with the scim, uim and iimf configs for input methods in
e17. :)

> 2011年7月26日13:52 Naruto TAKAHASHI :
> > 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 :
> >> On Sat, 23 Jul 2011 22:22:10 +0900 Jihoon Kim  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 
> >>>
> >>> > 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 :
> >>> > > 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 :
> >>> > >> 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 
> >>> > 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 :
> >>> > >>> > 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 

Re: [E-devel] [Announcement] elm_genlist_item_update will be removed from elm_genlist_item_data.

[The Rasterman]

On Thu, 21 Jul 2011 17:06:29 +0900 Daniel Juyung Seo 
said:

yay! :) (well i didnt get to say yes before u did it, but i'm happy its now
done)

> This patch is committed.
> Please refer this information if you use elm_genlist_item_data_set().
> http://trac.enlightenment.org/e/changeset/61546
> 
> Daniel Juyung Seo (SeoZ)
> 
> 
> On Thu, Jul 21, 2011 at 1:56 AM, Daniel Juyung Seo 
> wrote:
> > Dear all, I will commit this patch in 24 hours.
> > So please be prepared if you're using elm_genlist_item_data_set() API.
> > Thank you.
> >
> > Daniel Juyung Seo (SeoZ)
> >
> > On Mon, Jul 18, 2011 at 9:31 AM, Daniel Juyung Seo 
> > wrote:
> >> Oh this mail was sent while I was writing it up :(
> >> So again...
> >>
> >> Dear all, I am going to fix genlist API.
> >> And I feel like I need to announce this before I commit the code
> >> because this will break some application's behavior.
> >>
> >> [What?]
> >>    - Removal of elm_genlist_item_update() from elm_genlist_item_data_set()
> >> API.
> >>
> >> [When?]
> >>    - Very soon. In a week?
> >>
> >> [Description]
> >>    - Currently, elm_genlist_item_data_set() API calls
> >> elm_genlist_item_update() API internally.
> >> This causes unwanted realize of items. Some applications may need it
> >> but others are not.
> >> So I removed automatic item update from that API. If you want to
> >> update item after setting data, you need to call
> >> elm_genlist_item_update() API explicitly.
> >>
> >> Thanks.
> >> Daniel Juyung Seo (SeoZ)
> >>
> >>
> >> Index: elm_genlist.c
> >> ===
> >> --- elm_genlist.c       (revision 61455)
> >> +++ elm_genlist.c       (working copy)
> >> @@ -4777,9 +4777,9 @@ elm_genlist_item_del(Elm_Genlist_Item *it)
> >>  * Set the data item from the genlist item
> >>  *
> >>  * This set the data value passed on the elm_genlist_item_append() and
> >> - * related item addition calls. This function will also call
> >> - * elm_genlist_item_update() so the item will be updated to reflect the
> >> - * new data.
> >> + * related item addition calls. This function will not call
> >> + * elm_genlist_item_update() anymore. So call elm_genlist_item_update()
> >> + * manually only when it's needed.
> >>  *
> >>  * @param it The item
> >>  * @param data The new data pointer to set
> >> @@ -4792,7 +4792,6 @@ elm_genlist_item_data_set(Elm_Genlist_Item *it,
> >>  {
> >>   ELM_WIDGET_ITEM_WIDTYPE_CHECK_OR_RETURN(it);
> >>   elm_widget_item_data_set(it, data);
> >> -   elm_genlist_item_update(it);
> >>  }
> >>
> >>
> >> On Mon, Jul 18, 2011 at 9:27 AM, Daniel Juyung Seo 
> >> wrote:
> >>> Dear all, I am going to fix genlist API.
> >>> And I feel like I need to announce this before I commit the code
> >>> because this will break some application's behavior.
> >>>
> >>> [What to Change]
> >>> I am going to remove elm_genlist_item_update() from
> >>> elm_genlist_item_data_set() API soon.
> >>>
> >>> Currently, elm_genlist_item_data_set() API calls
> >>> elm_genlist_item_update() API internally.
> >>>
> >>>
> >>> Index: elm_genlist.c
> >>> ===
> >>> --- elm_genlist.c       (revision 61455)
> >>> +++ elm_genlist.c       (working copy)
> >>> @@ -4777,9 +4777,9 @@ elm_genlist_item_del(Elm_Genlist_Item *it)
> >>>  * Set the data item from the genlist item
> >>>  *
> >>>  * This set the data value passed on the elm_genlist_item_append() and
> >>> - * related item addition calls. This function will also call
> >>> - * elm_genlist_item_update() so the item will be updated to reflect the
> >>> - * new data.
> >>> + * related item addition calls. This function will not call
> >>> + * elm_genlist_item_update() anymore. So call elm_genlist_item_update()
> >>> + * manually only when it's needed.
> >>>  *
> >>>  * @param it The item
> >>>  * @param data The new data pointer to set
> >>> @@ -4792,7 +4792,6 @@ elm_genlist_item_data_set(Elm_Genlist_Item *it,
> >>>  {
> >>>    ELM_WIDGET_ITEM_WIDTYPE_CHECK_OR_RETURN(it);
> >>>    elm_widget_item_data_set(it, data);
> >>> -   elm_genlist_item_update(it);
> >>>  }
> >>>
> >>
> >
> 
> --
> 5 Ways to Improve & Secure Unified Communications
> Unified Communications promises greater efficiencies for business. UC can 
> improve internal communications as well as offer faster, more efficient ways
> to interact with customers and streamline customer service. Learn more!
> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> ___
> 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?   Slash

Re: [E-devel] E SVN: glima IN trunk/elementary: doc doc/img/screenshots src/examples src/lib

[The Rasterman]

On Fri, 15 Jul 2011 11:06:59 -0300 Gustavo Lima Chaves 
said:

1. elm_fileselector_is_save_set() not borken... BUT elm_fileselector_is_save_get
() was. fixed. at least elementary_test works and enables/disables entry (when
disabled i cant type in it).

2. elm_fileselector_expandable_set - CEDRIC BROKE THIS when he added EIO. works
without EIO. :) he promises to fix it all properly! :) (don't you cedric). :)

> * Enlightenment SVN  [2011-07-15 07:02:54 -0700]:
> 
> > Log:
> > [elementary] Documenting/exemplifying file selector
> >widget.
> 
> I remember having corrected at least one of the issues reported below for
> file selectors, but it's always b0rked again :/
> 
> No time to fix it this time, so... have fun.
> 
> >   
> >   
> > 
> > Author:   glima
> > Date: 2011-07-15 07:02:54 -0700 (Fri, 15 Jul 2011)
> > New Revision: 61401
> > Trac: http://trac.enlightenment.org/e/changeset/61401
> > 
> > Added:
> >   trunk/elementary/doc/img/screenshots/fileselector_example.eps
> > trunk/elementary/doc/img/screenshots/fileselector_example.png
> > trunk/elementary/src/examples/fileselector_example.c Modified:
> > trunk/elementary/doc/examples.dox trunk/elementary/src/examples/Makefile.am
> > trunk/elementary/src/lib/Elementary.h.in
> > trunk/elementary/src/lib/elc_fileselector.c 
> > 
> > Modified: trunk/elementary/doc/examples.dox
> > ===
> > --- trunk/elementary/doc/examples.dox   2011-07-15 13:54:39 UTC (rev
> > 61400) +++ trunk/elementary/doc/examples.dox2011-07-15 14:02:54 UTC
> > (rev 61401) @@ -34,6 +34,8 @@
> >   * @ref clock_example
> >   *
> >   * @ref flipselector_example
> > + *
> > + * @ref fileselector_example
> >   */
> >  
> >  /**
> > @@ -1473,6 +1475,79 @@
> >   */
> >  
> >  /**
> > + * @page fileselector_example File selector widget example
> > + *
> > + * This code places two Elementary file selector widgets on a window.
> > + * The one on the left is layouting file system items in a @b list,
> > + * while the the other is layouting them in a @b grid.
> > + *
> > + * The one having the majority of hooks of interest is on the left,
> > + * which we create as follows:
> > + * @dontinclude fileselector_example.c
> > + * @skip first file selector
> > + * @until object_show
> > + *
> > + * Note that we enable custom edition of file/directory selection, via
> > + * the text entry it has on its bottom, via
> > + * elm_fileselector_is_save_set(). It starts with the list view, which
> > + * is the default, and we make it not expandable in place
> > + * (elm_fileselector_expandable_set()), so that it replaces its view's
> > + * contents with the current directory's entries each time one
> > + * navigates to a different folder.  For both of file selectors we are
> > + * starting to list the contents found in the @c "/tmp" directory
> > + * (elm_fileselector_path_set()).
> > + *
> > + * Note the code setting it to "grid mode" and observe the differences
> > + * in the file selector's views, in the example. We also hide the
> > + * second file selector's Ok/Cancel buttons -- since it's there just
> > + * to show the grid view (and navigation) -- via
> > + * elm_fileselector_buttons_ok_cancel_set().
> > + *
> > + * The @c "done" event, which triggers the callback below
> > + * @dontinclude fileselector_example.c
> > + * @skip 'done' cb
> > + * @until }
> > + * will be called at the time one clicks the "Ok"/"Cancel" buttons of
> > + * the file selector (on the left). Note that it will print the path
> > + * to the current selection, if any.
> > + *
> > + * The @c "selected" event, which triggers the callback below
> > + * @dontinclude fileselector_example.c
> > + * @skip bt = 'selected' cb
> > + * @until }
> > + * takes place when one selects a file (if the file selector is @b not
> > + * under folders-only mode) or when one selects a folder (when in
> > + * folders-only mode). Experiment it by selecting different file
> > + * system entries.
> > + *
> > + * What comes next is the code creating the three check boxes and two
> > + * buttons below the file selector in the right. They will exercise a
> > + * bunch of functions on the file selector's API, for the instance on
> > + * the left. Experiment with them, specially the buttons, to get the
> > + * difference between elm_fileselector_path_get() and
> > + * elm_fileselector_selected_get().
> > + *
> > + * Finally, there's the code adding the second file selector, on the
> > + * right:
> > + * @dontinclude fileselector_example.c
> > + * @skip second file selector
> > + * @until object_show
> > + *
> > + * Pay attention to the code setting it to "grid mode" and observe the
> > + * differences in the file selector's views, in the example. We also
> > + * hide the second file selector's Ok/Cancel buttons -- since it's
> > + * there just to show the grid view (and navigation) -- via
> > + * elm_fileselector_buttons_ok_cancel_set().
> > + *
> > + * See the full @re

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[Cedric BAIL]

On Thu, Jul 28, 2011 at 7:20 AM, Mike McCormack
 wrote:
> On 07/27/2011 10:08 PM, Cedric BAIL wrote:
>> So it will most of the time work, but in some racy case, not. Sounds
>> to me like this doesn't change much from the current behaviour. I
>> agree, it will work more often than previously, but still hidding bug
>> until it's to late.
>
> It is a change it goal.  The goal will be to make ecore calls thread safe,
> and any non-thread safe behavior is a bug.
>
>> People should never use things they don't understand... and so few
>> people understand threads. Just one question, do they use ecore_thread
>> or there own stuff ?
>
> I disagree with "people should never use things they don't understand".
>
> The whole point of a library or any other programming abstraction is
> to hide details and save people reimplementing these things over and over
> themselves.
>
> Some developers in Samsung use ecore_thread, and some don't.  Honestly,
> ECORE_MAIN_LOOP_ASSERT has shown up quite a few problems with code.
> Though the majority of developers understand that EFL code should be
> single threaded, there are still many crashes due to threading issues.
> I think EFL will be seen as "more stable" if it is thread safe... thus
> these patches.

Maybe stable, but the rendered scene will not make sense and be highly
difficult to debug. So spank and point people to the right solution.
If you try to avoid segv by making code that are buggy almost working
in most case, you are trying to hide issue and they will bite you
harder when they come back. I think we should display error message
that people do understand well and that point them to where they
should fix their code and how they should fix it. And I am sure we can
provide such a warning.

>> You can't make it work sanely, how are you planning to synchronize the
>> rendering state with your request from a thread. It's just not
>
> Let's stick to technical stuff rather than abstract ideas like sanity.
>
> I'm only talking about ecore here.  Step by step... (Raster has big plans
> for the rendering engine involving threads.)

As far as I understand raster plan for rendering, it doesn't involve
the user api of evas at all. It will continue to be a seriealised list
of function call from the same main thread, then something will
trigger evas_render and compute what is needed for doing the rendering
asynchronously, before waking up all the rendering thread and getting
out of evas_render and back to the application logique. And if you
want you can put all this call in another thread, but it will always
require to come from the same thread or they will never be any
synchronization of the object state before entering the rendering
state.

> If the code is lacking in one area or the other, please point it out.
> (Actually, some big bits, like locks around the idlers are missing from
> the patch I sent.)

See my answer to gustavo if you want something that work in all case.

>> I clearly disagree on that patch going in (and I am still not
>> discussing the issue of performance here).
>
> Well three points:
>
> * nobody complained when I added checks to show that ecore calls are coming
>  from the same thread, even though the performance "impact" would be 
> comparable.
>  (See ECORE_MAIN_LOOP_ASSERT)

Because if needed, we can turn it off without breaking application or
any behaviour. Something that was working with it on will work with it
off. It something that we could use in a development build and remove
from the production build without the need to worry about it at all.

> * given that SMP is widely available these days, I would think that
>  enabling simple thread based programming could dramatically improve
>  performance of some code.

Agreed, that's why we have Ecore_Thread in Ecore (stuff that I added)

> * I will provide a way to switch off thread safety at build time

That wouldn't help, because you will break application. There is no
way to have a development build and a production build with that kind
of feature, either you have only one application in your system and
you know that it doesn't require Ecore to be thread safe and you can
turn it off, or you just can't turn this feature off.

> Right now my thoughts are:
>
> * support single main loop only
> * add support for waking the main loop when timers, fds, etc. are added

I thing that this will get confusing and people will introduce more
bug, because the barrier with thread safety will be blured, some
function call will work, some won't. At the end, I think you are
increasing the complexity of the EFL without any benefit, you will
have more and more complex code to debug (because every thing will not
be thread safe). I really am more for a macro that display a spank
with backtrace and do nothing in all efl function call (including
evas, edje and elementary), that point to Ecore_Thread documentation.
In fact halt of that code is already provided by eina, I can provide
it quickly if that feat your need. This wi

Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_x/xcb

[The Rasterman]

On Fri, 15 Jul 2011 07:40:20 +0200 (CEST) Vincent Torri 
said:

> 
> 
> On Fri, 15 Jul 2011, Carsten Haitzler (The Rasterman) wrote:
> 
> > On Thu, 14 Jul 2011 12:14:05 -0400 Christopher Michael
> >  said:
> >
> >> On 07/14/11 12:10, Vincent Torri wrote:
> >>>
> >>>
> >>> On Thu, 14 Jul 2011, Christopher Michael wrote:
> >>>
>  On 07/14/11 11:58, Vincent Torri wrote:
> >
> >
> > On Thu, 14 Jul 2011, Christopher Michael wrote:
> >
> >> On 07/14/11 11:46, Vincent Torri wrote:
> >>>
> >>> Hey
> >>>
> >>> what about killing completely xlib, now ?
> >>>
> >>> Vincent
> >>>
> >> Soon ;) XCB stuff still needs more work before that can happen tho.
> >> Granted, I do have E fully working here (locally) with the new XCB
> >> stuff, but there are still so things/issues to iron out (opengl, intl
> >> support, etc).
> >
> > i'm still a bit surprised that you made ecore_xcb completely async and
> > event-driven (you told me that on IRC), as I know that there could be
> > some problems if you keep the API that is in Ecore_X.h
> >
> > Vincent
> >
>  Well, the event-driven part was fairly easy. By it's nature, xcb
>  itself is async (to an extent). Now, having said that, the ecore_x
>  (xcb) stuff could be a bit 'more' async wrt some things. We could do
>  caching of cookies/requests/replies, etc, etc and improve things in
>  some areas.
> >>>
> >>> ok, so *ecore_xcb* is not async. That is, you didn't suppress the round
> >>> trips.
> >>>
> >>> Vincent
> >>>
> >> Not yet. I focused first on just getting everything working correctly ;)
> >> When all the major issues are flushed out, then we can move on to adding
> >> more 'async' behavior (round-trips, caching, etc).
> >
> > i smell a misunderstanding of xcb here.. and xlib. xlib *IS* async. x
> > PROTOCOL is async. in that there are a LOT of calls to xlib do NOT send a
> > request and WAIt for a reply. xcreatewindow doesnt. xsetwindowattributes
> > doesnt. xconfigurewindow doesnt, xputimage doesnt... but other calls do -
> > xgetwindowattributes, xinternatom, etc. - they REQUIRE a reply from x in
> > order to return. xcb simply exposes the lower level x protocol more
> > than xlib does so it ALLOWS you to make these sync calls become async.. *IF*
> > you use the calls very differently to how you did before. basically an xcb
> > based ecore_x vs xlib has basically no benefits compared to xlib with
> > regards to async except in a few rare internal places (eg on init). what
> > needs to change is the ecore_x calls need to allow more async behavior.
> > that means making sync calls that batch a lot of requests and replies into
> > a single round trip, or that allow for completely event-driven replies (eg
> > you xgetwindowproperty AND the property reply comes in some time later as an
> > event). event driven means major changes in code that uses ecore_x as the
> > code cannot get the data then do its thing. it has to start a get and queue
> > it deferring the "do its thing" until the reply comes in. this has a knock
> > on effect to all other code logic that was dependant on the reply.
> >
> > total async execution is the holy grail and "best possible result". it is
> > also the hardest.
> 
> And i'm convinced that it is not possible, without memory (maybe big) 
> loss, with the Ecore_X API. To have ecore_x really async and event driven, 
> you have to poll each replies on the fd. So, if e17 queries, at different 
> time and place, in that order:
> 
> GetWindowAttributes of window1
> GetAtomName of atom a
> GetWindowAttributes of window2
> 
> The fd is awaken, xcb_poll_for_reply is called, replies are sent in that 
> order (X assures that) but it's not necessarly the case for the events. If 
> you just use the cookie, then event won't be able to know which window 
> (window1 or window2) correspond to the event. So you have to allocate / 
> free memory to store more informations + a lot of code to detect which 
> object (window1 or window2) is associated to the event you have. And 
> then, you lose a big interest of xcb. I'm not even sure it's possible, 
> btw.

it is possible. it's just hard. for the above example, you COULD deliver all
results as events and its the clients job of matching up the events with the
data that wanted to store the results. it's hard though.

> > the middle ground is a "much less round trips" world where, for
> > example, when e has to manage a new window, it queues every property fetch
> > and then does a single round-trip wait for al the replies, as opposed to a
> > round trip per property (it may have to fetch between 0 and 100 properties
> > for a new window).
> 
> just init is almost 200 properties. On my computer, ecore_x_init xlib was 
> 6 times slower than ecore_x_init xcb

yes - thats where doing batch fetch and batch reply helps a lot. u can do 1
round trip instead of 200.

> > this requires ecore_x to expose enough handles/f

Re: [E-devel] [Patch] A fault stride value in eng_image_stride_get of gl backend

[The Rasterman]

On Fri, 15 Jul 2011 02:21:47 + (GMT) 우승수  said:

someone already snuck this in svn. :)

> 
>Dear all,
>eng_image_stride_get() of gl backend get fault stride value.
> 
>In case of using dynamic image, it get from dyn.w*4.
> 
>But,  dyn.stride was already got from secsym_eglGetImageAttribSEC() in
>_pool_tex_dynamic_new().
> 
>dyn.stride can be changed according to DDK.
> 
>So, the stride needs to get from dyn.stride.
> 
>Please find enclosed file.
>Thanks.
> 
>[cid:BEI0XT4NZ5JE@namo.co.kr]
> 
>[SeenTimeChecker?
> do=29ca0e02be538846cd3c5e93b827b3496242e3beb47ff168a85d7c0c
> af7791632fe50af216eefd44d1b17ce7cdd50431f1bc9e894f4f495bed2705d6268c6898dd8a
> aa5ed8b0e8e4326bbdfb2ea96a2fcf878f9a26ce15a0]


-- 
- 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] New Server available / Suggestions

[The Rasterman]

On Thu, 14 Jul 2011 20:43:44 +0200 Michael Taubert 
said:

i see no problem with doing this. is there anything we can do to help?

> Hi list!
> 
> It took a while, but with today I've got a new OBS instance running to
> provide EFL packages for OpenSUSE 11.4/11.3.
> 
> As I'm not that experienced RPM packager, I thought about adapting the kind
> of packaging like in http://download.enlightenment.org/releases/RHEL6/x86_64/
> as long as it doesn't conflict with Suse's guidelines/specifications.
> Currently I've just added the old packages to see wether it's building at all
> or not.
> 
> The primary use for these packages will be to provide OpenSUSE packages of
> 'enna'. Well, at least for my private development efforts. And when I got a
> connection to the Packman OBS, or a local clone of their repository running.
> I think that enna's lack of publicity depends on 'easy availability' and I
> couldn't find any pre-compiled package, some time ago. As it's the only media
> center solution that runs on my Zotac MAG in a suitable performance, I will
> spend some time in its development.
> 
> I will update these packages on an occasional basis, but try to keep them
> updated. So within the next few days I will update all packages to the latest
> releases that I can find at http://download.enlightenment.org/releases/.
> 
> You can get the packages at http://repos.dev.4kit.de/
> 
> What do you think?
> 
> Regards
> 
> 
> --
> AppSumo Presents a FREE Video for the SourceForge Community by Eric 
> Ries, the creator of the Lean Startup Methodology on "Lean Startup 
> Secrets Revealed." This video shows you how to validate your ideas, 
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> ___
> 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] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib

[Tom Hacohen]

On 28/07/11 11:29, Carsten Haitzler (The Rasterman) wrote:
> i think it needs to handle mirroring. things like buttons for control (back) 
> go
> in the top and may be on the left normally, but in a mirrored case.. i guess
> should be on the right. so yes - it needs mirroring support for our
> arabic/hebrew/etc. RTL friends. :)
>
>

 From you description it sounds like it does. :)

--
Tom.

--
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] epp does not remove \r at the end of lines

[The Rasterman]

On Sat, 16 Jul 2011 10:39:10 +0200 (CEST) Vincent Torri 
said:

> 
> 
> On Sat, 16 Jul 2011, Ulrich Eckhardt wrote:
> >
> > "diff" tries to be convenient, just like many text-based tools, so it hides
> > different line-endings from you. "hexdump" works with bytes and doesn't try
> > to make things easy for text files but gives you the whole truth.
> 
> so if i run
> 
> hexdump -C file1 > file1.hd
> hexdump -C file2 > file2.hd
> 
> what should i do, next ?

well u want to look at the input bytes vs output - find the CRLF bytes and see
what input has and what output has. has the function stripped the CRLF to LF?

-- 
- 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] epp does not remove \r at the end of lines

[The Rasterman]

On Thu, 14 Jul 2011 16:36:58 +0200 (CEST) Vincent Torri 
said:

dos2unix is called on the WHOLE file... all the data in the input file (which
is read to memory) is stripped of \r in \r\n sequences.

> 
> Hey,
> 
> raster added a 'dos2unix' function in epp to remove trailing \r (rev 
> 59799). However, when i compare the files generated by epp on Windows and 
> linux (just after line 751 of edje_cc_parse.c), they have a different size 
> (windows one is bigger). When I run the dos2unix tool I have on the 
> windows file, then there is no difference between the unix and window file 
> anymore.
> 
> I have looked at the dos2unix function and i don't see any problem.
> 
> So, is the dos2unix function called everywhere it has to ?
> 
> Vincent
> 
> --
> AppSumo Presents a FREE Video for the SourceForge Community by Eric 
> Ries, the creator of the Lean Startup Methodology on "Lean Startup 
> Secrets Revealed." This video shows you how to validate your ideas, 
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> ___
> 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] epp does not remove \r at the end of lines

[The Rasterman]

On Fri, 15 Jul 2011 23:28:06 +0200 Ulrich Eckhardt  said:

> On Thursday 14 July 2011 16:36:58 Vincent Torri wrote:
> > raster added a 'dos2unix' function in epp to remove trailing \r (rev
> > 59799).
> 
> As I understand it, it converts '\r\n' to '\n' in a string.
> 
> 
> > However, when i compare the files generated by epp on Windows and
> > linux (just after line 751 of edje_cc_parse.c), they have a different size
> > (windows one is bigger). When I run the dos2unix tool I have on the
> > windows file, then there is no difference between the unix and window file
> > anymore.
> 
> Where exactly is the difference in the file? Does it have multiple lines at 
> all? Try running hexdump/hd on it to get a bytewise comparison.
> 
> 
> There is a problem with the dos2unix function, it reads beyond the supplied 
> buffer if the last byte is a '\r'. I don't think this is actually a problem, 

intentional. indeed as u noticed we alloc an extra 2 bytes. 1 is for the 0 byte
delimiter of the string.. the other.. just for giggles :)

> because the allocated buffer is two bytes (why two?) larger than the file's 
> size. Also, it allocates another, even larger buffer although it can only 
> shrink the required length. I'm not sure if any combination of events there 
> can lead to any weirdness. Just to be sure, can you try the attached patch.
> 
> 
> Cheers!
> 
> 
> Uli


-- 
- 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] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib

[The Rasterman]

On Thu, 14 Jul 2011 10:26:10 +0900 ChunEon Park said:

yes docs! with auto-generated screenshots (scripted/makefile) from example code
and examples... :)

> Ok, will soon.
> 
> Let's run together for the best moment!
>  -Regards, Hermet-
>  
> -Original Message-
> From: "Daniel Juyung Seo" 
> To: "ChunEon Park"
> Cc: enlightenment-devel@lists.sourceforge.net;
> enlightenment-...@lists.sourceforge.net Sent: 11-07-14(목) 09:37:25
> Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images
> data/themes src/bin src/libWe also need a SOLID DOCUMENTATION! Thanks.
> Daniel Juyung Seo (SeoZ)
> 2011/7/13 ChunEon Park :
> > Dear,
> > I added a new widget naviframe.
> > This widget is for application's view manager such as elm_pager.
> > But has optional functions more for users convenience.
> > Not completed yet for decorations. but basic frame is completed.
> > Do someone review it's APIs and functionalities?
> > 
> > Let's run together for the best moment!
> > -Regards, Hermet-
> >
> > -Original Message-
> > From: "Enlightenment SVN"
> > To: enlightenment-...@lists.sourceforge.net
> > Cc:
> > Sent: 11-07-13(수) 13:21:50
> > Subject: E SVN: hermet IN trunk/elementary: data/images data/themes src/bin
> > src/libLog: elementary/naviframe - added new widget.
> >
> > This widget is for application's view manager such as elm_pager
> > But has optional functions more for users convenience.
> > Not completed yet for decorations. but basic frame is completed.
> >
> > Need to have a review.
> >
> >
> > Author: hermet
> > Date: 2011-07-12 21:21:50 -0700 (Tue, 12 Jul 2011)
> > New Revision: 61313
> > Trac: http://trac.enlightenment.org/e/changeset/61313
> > Added:
> > trunk/elementary/data/images/icon_right_arrow.png
> > trunk/elementary/src/bin/test_naviframe.c
> > trunk/elementary/src/lib/elc_naviframe.c Modified:
> > trunk/elementary/data/themes/default.edc
> > trunk/elementary/src/bin/Makefile.am trunk/elementary/src/bin/test.c
> > trunk/elementary/src/lib/Elementary.h.in
> > trunk/elementary/src/lib/Makefile.am Property changes on:
> > trunk/elementary/data/images/icon_right_arrow.png
> > ___ Added:
> > svn:mime-type
> > + application/octet-stream
> > Modified: trunk/elementary/data/themes/default.edc
> > ===
> > --- trunk/elementary/data/themes/default.edc 2011-07-13 01:41:56 UTC (rev
> > 61312) +++ trunk/elementary/data/themes/default.edc 2011-07-13 04:21:50 UTC
> > (rev 61313) @@ -2970,6 +2970,193 @@
> > }
> > }
> > }
> > + group { name: "elm/button/base/naviframe/back_btn/default";
> > + images {
> > + image: "bt_base1.png" COMP;
> > + image: "bt_base2.png" COMP;
> > + image: "bt_hilight.png" COMP;
> > + image: "bt_shine.png" COMP;
> > + image: "bt_glow.png" COMP;
> > + image: "bt_dis_base.png" COMP;
> > + image: "bt_dis_hilight.png" COMP;
> > + image: "icon_left_arrow.png" COMP;
> > + }
> > + parts {
> > + part { name: "button_image";
> > + mouse_events: 1;
> > + description { state: "default" 0.0;
> > + min: 15 15;
> > + image {
> > + normal: "bt_base2.png";
> > + border: 7 7 7 7;
> > + }
> > + image.middle: SOLID;
> > + }
> > + description { state: "clicked" 0.0;
> > + inherit: "default" 0.0;
> > + image.normal: "bt_base1.png";
> > + }
> > + description { state: "disabled" 0.0;
> > + inherit: "default" 0.0;
> > + image {
> > + normal: "bt_dis_base.png";
> > + border: 4 4 4 4;
> > + }
> > + }
> > + }
> > + part { name: "prev_image";
> > + type: IMAGE;
> > + scale: 1;
> > + description { state: "default" 0.0;
> > + min: 30 30;
> > + max: 30 30;
> > + fixed: 1 1;
> > + align: 0.5 0.5;
> > + image.normal: "icon_left_arrow.png";
> > + }
> > + }
> > + part { name: "over1";
> > + mouse_events: 0;
> > + description { state: "default" 0.0;
> > + rel2.relative: 1.0 0.5;
> > + image {
> > + normal: "bt_hilight.png";
> > + border: 7 7 7 0;
> > + }
> > + }
> > + description { state: "disabled" 0.0;
> > + inherit: "default" 0.0;
> > + image {
> > + normal: "bt_dis_hilight.png";
> > + border: 4 4 4 0;
> > + }
> > + }
> > + }
> > + part { name: "over2";
> > + mouse_events: 1;
> > + repeat_events: 1;
> > + ignore_flags: ON_HOLD;
> > + description { state: "default" 0.0;
> > + image {
> > + normal: "bt_shine.png";
> > + border: 7 7 7 7;
> > + }
> > + }
> > + description { state: "disabled" 0.0;
> > + inherit: "default" 0.0;
> > + visible: 0;
> > + }
> > + }
> > + part { name: "over3";
> > + mouse_events: 1;
> > + repeat_events: 1;
> > + description { state: "default" 0.0;
> > + color: 255 255 255 0;
> > + image {
> > + normal: "bt_glow.png";
> > + border: 12 12 12 12;
> > + }
> > + fill.smooth : 0;
> > + }
> > + description { state: "clicked" 0.0;
> > + inherit: "default" 0.0;
> > + color: 255 255 255 255;
> > + }
> > + }
> 

Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib

[The Rasterman]

On Wed, 13 Jul 2011 10:17:41 +0300 Tom Hacohen
 said:

> On 13/07/11 10:15, ChunEon Park wrote:
> > Ok, i will check the ui-mirroring soon.
> 
> I'm not even sure it's needed, as I'm not sure exactly what's a part of 
> the widget, and what's not.
> 
> But from the code it seems there's not ui-mirroring handling (not to 
> mention, theme hook/scaling)...

i think it needs to handle mirroring. things like buttons for control (back) go
in the top and may be on the left normally, but in a mirrored case.. i guess
should be on the right. so yes - it needs mirroring support for our
arabic/hebrew/etc. RTL friends. :)


-- 
- 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