Re: [E-devel] segfault of edje_cc during compilation of elementary
On Sat, 23 Jul 2011 11:44:25 +0200 Tomas Cech tc...@suse.cz 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] elm cnp bugs remaining
On Sun, 24 Jul 2011 17:57:48 -0400 Mike Blumenkrantz m...@zentific.com 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] new APIs about page
On Mon, 25 Jul 2011 06:22:09 + (GMT) Jaehwan Kim jae.hwan@samsung.com 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] new APIs about page
2011/7/25 Jaehwan Kim jae.hwan@samsung.com: 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] [Patch] elm_diskselector
On Mon, 25 Jul 2011 21:25:36 +0900 cnook kimci...@gmail.com 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] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib
On Wed, 27 Jul 2011 09:02:56 +0900 ChunEon Parkher...@naver.com 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 Parklt;her...@naver.comgt; To: Gustavo Sverzut Barblt;barbi...@profusion.mobigt; Cc: Tom Hacohenlt;tom.haco...@partner.samsung.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-18(월) 14:16:44 Subject: RE: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib Ok, I will do. thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Gustavo Sverzut Barbierilt;barbi...@profusion.mobigt; To: Tom Hacohenlt;tom.haco...@partner.samsung.comgt; Cc: ChunEon Parklt;her...@naver.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-15(금) 02:38:42 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Thu, Jul 14, 2011 at 12:58 PM, Tom Hacohen lt;tom.haco...@partner.samsung.comgt; wrote: On 14/07/11 18:52, Gustavo Sverzut Barbieri wrote: 2011/7/13 ChunEon Parklt;her...@naver.comgt;: elm_naviframe_item_text_part_set/get() or something like that. - Yes. it looks not bad for me. But it will cause more mistakes of users since they should pass the part name, (I don't like it from that point of view although.) And some widgets have the item_label_set now. Need to keep the consistency if everyone agree with. Yes, Daniel is right and the current item_label_set() are more like unconverted legacy. They must be fixed and new APIs must be correct from start. Unfortunately, because those are not elm_widgets, calling elm_object_text_set won't work. We really need to find a solution to this one. Possibly another API that allows passing additional data? elm_object_text_subitem_set or something like that? check what we did for tooltips and others, they have some kind of interface in the items, if you follow you have generic functions to operate on them. but all in all I'd go for actual interfaces (in classes, not instances -- partial infra for Evas_Object is there, but lacks for generic items) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - 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...
On 29/07/11 03:37, Bruno Dilly wrote: On Thu, Jul 28, 2011 at 7:53 PM, Mike Blumenkrantz m...@zentific.com wrote: On Fri, 29 Jul 2011 00:38:50 +0200 Hugo Camboulive hugo.camboul...@gmail.com 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. I (and probably many others) suggested it many times before, raster is against, I don't remember why. -- 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] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib
in Elementary? I've not seen any regarding APIs. and can't not find. Could you give me a hint? Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Carsten Haitzlerlt;ras...@rasterman.comgt; To: ChunEon Parklt;her...@naver.comgt; Cc: enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-29(금) 15:50:46 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Wed, 27 Jul 2011 09:02:56 +0900 ChunEon Parklt;her...@naver.comgt; 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 Parklt;her...@naver.comgt; To: Gustavo Sverzut Barblt;barbi...@profusion.mobigt; Cc: Tom Hacohenlt;tom.haco...@partner.samsung.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-18(월) 14:16:44 Subject: RE: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib Ok, I will do. thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Gustavo Sverzut Barbierilt;barbi...@profusion.mobigt; To: Tom Hacohenlt;tom.haco...@partner.samsung.comgt; Cc: ChunEon Parklt;her...@naver.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-15(금) 02:38:42 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Thu, Jul 14, 2011 at 12:58 PM, Tom Hacohen lt;tom.haco...@partner.samsung.comgt; wrote: On 14/07/11 18:52, Gustavo Sverzut Barbieri wrote: 2011/7/13 ChunEon Parklt;her...@naver.comgt;: elm_naviframe_item_text_part_set/get() or something like that. - Yes. it looks not bad for me. But it will cause more mistakes of users since they should pass the part name, (I don't like it from that point of view although.) And some widgets have the item_label_set now. Need to keep the consistency if everyone agree with. Yes, Daniel is right and the current item_label_set() are more like unconverted legacy. They must be fixed and new APIs must be correct from start. Unfortunately, because those are not elm_widgets, calling elm_object_text_set won't work. We really need to find a solution to this one. Possibly another API that allows passing additional data? elm_object_text_subitem_set or something like that? check what we did for tooltips and others, they have some kind of interface in the items, if you follow you have generic functions to operate on them. but all in all I'd go for actual interfaces (in classes, not instances -- partial infra for Evas_Object is there, but lacks for generic items) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - 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] #define in Edje
Am Fri, 29 Jul 2011 00:12:30 +0300 schrieb 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.
Hm, as I said before. I had problems with clock module from darkness
theme:
if E17_PROFILE != HIRES_PDA E17_PROFILE != LOWRES_PDA
E17_PROFILE != MEDIUMRES_PDA
I tried various combinations. From my eyes defining some *_PDA doesn't
currently switch the timer to 10 sec. But I think this is what the
author liked. Then this is also wrong. But are you sure?
regards
Andreas
--
Technical Blog http://andreasvolz.wordpress.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 POLL
On Thu, Jul 28, 2011 at 20:17, Iván Briano (Sachiel) sachi...@gmail.com wrote: 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. I definitely agree with you. I'm used to go and read the code anyway. If we can't make a vote out of this proposition, then my vote goes to #2. -- Boris Faure -- 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
On Fri, Jul 29, 2011 at 03:24:35PM +0900, Carsten Haitzler wrote: On Sat, 23 Jul 2011 11:44:25 +0200 Tomas Cech tc...@suse.cz 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. :) Thanks for your comments. I made these modules not configurable in my spec file so I won't meet it again. Best regards, Tomas Cech Sleep_Walker -- 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] Fwd: [PATCH] ecore: Add basic thread safety
Oops, forgot to CC the ML. -- Forwarded message -- From: Cedric BAIL cedric.b...@free.fr Date: Thu, Jul 28, 2011 at 12:13 PM Subject: Re: [E-devel] [PATCH] ecore: Add basic thread safety To: Gustavo Sverzut Barbieri barbi...@profusion.mobi On Wed, Jul 27, 2011 at 9:18 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jul 27, 2011 at 10:08 AM, Cedric BAIL cedric.b...@free.fr wrote: On Wed, Jul 27, 2011 at 1:17 PM, Mike McCormack mj.mccorm...@samsung.com 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). Cedric, I disagree with you and agree with Mike. Let's face it, we pushed threads away for years, it did not help. People won't learn (precious time) and they'll just use it incorrectly or get away from EFL at all. Mike is only trying to minimize parts of the problem... and in an real world application there should be enough activity on the main thread to make this problem not happen at all. Alternatively we can have a FD on own own and write to it whenever we added stuff from worker threads. If you really want that feature, we should do it right. So use one Ecore_Pipe with lock around it on writing, and write a duplicate of the command to it when not in the main loop and call the command from the main loop. At least that would work in all case and wont trigger any bug. All in all I'd use the Evas rewrite Raster wants to do and think about it as well. I know it's a tremendous effort, but likely if we design things like that we can achieve always thread safe GUI. I'm not talking about locking all the paths and render immediately, we can take a simpler path to serialize access to each object and do the actual work from other threads. IMO the perfect solution would be: - PROCESS: image loading process, no loading would be done in the application process. Data would always be shared with shmem - THREAD: garbage collector defragmenting for our datatypes. - THREAD: evas rendering - THREAD: ecore mainloop Evas rendering will use multiple thread and not just one, it will also use multiple process and will get out of the main loop quickly. Given N applications we'd account as: (1 + N * 3) threads. Given stupidly cheap Linux threads this is not a performance impact. The benefits are clear: - application would never block to users - image data would be shared among applications (themes, etc) - we'd avoid memory fragmentation and most of the leaks Agreed, that's also how I see things (was planning to use Ecore_Thread in edje for garbage collection/free loop), but that doesn't put any requirement on the EFL to be thread safe. And that's my main point, take evas as an example, if you push to make it's call thread safe, and do an evas_object_move followed by an evas_object_resize. How are you sure that they the change will be synchronized and happen in the same frame ? You need to add some kind of synchronisation barrier explicitly in your code to be sure that all the object you wanted to update will be updated at the same time. And this should work on all thread at the same time, I don't see how you can make it work. From my point of view, if you want thread, use ecore_thread, we have yet some that can send feedback during their live to the main loop and simple worker one. I have started locally working on more complex use that can directly trigger a function call in the main loop or in any
Re: [E-devel] [PATCH] ecore: Add basic thread safety
On Fri, Jul 29, 2011 at 3:44 AM, Mike McCormack
mj.mccorm...@samsung.com wrote:
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).
Case 3, could be easily merged and done directly in
ecore_main_loop_thread_safe_call. Patch welcome, if I don't get to it
before anyone.
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.
Then take that pseudo example :
Eina_Bool _timer_in_main_loop(void *data)
{
;
free(data);
return 0;
}
void bad_idea()
{
tuttut = ecore_timer_add(unlucky, _timer_in_main_loop, something);
...;
if (bad_happen)
{
ecore_timer_del(tuttut);
free(something);
}
}
This code will work just fine in the main loop. Now in a thread it's
full of race condition and double free. Tell me how you can make it
work ? By trying to say, we are thread safe, you are just hidding more
and more the issue without solving it. So at the end, app will be less
stable and more difficult to debug. That's my point. Your patch isn't
fixing what it is advertising and I think it can't do it by design. C
is very different from Java, and is very difficult to make it thread
safe.
As far as I know, Cocoa, GTK, Qt and Win32 are not thread safe, and
nobody complain about that. It doesn't prevent anyone from writing
thousand of greate Cocoa appication (Maybe because they have GCD and
block and advertise it alot).
PS: Don't focus yet on performance cost, I didn't raise that point
yet, first we need something that do what it says it does before
trying any optimisation and we are far from that.
--
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
Re: [E-devel] Problem about the positon of candidate window in Ibus or SCIM
On Tue, 26 Jul 2011 21:20:58 +0900 Jihoon Kim jihoon48@samsung.com said: score! i took your stuff and made it work. with some BUTS... 1. doesnt work with scim xim bridge. scim seems to simply not respond no matter what you do. 2. it works with kinput2... so it IS doing proepr over the spot now... with kinput2. it might now work with nabi etc. - not sure. 3. i found that to make over the spot work u HAVE to provide a fontset or it wont. i just threw in fixed and presto. not pretty, but works. 4. i had to make it auto-detect scim vs kinput2 so it uses different preedit modes, i figured out the difference and it was the cursor value that scim doesnt support. (thus probably why the over-the-spot doesnt work as it needs cursor location). so it works now.. in svn :) Hey, raster. Like you told me, there is some problem that the candidate word window is located on the wrong position when ecore_imf works with xim immodule. To solve this problem, I've tried to make the patch file, but it does not work well at this moment. I've made this patch referring to gtk xim module. I've tested with GTK application, but GTK application also have same problem. This patch should be applied after applying the patch I sent (http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg33 889.html) If you have the XIM knowledge, would you please let me know the solution? -- - 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] Animation gif feature patch
On Tue, 26 Jul 2011 16:25:45 +0900 Jiyoun Park jy0703.p...@samsung.com said: i see chuneon's point. evas uses animated and elm anim. so either use animated or anim in both - i'd choose animated. :) can you just rename the elm calls and resend the patches? i'll review them apart from the name thing here: 1. documentation - way too little WAY too little. provide examples of the functions and how to use them in a small app 2.static Eina_Bool _evas_image_... and static Eina_Bool _evas_image_load_frame_... and static Eina_Bool _evas_image_load_fram... why no newline between retyurn type and function name? the other functions have it static Eina_Bool evas_image_load_file_data... too 3. you missed adding NULL to the generic, eet, psd, svg, and xpm loader structs i believe. (like you did to the others). :) can you fix the naming and the above and re-send the patches? :) 1. why do you think *_animated_* is not proper name? long character or grammar problem (word class? Other reason?) ? *_animated_* is familiar to me, and there is no place related with this in evas , so I want to keep this name. But If this name is wrong or not acceptable name generally , I will consider to change API name. 2. yes . I already have elm_icon_anim_available_get API 3. elm_icon_anim_set means I will use animation mode currently or later. Elm_icon_anim_play_set is for real play of image. Thanks. -Original Message- From: Daniel Juyung Seo [mailto:seojuyu...@gmail.com] Sent: Monday, July 25, 2011 11:43 PM To: ChunEon Park Cc: Jiyoun Park; enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] [Patch] Animation gif feature patch 1) Frankely, I don't like *_animated_* Agreed. Choose either animation or anim and apply it to evas_object_image and elm_icon. I prefer anim :) 2) Eina_Bool elm_icon_anim_get (const Evas_Object *obj) - elm_icon_anim_available_get ... elm_icon_anim_available_get is already in Jiyoun's patch. 3) API names are not clear. For me 2 names are confusing. elm_icon_anim_set() elm_icon_anim_play_set() What's anim mode and anim play mode? Maybe I'm missing some animation image concept. Thanks. Daniel Juyung Seo (SeoZ) On Mon, Jul 25, 2011 at 8:20 PM, ChunEon Park her...@naver.com wrote: Frankely, I don't like *_animated_* How about just animation or anim? evas_object_image_animation_available_get evas_object_image_animation_frame_get ... and this API also. Eina_Bool elm_icon_anim_get (const Evas_Object *obj) - elm_icon_anim_available_get ... Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Jiyoun Parklt;jy0703.p...@samsung.comgt; To: enlightenment-devel@lists.sourceforge.net Cc: Sent: 11-07-25(월) 17:18:22 Subject: [E-devel] [Patch] Animation gif feature patchHello. I modified animated gif feature code according Mike’s advise. Added api Eina_Bool evas_object_image_animated_get (const Evas_Object *obj) int evas_object_image_animated_frame_num_get (const Evas_Object *obj) Evas_Image_Animated_Loop_Hint evas_object_image_animated_loop_type_get (const Evas_Object *obj) int evas_object_image_animated_loop_count_get (const Evas_Object *obj) double evas_object_image_animated_frame_duration_get (const Evas_Object *obj, int start_frame, int fram_num) void evas_object_image_animated_frame_set (Evas_Object *obj, int frame_num) Eina_Bool elm_icon_anim_available_get (const Evas_Object *obj) Void elm_icon_anim_set (Evas_Object *obj, Eina_Bool anim) Eina_Bool elm_icon_anim_get (const Evas_Object *obj) void elm_icon_anim_play_set (Evas_Object *obj, Eina_Bool play) Eina_Bool elm_icon_anim_play_get (const Evas_Object *obj) Todo 1. optimization 2. Test case to test several files Test_icon.c is for elm icon test. Change test_icon.c in elementary/src/bin to this. Thanks. -- Jiyoun Park Mobile S/W Platform Lab DMC RD Center SAMSUNG ELECTRONICS CO. ,LTD TEL: +82-31-279-0619 Mobile: +82-10-9871-0703 jy0703.p...@samsung.com -- -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Magic Quadrant for Content-Aware Data Loss Prevention
Re: [E-devel] elm cnp bugs remaining
On Fri, 29 Jul 2011 15:32:39 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 24 Jul 2011 17:57:48 -0400 Mike Blumenkrantz m...@zentific.com 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. yep, easy way is just open elm entry notepad test, hit enter a few times, then select all and cut/paste. fails every time. * 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). Well imo we should at least support this mode and allow the app to choose. ? -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- 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 cnp bugs remaining
On Fri, 29 Jul 2011 15:32:39 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 24 Jul 2011 17:57:48 -0400 Mike Blumenkrantz m...@zentific.com 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. also another strange bug: if I copy a url from the address bar in opera to clipboard, it NEVER shows up in elm's clipboard. I'd guess there are other cases of this, but I've tested with xclip and it's definitely putting the selection in. -- 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 cnp bugs remaining
On Fri, 29 Jul 2011 15:32:39 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 24 Jul 2011 17:57:48 -0400 Mike Blumenkrantz m...@zentific.com 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. also another strange bug: if I copy a url from the address bar in opera to clipboard, it NEVER shows up in elm's clipboard. I'd guess there are other cases of this, but I've tested with xclip and it's definitely putting the selection in. -- 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] [Patch] Add XIM module for ecore_imf
On Thu, 28 Jul 2011 22:16:47 +0900 Naruto TAKAHASHI tnar...@gmail.com said: Thanks, raster! BTW, where is iBus config? :) none. ibus is new and ... well new. you can make an ibus one.. look at the scim, uim and iimf ones. we could make kinput2 and many others... i'll leave it up to whoever wants to use that input method to make one. the enlightenment_imc tool can helpe edit/create those files. :) just need to be added. 2011/7/28 Carsten Haitzler ras...@rasterman.com: On Tue, 26 Jul 2011 13:57:05 -0300 Iván Briano (Sachiel) sachi...@gmail.com 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 tnar...@gmail.com: Ya, thanks raster :) Now we are missing the E17 IM settings to set ECORE_IMF_MODULE properly. With my locale it's not loading the xim one by default when I run Elementary. 2011/7/26 Carsten Haitzler ras...@rasterman.com: On Sat, 23 Jul 2011 22:22:10 +0900 Jihoon Kim imfin...@gmail.com said: i fixed this one in svn already :) Hi, Naruto. I've tested in elementary_test entry menu after applying my edje patch related to client_window_set. However, I couldn't see the preedit string in the entry widget while I was typing. In addition, sometimes segmentation fault was occured. Here is backtrace of GDB. (gdb) bt #0 0x0030fb62 in eina_unicode_strlen (ustr=0x0) at eina_unicode.c:70 #1 0x003105dc in eina_unicode_unicode_to_utf8 (uni=0x0, #_len=0xb184) at eina_unicode.c:331 #2 0x00efd7b3 in _ecore_imf_context_xim_preedit_string_get #(ctx=0x8251b28, str=0xb1d8, cursor_pos=0xb1dc) at ecore_imf_xim.c:179 #3 0x004736d6 in ecore_imf_context_preedit_string_get (ctx=0x8251b28, str=0xb1d8, cursor_pos=0xb1dc) at ecore_imf_context.c:388 #4 0x004d4c44 in _edje_entry_imf_event_preedit_changed_cb #(data=0x8333628, type=79, event=0x838f0b8) at edje_entry.c:2887 #5 0x00428ac6 in _ecore_event_call () at ecore_events.c:693 #6 0x0042f4d2 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:1750 #7 0x0042dc49 in ecore_main_loop_begin () at ecore_main.c:848 #8 0x001d08cc in elm_run () at elm_main.c:1075 #9 0x0805551b in elm_main (argc=1, argv=0xb3a4) at test.c:489 #10 0x0804 in main (argc=1, argv=0xb3a4) at test.c:498 2011/7/23 Naruto TAKAHASHI tnar...@gmail.com Hi JihoonKim, and EFL developers. I attach a patch for fixing some XIM module bugs. - fix showing previous preedit string bug. - delete compile warning(thanks JihoonKim) - fix some sequence issue to send preedit changed event and commit event.(thanks JihoonKim) Please review this patch? Regards. 2011年7月22日23:52 Naruto TAKAHASHI tnar...@gmail.com: Hi, JihoonKim. I talked to you how fix preedit draw callback direction on IRC. I repeat to talk this stuff for didn't see this talk. Your patch behavior is no problem. But Preedit Draw Callback needs insert, delete, and replace by referencing Preedit Draw Callback argument. (detail: http://static.cray-cyber.org/Documentation/NEC_SX_R10_1/G1AE02E/CHAP13.HTML#13.18.6 . Preedit Draw Callback) I'm trying to fix too easy routine by using Eina_UStrBuf, now. So, please wait this. Off course, I merge deleting comple warning of your patch with thanks. :) Thanks. 2011/7/17 Jihoon Kim imfin...@gmail.com: Hi, Naruto. As I told you last Friday on IRC, I guess there are some bugs in your xim immodule. For example, in case that I'd like to input '私の' (watasino), the preedit string was got from your immodule like below '私のしの'. In addition, there are some sequence issue to send preedit changed event and commit event. I've tried to fix this problem and send you the patch. (I've tested on elementary_test entry) If you don't mind uploading this patch to svn, I'll request Maintainers to upload this patch. Thanks. On Sun, Jul 10, 2011 at 2:51 AM, Naruto TAKAHASHI tnar...@gmail.com wrote: Hi Mike. Thanks, feedback. I merged it to xim/Makefile.am. I attach a source code for using XIM module debug. This program can check a below behaviors. - toggle enable and disable XIM - commit string from XIM Another test, by using Desktop Entry Editor's text field. (Enlightenment Main-Settings-Settings Panel-New Application) When executing test program, set ECORE_IMF_MODULE=xim. Thanks. 2011/7/8 Mike McCormack mj.mccorm...@samsung.com: On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote: Hi, All. I attached some patches of XIM module of ecore_imf. As far as I know, EFL has
Re: [E-devel] header size...
On Fri, 29 Jul 2011 10:15:40 +0300 Tom Hacohen t...@stosb.com said: On 29/07/11 03:37, Bruno Dilly wrote: On Thu, Jul 28, 2011 at 7:53 PM, Mike Blumenkrantz m...@zentific.com wrote: On Fri, 29 Jul 2011 00:38:50 +0200 Hugo Camboulive hugo.camboul...@gmail.com 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. I (and probably many others) suggested it many times before, raster is against, I don't remember why. edje_decc then breaks if we start using includes. -- - 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] #define in Edje
On Thu, 28 Jul 2011 23:47:27 +0200 Andreas Volz li...@brachttal.net said:
Am Fri, 29 Jul 2011 00:12:30 +0300 schrieb 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.
Hm, as I said before. I had problems with clock module from darkness
theme:
if E17_PROFILE != HIRES_PDA E17_PROFILE != LOWRES_PDA
E17_PROFILE != MEDIUMRES_PDA
I tried various combinations. From my eyes defining some *_PDA doesn't
currently switch the timer to 10 sec. But I think this is what the
author liked. Then this is also wrong. But are you sure?
regards
Andreas
edje uses epp now. its older and simpler than gcc's cpp. its a very very very
old cpp from gcc. it works with numbers, but not enums, as tasn said - #define
HIRES_PDA to numbers.. literally. it ONLY every worked this way. look at the
Makefile of e17's theme. it literally doesd define these to numbers to make it
work:
-DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5
-DFAST_PC=6 -DE17_PROFILE=SLOW_PC
(defined in the @EDJE_DEF@ replace).
--
- 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] A Problem about using non-smart objects in Elemenetary.
On Thu, 28 Jul 2011 10:17:57 +0900 ChunEon Parkher...@naver.com said: i say remove the smart object check from smart_data_get as its not that useful and helps a lot here. Ok. I see.. But even it's the simple way we can do, I still wonder that the MAGIC CHECK is not strange in smart_data_get function since it is just checking whether object is smart or not... Do anybody has any other opinion ? If many agree with raster (or nobody reply to this mail), then i will apply the changes. Thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Carsten Haitzlerlt;ras...@rasterman.comgt; To: ChunEon Parklt;her...@naver.comgt; Cc: EFLlt;enlightenment-devel@lists.sourceforge.netgt; Sent: 11-07-27(수) 18:16:55 Subject: Re: [E-devel] A Problem about using non-smart objects in Elemenetary.On Mon, 11 Jul 2011 13:04:38 +0900 ChunEon Parklt;her...@naver.comgt; said: we also have the elm error abort stuff too. but as such i think some calls in evas can be made to not barf if its not a smart object, like getting smart data. if its not a smart obj just safely return null - thats basically then a simple way to detect if its a smart object or not. thats the right thing to do. Hello, EFL developers. I just have one question and need your opinions. In many cases, many non-smart objects are used in elementary e.g) evas_object_rectangle. Those objects are passed to elm_widget APIs frequently which calls the smart_object_data_get in API_ENTRY define. Since those are not smart objects, they will be handled by MAGIC_CHECK(EVAS_OBJ_SMART) in evas. If EVAS_DEBUG_ABORT is enabled, in that case the program will be aborted. Consequently, elementary can't use the EVAS_DEBUG_ABORT property usefully now as you can check it with elementary_test So, my question is where do we fix this problem ? 1. Find all the non-smart objects in elementary then change to smart objects? 2. Or before call the smart_object_data_get in API_ENTRY, check the object_type then pass the API call if the objects are non-smart? 3. Or skip the smart object MAGIC_CHECK in Evas? 4. Or leave them and don't use EVAS_DEBUG_ABORT? What do you think about this? -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
On Fri, 29 Jul 2011 16:18:21 +0900 ChunEon Parkher...@naver.com said: well they are internal like: _elm_widget_item_new() - they are intended to be used by item api's to have a shared core for building and managing items. each api exposes its own item api though. we COULd make some of these, as you say, exposed and shared so we dont duplicate the same api - like item_data_set/get(). in Elementary? I've not seen any regarding APIs. and can't not find. Could you give me a hint? Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Carsten Haitzlerlt;ras...@rasterman.comgt; To: ChunEon Parklt;her...@naver.comgt; Cc: enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-29(금) 15:50:46 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Wed, 27 Jul 2011 09:02:56 +0900 ChunEon Parklt;her...@naver.comgt; 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 Parklt;her...@naver.comgt; To: Gustavo Sverzut Barblt;barbi...@profusion.mobigt; Cc: Tom Hacohenlt;tom.haco...@partner.samsung.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-18(월) 14:16:44 Subject: RE: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib Ok, I will do. thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Gustavo Sverzut Barbierilt;barbi...@profusion.mobigt; To: Tom Hacohenlt;tom.haco...@partner.samsung.comgt; Cc: ChunEon Parklt;her...@naver.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-15(금) 02:38:42 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Thu, Jul 14, 2011 at 12:58 PM, Tom Hacohen lt;tom.haco...@partner.samsung.comgt; wrote: On 14/07/11 18:52, Gustavo Sverzut Barbieri wrote: 2011/7/13 ChunEon Parklt;her...@naver.comgt;: elm_naviframe_item_text_part_set/get() or something like that. - Yes. it looks not bad for me. But it will cause more mistakes of users since they should pass the part name, (I don't like it from that point of view although.) And some widgets have the item_label_set now. Need to keep the consistency if everyone agree with. Yes, Daniel is right and the current item_label_set() are more like unconverted legacy. They must be fixed and new APIs must be correct from start. Unfortunately, because those are not elm_widgets, calling elm_object_text_set won't work. We really need to find a solution to this one. Possibly another API that allows passing additional data? elm_object_text_subitem_set or something like that? check what we did for tooltips and others, they have some kind of interface in the items, if you follow you have generic functions to operate on them. but all in all I'd go for actual interfaces (in classes, not instances -- partial infra for Evas_Object is there, but lacks for generic items) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
Re: [E-devel] [PATCH] check NULL parameter in edje entry
On Fri, 29 Jul 2011 10:59:28 +0900 Jihoon Kim jihoon48@samsung.com said: 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? definitely! in svn! :) -- - 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] ecore: Add basic thread safety
On Wed, 27 Jul 2011 20:17:14 +0900 Mike McCormack mj.mccorm...@samsung.com said: it's 9pm on a friday night... and i don't think i'm going to get stuck into this right now. for now.. no one revert or do anything... i'll get to this tomorrow after some good sleep. :) Hi All, 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). In my experience, developers either are ignorant of the problems of threads, or expect libraries to magically work with threads. 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. thanks, Mike -- - 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 POLL
On Thu, 28 Jul 2011 12:42:32 -0400 Mike Blumenkrantz m...@zentific.com said: 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. we can have polls... sure. but i do reserve the right to go pffft to them. :) 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) i dislike 2. finding shit in eina is annoying and i keep having to open a new file for each thing i want to find.if someone is going to do 2 - it sure as hell is not going to be me. 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 -- - 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...
On 29/07/11 14:25, Carsten Haitzler (The Rasterman) wrote: edje_decc then breaks if we start using includes. That can be solved simply by normalizing the path, will take a look tomorrow. -- 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] A Problem about using non-smart objects in Elemenetary.
removed! Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Carsten Haitzlerlt;ras...@rasterman.comgt; To: ChunEon Parklt;her...@naver.comgt; Cc: EFLlt;enlightenment-devel@lists.sourceforge.netgt; Sent: 11-07-29(금) 20:19:01 Subject: Re: [E-devel] A Problem about using non-smart objects in Elemenetary.On Thu, 28 Jul 2011 10:17:57 +0900 ChunEon Parklt;her...@naver.comgt; said: i say remove the smart object check from smart_data_get as its not that useful and helps a lot here. Ok. I see.. But even it's the simple way we can do, I still wonder that the MAGIC CHECK is not strange in smart_data_get function since it is just checking whether object is smart or not... Do anybody has any other opinion ? If many agree with raster (or nobody reply to this mail), then i will apply the changes. Thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Carsten Haitzlerlt;ras...@rasterman.comgt; To: ChunEon Parklt;her...@naver.comgt; Cc: EFLlt;enlightenment-devel@lists.sourceforge.netgt; Sent: 11-07-27(수) 18:16:55 Subject: Re: [E-devel] A Problem about using non-smart objects in Elemenetary.On Mon, 11 Jul 2011 13:04:38 +0900 ChunEon Parklt;her...@naver.comgt; said: we also have the elm error abort stuff too. but as such i think some calls in evas can be made to not barf if its not a smart object, like getting smart data. if its not a smart obj just safely return null - thats basically then a simple way to detect if its a smart object or not. thats the right thing to do. Hello, EFL developers. I just have one question and need your opinions. In many cases, many non-smart objects are used in elementary e.g) evas_object_rectangle. Those objects are passed to elm_widget APIs frequently which calls the smart_object_data_get in API_ENTRY define. Since those are not smart objects, they will be handled by MAGIC_CHECK(EVAS_OBJ_SMART) in evas. If EVAS_DEBUG_ABORT is enabled, in that case the program will be aborted. Consequently, elementary can't use the EVAS_DEBUG_ABORT property usefully now as you can check it with elementary_test So, my question is where do we fix this problem ? 1. Find all the non-smart objects in elementary then change to smart objects? 2. Or before call the smart_object_data_get in API_ENTRY, check the object_type then pass the API call if the objects are non-smart? 3. Or skip the smart object MAGIC_CHECK in Evas? 4. Or leave them and don't use EVAS_DEBUG_ABORT? What do you think about this? -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- 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
I see your point.. I knew those things already. Thank you! Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Carsten Haitzlerlt;ras...@rasterman.comgt; To: ChunEon Parklt;her...@naver.comgt; Cc: enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-29(금) 20:23:17 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Fri, 29 Jul 2011 16:18:21 +0900 ChunEon Parklt;her...@naver.comgt; said: well they are internal like: _elm_widget_item_new() - they are intended to be used by item api's to have a shared core for building and managing items. each api exposes its own item api though. we COULd make some of these, as you say, exposed and shared so we dont duplicate the same api - like item_data_set/get(). in Elementary? I've not seen any regarding APIs. and can't not find. Could you give me a hint? Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Carsten Haitzlerlt;ras...@rasterman.comgt; To: ChunEon Parklt;her...@naver.comgt; Cc: enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-29(금) 15:50:46 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Wed, 27 Jul 2011 09:02:56 +0900 ChunEon Parklt;her...@naver.comgt; 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 Parklt;her...@naver.comgt; To: Gustavo Sverzut Barblt;barbi...@profusion.mobigt; Cc: Tom Hacohenlt;tom.haco...@partner.samsung.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-18(월) 14:16:44 Subject: RE: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/lib Ok, I will do. thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: Gustavo Sverzut Barbierilt;barbi...@profusion.mobigt; To: Tom Hacohenlt;tom.haco...@partner.samsung.comgt; Cc: ChunEon Parklt;her...@naver.comgt;; enlightenment-devel@lists.sourceforge.net; enlightenment-...@lists.sourceforge.net Sent: 11-07-15(금) 02:38:42 Subject: Re: [E-devel] E SVN: hermet IN trunk/elementary: data/images data/themes src/bin src/libOn Thu, Jul 14, 2011 at 12:58 PM, Tom Hacohen lt;tom.haco...@partner.samsung.comgt; wrote: On 14/07/11 18:52, Gustavo Sverzut Barbieri wrote: 2011/7/13 ChunEon Parklt;her...@naver.comgt;: elm_naviframe_item_text_part_set/get() or something like that. - Yes. it looks not bad for me. But it will cause more mistakes of users since they should pass the part name, (I don't like it from that point of view although.) And some widgets have the item_label_set now. Need to keep the consistency if everyone agree with. Yes, Daniel is right and the current item_label_set() are more like unconverted legacy. They must be fixed and new APIs must be correct from start. Unfortunately, because those are not elm_widgets, calling elm_object_text_set won't work. We really need to find a solution to this one. Possibly another API that allows passing additional data? elm_object_text_subitem_set or something like that? check what we did for tooltips and others, they have some kind of interface in the items, if you follow you have generic functions to operate on them. but all in all I'd go for actual interfaces (in classes, not instances -- partial infra for Evas_Object is there, but lacks for generic items) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten
[E-devel] [Patch] Handling the engine creation failed
Hi All,
If ecore_evas_[not_software_x11]_new(); returns NULL while elm_win_add(); is
called,
then ecore_evas_software_x11_new(); is used instead of other engines.
(FALLBACK_TRY)
But the configuration value for engine is not changed. This makes improper
result.
After FALLBACK_TRY, the elm_win works with different configuration value.
In this case, win-xwin (_elm_win_xwindow_get()) gives NULL.
and elm_win_xsinodow_get() returns 0 also.
Please refer to attached patch. Thanks a lot
Sincerely,
Shinwoo Kim.
Index: src/lib/elm_win.c
===
--- src/lib/elm_win.c (revision 61887)
+++ src/lib/elm_win.c (working copy)
@@ -1406,6 +1406,7 @@ elm_win_add(Evas_Object *parent, const char *name,
do { \
CRITICAL(engine engine creation failed. Trying software X11.); \
win-ee = ecore_evas_software_x11_new(NULL, 0, 0, 0, 1, 1); \
+elm_engine_set(ELM_SOFTWARE_X11); \
} while (0)
#define ENGINE_COMPARE(name) (!strcmp(_elm_config-engine, name))
--
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] Engage and XCB are on a boat
Hi, When i activated XCB support in ecore and evas, engage is not usable anymore. When i click on engage bar the E desktop menu is displayed. It's like if engage doesn't take focus when mouse entered the window. There is no zoom animation on mouse over. I try with and without composite, with detourious and default theme. I updated all EFL, e and engage today. When i rebuild evas and ecore without xcb, and only them, engage is working again as expected. -- 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] Engage and XCB are on a boat
On 07/29/2011 09:39 AM, Nicolas Aguirre wrote: Hi, When i activated XCB support in ecore and evas, engage is not usable anymore. When i click on engage bar the E desktop menu is displayed. It's like if engage doesn't take focus when mouse entered the window. There is no zoom animation on mouse over. I try with and without composite, with detourious and default theme. I updated all EFL, e and engage today. When i rebuild evas and ecore without xcb, and only them, engage is working again as expected. Hmmm, highly odd. I'll have a look at this when I get back to the states. dh -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] ecore: Add basic thread safety
On Fri, Jul 29, 2011 at 5:56 AM, Cedric BAIL cedric.b...@free.fr wrote:
On Fri, Jul 29, 2011 at 3:44 AM, Mike McCormack
mj.mccorm...@samsung.com wrote:
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).
Case 3, could be easily merged and done directly in
ecore_main_loop_thread_safe_call. Patch welcome, if I don't get to it
before anyone.
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.
Then take that pseudo example :
Eina_Bool _timer_in_main_loop(void *data)
{
;
free(data);
return 0;
}
void bad_idea()
{
tuttut = ecore_timer_add(unlucky, _timer_in_main_loop, something);
...;
if (bad_happen)
{
ecore_timer_del(tuttut);
free(something);
}
}
This code will work just fine in the main loop. Now in a thread it's
full of race condition and double free. Tell me how you can make it
work ? By trying to say, we are thread safe, you are just hidding more
and more the issue without solving it. So at the end, app will be less
stable and more difficult to debug. That's my point. Your patch isn't
fixing what it is advertising and I think it can't do it by design. C
is very different from Java, and is very difficult to make it thread
safe.
As far as I know, Cocoa, GTK, Qt and Win32 are not thread safe, and
nobody complain about that. It doesn't prevent anyone from writing
thousand of greate Cocoa appication (Maybe because they have GCD and
block and advertise it alot).
I don't know about the others, but at least GTK is kind of thread
safe. You can't ignore that you are using threads and just add
callbacks at will or check for them, but at least you have some ways
to do it:
http://developer.gnome.org/gtk-faq/stable/x481.html
--
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] Handling the engine creation failed
Dear cinoo. The patch looks good to me ! I committed your patch. But I changed some trivials there. Please check the lastest code. Thank you. Let's run together for the best moment! -Regards, Hermet- -Original Message- From: cnooklt;kimci...@gmail.comgt; To: EFLlt;enlightenment-devel@lists.sourceforge.netgt; Cc: Sent: 11-07-29(금) 22:14:07 Subject: [E-devel] [Patch] Handling the engine creation failedHi All, If ecore_evas_[not_software_x11]_new(); returns NULL while elm_win_add(); is called, then ecore_evas_software_x11_new(); is used instead of other engines. (FALLBACK_TRY) But the configuration value for engine is not changed. This makes improper result. After FALLBACK_TRY, the elm_win works with different configuration value. In this case, win-xwin (_elm_win_xwindow_get()) gives NULL. and elm_win_xsinodow_get() returns 0 also. Please refer to attached patch. Thanks a lot Sincerely, Shinwoo Kim. -- 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
On Fri, 29 Jul 2011, Rafael Antognolli wrote:
On Fri, Jul 29, 2011 at 5:56 AM, Cedric BAIL cedric.b...@free.fr wrote:
On Fri, Jul 29, 2011 at 3:44 AM, Mike McCormack
mj.mccorm...@samsung.com wrote:
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).
Case 3, could be easily merged and done directly in
ecore_main_loop_thread_safe_call. Patch welcome, if I don't get to it
before anyone.
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.
Then take that pseudo example :
Eina_Bool _timer_in_main_loop(void *data)
{
;
free(data);
return 0;
}
void bad_idea()
{
tuttut = ecore_timer_add(unlucky, _timer_in_main_loop, something);
...;
if (bad_happen)
{
ecore_timer_del(tuttut);
free(something);
}
}
This code will work just fine in the main loop. Now in a thread it's
full of race condition and double free. Tell me how you can make it
work ? By trying to say, we are thread safe, you are just hidding more
and more the issue without solving it. So at the end, app will be less
stable and more difficult to debug. That's my point. Your patch isn't
fixing what it is advertising and I think it can't do it by design. C
is very different from Java, and is very difficult to make it thread
safe.
As far as I know, Cocoa, GTK, Qt and Win32 are not thread safe, and
nobody complain about that. It doesn't prevent anyone from writing
thousand of greate Cocoa appication (Maybe because they have GCD and
block and advertise it alot).
I don't know about the others, but at least GTK is kind of thread
safe.
gtk is not thread safe. glib is.
Vincent
You can't ignore that you are using threads and just add
callbacks at will or check for them, but at least you have some ways
to do it:
http://developer.gnome.org/gtk-faq/stable/x481.html
--
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
--
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/eina: . src/include src/lib
On Fri, 29 Jul 2011, Enlightenment SVN wrote:
Log:
eina: add eina_main_loop_is.
Author: cedric
Date: 2011-07-29 07:56:42 -0700 (Fri, 29 Jul 2011)
New Revision: 61896
Trac: http://trac.enlightenment.org/e/changeset/61896
Modified:
trunk/eina/ChangeLog trunk/eina/src/include/eina_main.h
trunk/eina/src/lib/eina_main.c
Modified: trunk/eina/ChangeLog
===
--- trunk/eina/ChangeLog 2011-07-29 14:41:18 UTC (rev 61895)
+++ trunk/eina/ChangeLog 2011-07-29 14:56:42 UTC (rev 61896)
@@ -118,3 +118,8 @@
2011-07-04 Carsten Haitzler (The Rasterman)
* Add eina_mmap safety handling.
+
+2011-07-29 Cedric Bail
+
+ * Add eina_main_loop_is.
+
Modified: trunk/eina/src/include/eina_main.h
===
--- trunk/eina/src/include/eina_main.h2011-07-29 14:41:18 UTC (rev
61895)
+++ trunk/eina/src/include/eina_main.h2011-07-29 14:56:42 UTC (rev
61896)
@@ -133,6 +133,15 @@
EAPI int eina_threads_shutdown(void);
/**
+ * @brief Check if you are calling this function from the same thread Eina
was initialized or not
+ *
+ * Most EFL function are not thread safe and all the call need to happen in
+ * the main loop. With this call you could know if you can call an EFL
+ * function or not.
+ */
+EAPI Eina_Bool eina_main_loop_is(void);
+
+/**
* @}
*/
Modified: trunk/eina/src/lib/eina_main.c
===
--- trunk/eina/src/lib/eina_main.c2011-07-29 14:41:18 UTC (rev 61895)
+++ trunk/eina/src/lib/eina_main.c2011-07-29 14:56:42 UTC (rev 61896)
@@ -316,6 +316,19 @@
#endif
}
+EAPI Eina_Bool
+eina_main_loop_is(void)
+{
First you have to check here if threads are enabled
Vincent
+#ifdef EINA_HAVE_DEBUG_THREADS
+ if (pthread_equal(_eina_main_loop, pthread_self()))
+ return EINA_TRUE;
+ return EINA_FALSE;
+#else
+ /* FIXME: need to check how to do this on windows */
+ return EINA_TRUE;
+#endif
+}
+
/**
* @}
*/
--
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 get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] header size...
On Fri, 29 Jul 2011 15:01:52 +0300 Tom Hacohen t...@stosb.com said: On 29/07/11 14:25, Carsten Haitzler (The Rasterman) wrote: edje_decc then breaks if we start using includes. That can be solved simply by normalizing the path, will take a look tomorrow. it already tries. :) -- - 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] ecore: Add basic thread safety
On Wed, 27 Jul 2011 15:08:21 +0200 Cedric BAIL cedric.b...@free.fr said: OK... quick comments: 1. adding threadsafety isnt bad. it's no worse than the thread checks NO ONe complained about. it's also optionally enabled, so i see no downside there. 2. yes - it's a pain in the butt to do, BUT if someone is willing to do it... should we say no to someone picking up the work and doing it? 3. thread safety doesnt fix thread awareness. lets remember that. that's a different problem to fix and a separate topic. right now we hsave no official way to wake up the main loop when u do things like add a timer in a thread - if ecore is threadsafe. you can create a mechanism via ecore_pipe - but a simpler one would be needed eventually. until it's ready and well tested we can still claim ecore is not threadsafe. so.. now to specific comments. Hi, On Wed, Jul 27, 2011 at 1:17 PM, Mike McCormack mj.mccorm...@samsung.com 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. yes - it's not a final fix, then again how many things do we have in svn that get put in in stages. :) this doesnt finish making ecore threadsafe. it hasn't had a lot of testing yet. :) 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 ? they understand ecore_thread even less unfortunately. they also DONT understand ecore is NOT threadsafe. :( i sure as hell wasn't into the idea of making ecore threadsafe. i dont want to do the work. most here don't, but if someone is willing to do the work.. why should be veto it? 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 well that requires evas be threadsafe and edje and elementary ... etc. - they are still yet to be done. until we get that far, this is a moot point. when we DO get that far... we can add things like: evas_begin(evas); evas_end(evas); that act like a freeze push and pop and when you get back to 0, you wake up the mainloop - via the evas event fd :) we can create a thread local counter for each of these so this increments per thread. we can lock the canvas while itds begun, or create more imaginative schemes, but to even get that far, we MUST make all the libs threadsafe anyway. 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). education though is much harder. much much much much much harder. we can push these, but this does NOT preclude threadsafety. I clearly disagree on that patch going in (and I am still not discussing the issue of performance here). -- 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 -- - 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] ecore: Add basic thread safety
On Thu, 28 Jul 2011 14:31:53 +0200 Cedric BAIL cedric.b...@free.fr said: 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. why revert? we simply dont claim ecore is threadsafe yet. in fact its not even enabled by default. -- - 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] ecore: Add basic thread safety
On Fri, 29 Jul 2011 06:57:33 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: 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. of course it is! i've been doing this for YEARS! adding new features that u need to either compile-time enable or runtime enable to use/see. is not ecore-xcb exactly that? what about all of the loaders fo eavs, or engines... or... i can go on. -- - 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: discomfitor trunk/elementary/src/lib
On Fri, 29 Jul 2011 08:08:56 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: unbreak elm_menu_item api the following functions are now DEPRECATED and will be removed on 5 AUG 2011: elm_menu_item_object_icon_get - elm_menu_item_object_content_get elm_menu_item_icon_get - elm_menu_item_object_icon_name_get elm_menu_item_icon_set - elm_menu_item_object_icon_name_set added the following NEW functions: elm_menu_item_object_content_set elm_menu_item_menu_get (this will probably be replaced by an eventual elm_object_item_owner_get() or whatever it gets named) Author: discomfitor Date: 2011-07-29 08:08:56 -0700 (Fri, 29 Jul 2011) New Revision: 61899 Trac: http://trac.enlightenment.org/e/changeset/61899 Modified: trunk/elementary/src/lib/Elementary.h.in trunk/elementary/src/lib/elm_menu.c I was feeling benevolent this time, so I marked functions slated for removal as deprecated instead of just deleting them outright. Migrate your code quickly, as I intend to be very punctual with my deletions. On other matters, is Elm_Widget_Item stable enough to create an elm_object_item api yet? I think it would be nice to consolidate a lot of the genlist_item/gengrid_item/list_item/menu_item/etc apis... -- 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] [PATCH] ecore: Add basic thread safety
On Sat, 30 Jul 2011, Carsten Haitzler (The Rasterman) wrote: On Fri, 29 Jul 2011 06:57:33 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: 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. of course it is! i've been doing this for YEARS! adding new features that u need to either compile-time enable or runtime enable to use/see. is not ecore-xcb exactly that? what about all of the loaders fo eavs, or engines... or... i can go on. except for ecore_xcb (my code, before devilhorns' changes), the code was always functional and of good, or high quality. According to cedric, the code here will not work at all on some important cases. 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
Re: [E-devel] [PATCH] ecore: Add basic thread safety
On Fri, 29 Jul 2011, Vincent Torri wrote: On Sat, 30 Jul 2011, Carsten Haitzler (The Rasterman) wrote: On Fri, 29 Jul 2011 06:57:33 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: 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. of course it is! i've been doing this for YEARS! adding new features that u need to either compile-time enable or runtime enable to use/see. is not ecore-xcb exactly that? what about all of the loaders fo eavs, or engines... or... i can go on. except for ecore_xcb (my code, before devilhorns' changes), the code was always functional and of good, or high quality. According to cedric, the code here will not work at all on some important cases. and I repeat what i told you on IRC : these changes are in the most important part of the EFL : the main loop. Also, doing such critical change, even if it is optional, **just before** a release (if I'm not mistaken the release is for september) is just masochism (as people will use it if it is in a release, even if it is optional) so again, I'm against that commit. Add it later if you want (you're the maintianer, so you do what you want), but now, for such critical change, it's not good 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
Re: [E-devel] [PATCH] ecore: Add basic thread safety
On Fri, 29 Jul 2011 17:20:24 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Fri, 29 Jul 2011, Vincent Torri wrote: On Sat, 30 Jul 2011, Carsten Haitzler (The Rasterman) wrote: On Fri, 29 Jul 2011 06:57:33 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: 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. of course it is! i've been doing this for YEARS! adding new features that u need to either compile-time enable or runtime enable to use/see. is not ecore-xcb exactly that? what about all of the loaders fo eavs, or engines... or... i can go on. except for ecore_xcb (my code, before devilhorns' changes), the code was always functional and of good, or high quality. According to cedric, the code here will not work at all on some important cases. and I repeat what i told you on IRC : these changes are in the most important part of the EFL : the main loop. Also, doing such critical change, even if it is optional, **just before** a release (if I'm not mistaken the release is for september) is just masochism (as people will use it if it is in a release, even if it is optional) so again, I'm against that commit. Add it later if you want (you're the maintianer, so you do what you want), but now, for such critical change, it's not good at all. Vincent I'm normally gung ho about new features and all, but it does seem like we're cutting it close by sticking this in only a month or two before a possible release. If I recall (and I do since I have my mailbox open and flames are spewing out), I tried to add threadsafety to a few eina data types before 1.0. Despite having it functional and being 2-3 months before our eventual release, I bowed to the great wisdom of vtorri and reverted it. A similar situation happened with a match from Mike M. which optimized some main loop functionality by converting lists to inlists. On top of that, even if it's disabled by default this brings a radical shift in EFL's core philosophy. If we're going to implement it then it should be with general agreement (which is definitely not the case at present) and proper evaluations/benchmarks/etc which should NOT be rushed or ignored due to a pending release. -- 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
[E-devel] conf_randr - A Randr dialog for e17
it seems cool, thanx didn' try yet, i'll do -- 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] evas jpeg memfile loader leaks
heyo, got a couple leaks here: ==28967== 2,200 bytes in 55 blocks are definitely lost in loss record 2,038 of 2,100 ==28967==at 0x4007A6D: calloc (vg_replace_malloc.c:432) ==28967==by 0x421ED5A: _evas_jpeg_membuf_src (evas_image_load_jpeg.c:146) ==28967==by 0x421EEC2: evas_image_load_file_head_jpeg_internal (evas_image_load_jpeg.c:190) ==28967==by 0x4220667: evas_image_load_file_head_jpeg (evas_image_load_jpeg.c:856) ==28967==by 0x41FA541: _evas_image_foreach_loader (evas_image_load.c:147) ==28967==by 0x485B90DF: _eina_foreach_cb (eina_amalgamation.c:3709) ==28967==by 0x485C6E9D: eina_iterator_foreach (eina_amalgamation.c:5328) ==28967==by 0x485C9AD0: eina_hash_foreach (eina_amalgamation.c:4373) ==28967==by 0x41C6D26: evas_module_foreach_image_loader (evas_module.c:391) ==28967==by 0x41FAAB7: evas_common_load_rgba_image_module_from_file (evas_image_load.c:236) ==28967==by 0x41C7D21: _evas_cache_image_entry_new (evas_cache_image.c:314) ==28967==by 0x41C8E10: evas_cache_image_request (evas_cache_image.c:827) ==28967==by 0x41FC065: evas_common_load_image_from_file (evas_image_main.c:632) ==28967==by 0x421B40B: eng_image_load (evas_engine.c:365) ==28967==by 0x417BE4F: evas_object_image_file_set (evas_object_image.c:323) ==28967==by 0x417BA6E: evas_object_image_memfile_set (evas_object_image.c:253) ==28967==by 0x4126D41: _els_smart_icon_memfile_set (els_icon.c:102) ==28967==by 0x40BD2D6: elm_icon_memfile_set (elm_icon.c:486) ==28967==by 0x80706D5: _it_icon_get (contact_list.c:104) ==28967==by 0x40A678B: _item_icon_realize (elm_genlist.c:1702) ==28967==by 0x40A71BC: _item_realize (elm_genlist.c:1893) ==28967==by 0x40A8D16: _update_job (elm_genlist.c:2480) ==28967==by 0x488CE857: _ecore_job_event_handler (ecore_job.c:131) ==28967==by 0x488CA07D: _ecore_event_call (ecore_events.c:693) ==28967==by 0x488D093D: _ecore_main_loop_iterate_internal (ecore_main.c:1759) ==28967==by 0x488CF194: ecore_main_loop_begin (ecore_main.c:857) ==28967==by 0x8073845: main (main.c:92) ==28967== 160 bytes in 4 blocks are definitely lost in loss record 1,734 of 2,100 ==28967==at 0x4007A6D: calloc (vg_replace_malloc.c:432) ==28967==by 0x421ED5A: _evas_jpeg_membuf_src (evas_image_load_jpeg.c:146) ==28967==by 0x421EEC2: evas_image_load_file_head_jpeg_internal (evas_image_load_jpeg.c:190) ==28967==by 0x4220667: evas_image_load_file_head_jpeg (evas_image_load_jpeg.c:856) ==28967==by 0x41FA541: _evas_image_foreach_loader (evas_image_load.c:147) ==28967==by 0x485B90DF: _eina_foreach_cb (eina_amalgamation.c:3709) ==28967==by 0x485C6E9D: eina_iterator_foreach (eina_amalgamation.c:5328) ==28967==by 0x485C9AD0: eina_hash_foreach (eina_amalgamation.c:4373) ==28967==by 0x41C6D26: evas_module_foreach_image_loader (evas_module.c:391) ==28967==by 0x41FAAB7: evas_common_load_rgba_image_module_from_file (evas_image_load.c:236) ==28967==by 0x41C7D21: _evas_cache_image_entry_new (evas_cache_image.c:314) ==28967==by 0x41C8E10: evas_cache_image_request (evas_cache_image.c:827) ==28967==by 0x41FC065: evas_common_load_image_from_file (evas_image_main.c:632) ==28967==by 0x421B40B: eng_image_load (evas_engine.c:365) ==28967==by 0x417BE4F: evas_object_image_file_set (evas_object_image.c:323) ==28967==by 0x417BA6E: evas_object_image_memfile_set (evas_object_image.c:253) ==28967==by 0x4126D41: _els_smart_icon_memfile_set (els_icon.c:102) ==28967==by 0x40BD2D6: elm_icon_memfile_set (elm_icon.c:486) ==28967==by 0x806EA2E: _chat_conv_image_provider (chat_image.c:13) ==28967==by 0x4132492: _elm_tooltip_reconfigure (els_tooltip.c:324) ==28967==by 0x4131EEC: _elm_tooltip_reconfigure_job (els_tooltip.c:193) ==28967==by 0x488CE857: _ecore_job_event_handler (ecore_job.c:131) ==28967==by 0x488CA07D: _ecore_event_call (ecore_events.c:693) ==28967==by 0x488D093D: _ecore_main_loop_iterate_internal (ecore_main.c:1759) ==28967==by 0x488CF194: ecore_main_loop_begin (ecore_main.c:857) ==28967==by 0x8073845: main (main.c:92) -- 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] conf_randr - A Randr dialog for e17
Hello. On Fri, 2011-07-29 at 19:12, Leif Middelschulte wrote: Attached is yet another set, which fixes an issue when rearranging monitors multiple times. /usr/local/bin/edje_cc -v -id ../../../src/modules/conf_randr/images -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC \ ../../../src/modules/conf_randr/e-module-conf_randr.edc \ ../../../src/modules/conf_randr/e-module-conf_randr.edj /usr/local/bin/edje_cc: Wrote 251 bytes ( 0Kb) for edje_file header /usr/local/bin/edje_cc: Error. Unable to load image icon.png used by file ../../../src/modules/conf_randr/e-module-conf_randr.edj: File (or file path) does not exist. Check if path to file icon.png is correct (both directory and file name). make[4]: *** [e-module-conf_randr.edj] Error 255 For now I will drop in another icon and see if it works out. Will let you know. regards Stefan Schmidt -- 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
Am Fri, 29 Jul 2011 20:30:30 +0900 schrieb Carsten Haitzler (The
Rasterman):
On Thu, 28 Jul 2011 23:47:27 +0200 Andreas Volz li...@brachttal.net
said:
Am Fri, 29 Jul 2011 00:12:30 +0300 schrieb 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.
Hm, as I said before. I had problems with clock module from darkness
theme:
if E17_PROFILE != HIRES_PDA E17_PROFILE != LOWRES_PDA
E17_PROFILE != MEDIUMRES_PDA
I tried various combinations. From my eyes defining some *_PDA
doesn't currently switch the timer to 10 sec. But I think this is
what the author liked. Then this is also wrong. But are you sure?
regards
Andreas
edje uses epp now. its older and simpler than gcc's cpp. its a very
very very old cpp from gcc. it works with numbers, but not enums, as
tasn said - #define HIRES_PDA to numbers.. literally. it ONLY every
worked this way. look at the Makefile of e17's theme. it literally
doesd define these to numbers to make it work:
-DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4
-DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC
(defined in the @EDJE_DEF@ replace).
Thanks for that hint!
regards
Andreas
--
Technical Blog http://andreasvolz.wordpress.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] conf_randr - A Randr dialog for e17
Hello. On Fri, 2011-07-29 at 23:11, Stefan Schmidt wrote: On Fri, 2011-07-29 at 19:12, Leif Middelschulte wrote: Attached is yet another set, which fixes an issue when rearranging monitors multiple times. /usr/local/bin/edje_cc -v -id ../../../src/modules/conf_randr/images -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC \ ../../../src/modules/conf_randr/e-module-conf_randr.edc \ ../../../src/modules/conf_randr/e-module-conf_randr.edj /usr/local/bin/edje_cc: Wrote 251 bytes ( 0Kb) for edje_file header /usr/local/bin/edje_cc: Error. Unable to load image icon.png used by file ../../../src/modules/conf_randr/e-module-conf_randr.edj: File (or file path) does not exist. Check if path to file icon.png is correct (both directory and file name). make[4]: *** [e-module-conf_randr.edj] Error 255 For now I will drop in another icon and see if it works out. Will let you know. Hmm, either I'm to tired to think straight enough or something strange is going on here. I dropped in another icon and the edje compiled fine. Complete E rebuild and install and no sign of and randr module in modules neither any config options in the settings panel (no surprise if the module is not loaded). Is the any magic I'm missing to get the module show up? Its installed in the same folder as all the other E modules already checked that. regards Stefan Schmidt -- 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: discomfitor trunk/eet/src/lib
On Fri, 29 Jul 2011, Enlightenment SVN wrote: Log: I blame this one on raster funny to make a spelling mistake in a sentence where the word 'dictionnary' is used :) Vincent Author: discomfitor Date: 2011-07-29 15:17:16 -0700 (Fri, 29 Jul 2011) New Revision: 61911 Trac: http://trac.enlightenment.org/e/changeset/61911 Modified: trunk/eet/src/lib/Eet.h Modified: trunk/eet/src/lib/Eet.h === --- trunk/eet/src/lib/Eet.h 2011-07-29 21:40:54 UTC (rev 61910) +++ trunk/eet/src/lib/Eet.h 2011-07-29 22:17:16 UTC (rev 61911) @@ -626,7 +626,7 @@ * * This checks the given dictionary to see if the given string is actually * inside that dictionary (i.e. comes from it) and returns 1 if it does. - * If the dictionary handle is invlide, the string is NULL or the string is + * If the dictionary handle is invalid, the string is NULL or the string is * not in the dictionary, 0 is returned. * * @since 1.0.0 -- 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 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: discomfitor trunk/eet/src/lib
On Sat, 30 Jul 2011 00:54:04 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Fri, 29 Jul 2011, Enlightenment SVN wrote: Log: I blame this one on raster funny to make a spelling mistake in a sentence where the word 'dictionnary' is used :) Vincent I think it's funny that there was more than one occurrence of 'dictionnary' in the lib. Author: discomfitor Date: 2011-07-29 15:17:16 -0700 (Fri, 29 Jul 2011) New Revision: 61911 Trac: http://trac.enlightenment.org/e/changeset/61911 Modified: trunk/eet/src/lib/Eet.h -- 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] evas jpeg memfile loader leaks
On Fri, 29 Jul 2011 17:00:24 -0400 Mike Blumenkrantz m...@zentific.com said: SOMEONE didnt check that libjpeg calls the term func for the membuf src... who added that code... :) heyo, got a couple leaks here: ==28967== 2,200 bytes in 55 blocks are definitely lost in loss record 2,038 of 2,100 ==28967==at 0x4007A6D: calloc (vg_replace_malloc.c:432) ==28967==by 0x421ED5A: _evas_jpeg_membuf_src (evas_image_load_jpeg.c:146) ==28967==by 0x421EEC2: evas_image_load_file_head_jpeg_internal (evas_image_load_jpeg.c:190) ==28967==by 0x4220667: evas_image_load_file_head_jpeg (evas_image_load_jpeg.c:856) ==28967==by 0x41FA541: _evas_image_foreach_loader (evas_image_load.c:147) ==28967==by 0x485B90DF: _eina_foreach_cb (eina_amalgamation.c:3709) ==28967==by 0x485C6E9D: eina_iterator_foreach (eina_amalgamation.c:5328) ==28967==by 0x485C9AD0: eina_hash_foreach (eina_amalgamation.c:4373) ==28967==by 0x41C6D26: evas_module_foreach_image_loader (evas_module.c:391) ==28967== by 0x41FAAB7: evas_common_load_rgba_image_module_from_file (evas_image_load.c:236) ==28967==by 0x41C7D21: _evas_cache_image_entry_new (evas_cache_image.c:314) ==28967==by 0x41C8E10: evas_cache_image_request (evas_cache_image.c:827) ==28967==by 0x41FC065: evas_common_load_image_from_file (evas_image_main.c:632) ==28967==by 0x421B40B: eng_image_load (evas_engine.c:365) ==28967==by 0x417BE4F: evas_object_image_file_set (evas_object_image.c:323) ==28967== by 0x417BA6E: evas_object_image_memfile_set (evas_object_image.c:253) ==28967==by 0x4126D41: _els_smart_icon_memfile_set (els_icon.c:102) ==28967==by 0x40BD2D6: elm_icon_memfile_set (elm_icon.c:486) ==28967== by 0x80706D5: _it_icon_get (contact_list.c:104) ==28967==by 0x40A678B: _item_icon_realize (elm_genlist.c:1702) ==28967==by 0x40A71BC: _item_realize (elm_genlist.c:1893) ==28967==by 0x40A8D16: _update_job (elm_genlist.c:2480) ==28967==by 0x488CE857: _ecore_job_event_handler (ecore_job.c:131) ==28967==by 0x488CA07D: _ecore_event_call (ecore_events.c:693) ==28967==by 0x488D093D: _ecore_main_loop_iterate_internal (ecore_main.c:1759) ==28967==by 0x488CF194: ecore_main_loop_begin (ecore_main.c:857) ==28967==by 0x8073845: main (main.c:92) ==28967== 160 bytes in 4 blocks are definitely lost in loss record 1,734 of 2,100 ==28967==at 0x4007A6D: calloc (vg_replace_malloc.c:432) ==28967==by 0x421ED5A: _evas_jpeg_membuf_src (evas_image_load_jpeg.c:146) ==28967==by 0x421EEC2: evas_image_load_file_head_jpeg_internal (evas_image_load_jpeg.c:190) ==28967==by 0x4220667: evas_image_load_file_head_jpeg (evas_image_load_jpeg.c:856) ==28967==by 0x41FA541: _evas_image_foreach_loader (evas_image_load.c:147) ==28967==by 0x485B90DF: _eina_foreach_cb (eina_amalgamation.c:3709) ==28967==by 0x485C6E9D: eina_iterator_foreach (eina_amalgamation.c:5328) ==28967==by 0x485C9AD0: eina_hash_foreach (eina_amalgamation.c:4373) ==28967==by 0x41C6D26: evas_module_foreach_image_loader (evas_module.c:391) ==28967== by 0x41FAAB7: evas_common_load_rgba_image_module_from_file (evas_image_load.c:236) ==28967==by 0x41C7D21: _evas_cache_image_entry_new (evas_cache_image.c:314) ==28967==by 0x41C8E10: evas_cache_image_request (evas_cache_image.c:827) ==28967==by 0x41FC065: evas_common_load_image_from_file (evas_image_main.c:632) ==28967==by 0x421B40B: eng_image_load (evas_engine.c:365) ==28967==by 0x417BE4F: evas_object_image_file_set (evas_object_image.c:323) ==28967== by 0x417BA6E: evas_object_image_memfile_set (evas_object_image.c:253) ==28967==by 0x4126D41: _els_smart_icon_memfile_set (els_icon.c:102) ==28967==by 0x40BD2D6: elm_icon_memfile_set (elm_icon.c:486) ==28967== by 0x806EA2E: _chat_conv_image_provider (chat_image.c:13) ==28967==by 0x4132492: _elm_tooltip_reconfigure (els_tooltip.c:324) ==28967==by 0x4131EEC: _elm_tooltip_reconfigure_job (els_tooltip.c:193) ==28967==by 0x488CE857: _ecore_job_event_handler (ecore_job.c:131) ==28967==by 0x488CA07D: _ecore_event_call (ecore_events.c:693) ==28967==by 0x488D093D: _ecore_main_loop_iterate_internal (ecore_main.c:1759) ==28967==by 0x488CF194: ecore_main_loop_begin (ecore_main.c:857) ==28967==by 0x8073845: main (main.c:92) -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The
Re: [E-devel] evas jpeg memfile loader leaks
On Sat, 30 Jul 2011 10:14:05 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Fri, 29 Jul 2011 17:00:24 -0400 Mike Blumenkrantz m...@zentific.com said: SOMEONE didnt check that libjpeg calls the term func for the membuf src... who added that code... :) heyo, got a couple leaks here: ==28967== 2,200 bytes in 55 blocks are definitely lost in loss record 2,038 of 2,100 ==28967==at 0x4007A6D: calloc (vg_replace_malloc.c:432) ==28967==by 0x421ED5A: _evas_jpeg_membuf_src (evas_image_load_jpeg.c:146) ==28967==by 0x421EEC2: evas_image_load_file_head_jpeg_internal (evas_image_load_jpeg.c:190) ==28967==by 0x4220667: evas_image_load_file_head_jpeg (evas_image_load_jpeg.c:856) ==28967==by 0x41FA541: _evas_image_foreach_loader (evas_image_load.c:147) ==28967==by 0x485B90DF: _eina_foreach_cb (eina_amalgamation.c:3709) ==28967==by 0x485C6E9D: eina_iterator_foreach (eina_amalgamation.c:5328) ==28967== by 0x485C9AD0: eina_hash_foreach (eina_amalgamation.c:4373) ==28967==by 0x41C6D26: evas_module_foreach_image_loader (evas_module.c:391) ==28967== by 0x41FAAB7: evas_common_load_rgba_image_module_from_file (evas_image_load.c:236) ==28967==by 0x41C7D21: _evas_cache_image_entry_new (evas_cache_image.c:314) ==28967==by 0x41C8E10: evas_cache_image_request (evas_cache_image.c:827) ==28967== by 0x41FC065: evas_common_load_image_from_file (evas_image_main.c:632) ==28967==by 0x421B40B: eng_image_load (evas_engine.c:365) ==28967== by 0x417BE4F: evas_object_image_file_set (evas_object_image.c:323) ==28967== by 0x417BA6E: evas_object_image_memfile_set (evas_object_image.c:253) ==28967==by 0x4126D41: _els_smart_icon_memfile_set (els_icon.c:102) ==28967==by 0x40BD2D6: elm_icon_memfile_set (elm_icon.c:486) ==28967== by 0x80706D5: _it_icon_get (contact_list.c:104) ==28967==by 0x40A678B: _item_icon_realize (elm_genlist.c:1702) ==28967==by 0x40A71BC: _item_realize (elm_genlist.c:1893) ==28967==by 0x40A8D16: _update_job (elm_genlist.c:2480) ==28967==by 0x488CE857: _ecore_job_event_handler (ecore_job.c:131) ==28967==by 0x488CA07D: _ecore_event_call (ecore_events.c:693) ==28967==by 0x488D093D: _ecore_main_loop_iterate_internal (ecore_main.c:1759) ==28967==by 0x488CF194: ecore_main_loop_begin (ecore_main.c:857) ==28967==by 0x8073845: main (main.c:92) ==28967== 160 bytes in 4 blocks are definitely lost in loss record 1,734 of 2,100 ==28967==at 0x4007A6D: calloc (vg_replace_malloc.c:432) ==28967==by 0x421ED5A: _evas_jpeg_membuf_src (evas_image_load_jpeg.c:146) ==28967==by 0x421EEC2: evas_image_load_file_head_jpeg_internal (evas_image_load_jpeg.c:190) ==28967==by 0x4220667: evas_image_load_file_head_jpeg (evas_image_load_jpeg.c:856) ==28967==by 0x41FA541: _evas_image_foreach_loader (evas_image_load.c:147) ==28967==by 0x485B90DF: _eina_foreach_cb (eina_amalgamation.c:3709) ==28967==by 0x485C6E9D: eina_iterator_foreach (eina_amalgamation.c:5328) ==28967== by 0x485C9AD0: eina_hash_foreach (eina_amalgamation.c:4373) ==28967==by 0x41C6D26: evas_module_foreach_image_loader (evas_module.c:391) ==28967== by 0x41FAAB7: evas_common_load_rgba_image_module_from_file (evas_image_load.c:236) ==28967==by 0x41C7D21: _evas_cache_image_entry_new (evas_cache_image.c:314) ==28967==by 0x41C8E10: evas_cache_image_request (evas_cache_image.c:827) ==28967== by 0x41FC065: evas_common_load_image_from_file (evas_image_main.c:632) ==28967==by 0x421B40B: eng_image_load (evas_engine.c:365) ==28967== by 0x417BE4F: evas_object_image_file_set (evas_object_image.c:323) ==28967== by 0x417BA6E: evas_object_image_memfile_set (evas_object_image.c:253) ==28967==by 0x4126D41: _els_smart_icon_memfile_set (els_icon.c:102) ==28967==by 0x40BD2D6: elm_icon_memfile_set (elm_icon.c:486) ==28967== by 0x806EA2E: _chat_conv_image_provider (chat_image.c:13) ==28967==by 0x4132492: _elm_tooltip_reconfigure (els_tooltip.c:324) ==28967==by 0x4131EEC: _elm_tooltip_reconfigure_job (els_tooltip.c:193) ==28967==by 0x488CE857: _ecore_job_event_handler (ecore_job.c:131) ==28967==by 0x488CA07D: _ecore_event_call (ecore_events.c:693) ==28967==by 0x488D093D: _ecore_main_loop_iterate_internal (ecore_main.c:1759) ==28967==by 0x488CF194: ecore_main_loop_begin (ecore_main.c:857) ==28967==by 0x8073845: main (main.c:92) -- Mike Blumenkrantz Zentific: Coding in binary since '10. hooray! our lord and savior has blessed us with these leak fixes! -- 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.
Re: [E-devel] conf_randr - A Randr dialog for e17
Hey, thanks for testing the patch :-) See comments in their context, respectively. Am 30.07.2011 um 00:15 schrieb Stefan Schmidt ste...@datenfreihafen.org: Hello. On Fri, 2011-07-29 at 23:11, Stefan Schmidt wrote: On Fri, 2011-07-29 at 19:12, Leif Middelschulte wrote: Attached is yet another set, which fixes an issue when rearranging monitors multiple times. /usr/local/bin/edje_cc -v -id ../../../src/modules/conf_randr/ images -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3 -DSLOW_PC=4 - DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC \ ../../../src/modules/conf_randr/e-module-conf_randr.edc \ ../../../src/modules/conf_randr/e-module-conf_randr.edj /usr/local/bin/edje_cc: Wrote 251 bytes ( 0Kb) for edje_file header /usr/local/bin/edje_cc: Error. Unable to load image icon.png used by file ../../../src/modules/conf_randr/e-module-conf_randr.edj: File (or file path) does not exist. Check if path to file icon.png is correct (both directory and file name). make[4]: *** [e-module-conf_randr.edj] Error 255 I'm sorry. I thought gut produced a hexdump of the image as a patch. It did in my previous patch. I'll check again tomorrow, if I can. For now I will drop in another icon and see if it works out. Will let you know. Hmm, either I'm to tired to think straight enough or something strange is going on here. I dropped in another icon and the edje compiled fine. Complete E rebuild and install and no sign of and randr module in modules neither any config options in the settings panel (no surprise if the module is not loaded). Is the any magic I'm missing to get the module show up? Its installed in the same folder as all the other E modules already checked that. Yeah, that's a weird issue I also faced. I need to fix it. See whether it shows up in the system modules list. If not use 'enlightenment_remote -module-load conf_randr' and '-module-enable conf_randr' for now. I'm really sorry for the inconvenience. I think it's because of wrong naming, or changes to the module API. regards, Leif regards, Stefan Schmidt --- --- --- - 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
