Re: [E-devel] Next EFL release cycle
On Mon, 14 May 2012 08:51:44 +0200 Vincent Torri said: > On Mon, May 14, 2012 at 8:26 AM, Carsten Haitzler > wrote: > > We have a lot of changes going on in Elementary right now. Since people may > > submit patches relative to both trunk AND to the release, to minimize > > problems with pulling in patches and work I think we should have a short > > development cycle for the next release, so how about this: > > > > feature freeze july 1. next release july 30. (july 30 is a goal). this > > means: > > > > 1. features no0t in by july 1 need to hold back until release after (and go > > in after july 30). > > 2. we'll be spinning yet another release of efl and i'm thinking we > > synchronise all efl versions to 1.7 (this will help with single tree merge > > too). > > and we release e17 the same time. As cedric just said to me : e17 > using the EFL 1.7. Could be funny :) release E 1.7! :) bwhahahjahah ok - no. we;ve been so long waiting for 0.17.. it's going to happen damnit! -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: glima trunk/elementary/src/lib
On 13/05/12 18:14, Gustavo Sverzut Barbieri wrote: > That's the single sane way to do it, and the case for every toolkit > out there, be ObjC, C++ or C. The developer needs to understand the > hierarchy in order to use, you can't call a method in a object that > did not implement, but admittedly C makes it more cumbersome as you > must type the namespace and class name, while C++ and ObjC does that > for you. > > If you think about that now, although not having to think about the > hierarchy to type the name, the user indeed needs to know if the > object supports parts setting, and which. If you call part set on a > box, it will do nothing. > > We could keep the backwards compatibility thing and do not deprecate > it, but in my opinion it is bad because: > > Once we allow extending Elementary from outside, more libraries > will create more components and these may have their own common > methods. Imagine a library provides a base widget BW and dozen > widgets, all with the same methods. You'll have some my_bw_method(). > You cannot/should not create elm_object_method(), thus you'll generate > some inconsistency here as out-of-library widgets can't use the same > pattern. > > All in all the elm_object_ methods were mostly hacked in afterwards, > and that hurts. As we did not had any common "layout" to inherit, > every widget did the same code over and over again: Button, Checkbox, > Frame... all had text set on their own. Again, we lacked the > inheritance, then there was no other way than "move this to the base > widget operations" to solve the problem. Now we do have and we better > use it. Yep. Also, it's a good idea to take a look at GTK+'s docs. They actually did a nice job showing all the hierarchy and thus what functions you can hope to use. For example: http://developer.gnome.org/gtk/2.24/GtkButton.html -- Tom. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: glima trunk/elementary/src/lib
That's the idea. We also need to enhance our documentation like that. Thanks for the link! Daniel Juyung Seo (SeoZ) On Mon, May 14, 2012 at 4:13 PM, Tom Hacohen wrote: > On 13/05/12 18:14, Gustavo Sverzut Barbieri wrote: >> That's the single sane way to do it, and the case for every toolkit >> out there, be ObjC, C++ or C. The developer needs to understand the >> hierarchy in order to use, you can't call a method in a object that >> did not implement, but admittedly C makes it more cumbersome as you >> must type the namespace and class name, while C++ and ObjC does that >> for you. >> >> If you think about that now, although not having to think about the >> hierarchy to type the name, the user indeed needs to know if the >> object supports parts setting, and which. If you call part set on a >> box, it will do nothing. >> >> We could keep the backwards compatibility thing and do not deprecate >> it, but in my opinion it is bad because: >> >> Once we allow extending Elementary from outside, more libraries >> will create more components and these may have their own common >> methods. Imagine a library provides a base widget BW and dozen >> widgets, all with the same methods. You'll have some my_bw_method(). >> You cannot/should not create elm_object_method(), thus you'll generate >> some inconsistency here as out-of-library widgets can't use the same >> pattern. >> >> All in all the elm_object_ methods were mostly hacked in afterwards, >> and that hurts. As we did not had any common "layout" to inherit, >> every widget did the same code over and over again: Button, Checkbox, >> Frame... all had text set on their own. Again, we lacked the >> inheritance, then there was no other way than "move this to the base >> widget operations" to solve the problem. Now we do have and we better >> use it. > > Yep. Also, it's a good idea to take a look at GTK+'s docs. They actually > did a nice job showing all the hierarchy and thus what functions you can > hope to use. > > For example: > http://developer.gnome.org/gtk/2.24/GtkButton.html > > -- > Tom. > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch]Enable multisampling capacity on the evasgl
Hi Sanghee, I think we'll have to come up with a better way to differentiate between Low, Med, High in the future although... I do recognize that the GL_IMG_multisampled_render_to_texture isn't necessarily the best written GL extension. You can't exactly tell at what sample the driver is rendering. Anyway, the patch looks fine and I've tested it on an EGL target to verify that it works. In svn! Thanks for the patch. cheers, Sung On Mon, May 14, 2012 at 2:22 PM, sanghee park wrote: > Dear all, > > I compose this mail to ask reviewal this patch about multisampling on the > evasgl. > I want to make multisampling capacity to enhance rendering quality of the > evasgl. > But if MSAA is applied always, this have possibility lowering rendering > performance, > I separated user's input level to high, mid, low, none. > If you want to test this patch, try to examine rendering qulity on EGL > circumstance with multisampling level. > Plaese review it, and any suggestion will be appreciated. > > Best Regards, > SangHee > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: glima trunk/elementary/src/lib
On Mon, May 14, 2012 at 12:14 AM, Gustavo Sverzut Barbieri wrote: > On Thu, May 10, 2012 at 5:10 AM, Daniel Juyung Seo > wrote: >> Thanks for the great effort. >> But I have a question about this commit. >> >> It describes that >> - elm_object_xxx APIs will be deprecated later. Use elm_layout_xxx APIs >> instead. >> - all elm_layout_* namespaced fuctions will function on objects >> inheriting from this base: >> >> So it means to set the actionslider text, we will be using >> elm_layout_text_set(actionslider, "left", "Left"); >> Isn't this confusing for app developers? >> And app developers have to understand the inheritance structure of >> elementary. >> >> It will be great if you give me further explanation about this. > Hello, > That's the single sane way to do it, and the case for every toolkit > out there, be ObjC, C++ or C. The developer needs to understand the > hierarchy in order to use, you can't call a method in a object that > did not implement, but admittedly C makes it more cumbersome as you > must type the namespace and class name, while C++ and ObjC does that > for you. > > If you think about that now, although not having to think about the > hierarchy to type the name, the user indeed needs to know if the > object supports parts setting, and which. If you call part set on a > box, it will do nothing. > > We could keep the backwards compatibility thing and do not deprecate > it, but in my opinion it is bad because: > > Once we allow extending Elementary from outside, more libraries > will create more components and these may have their own common > methods. Imagine a library provides a base widget BW and dozen > widgets, all with the same methods. You'll have some my_bw_method(). > You cannot/should not create elm_object_method(), thus you'll generate > some inconsistency here as out-of-library widgets can't use the same > pattern. > > All in all the elm_object_ methods were mostly hacked in afterwards, > and that hurts. As we did not had any common "layout" to inherit, > every widget did the same code over and over again: Button, Checkbox, > Frame... all had text set on their own. Again, we lacked the > inheritance, then there was no other way than "move this to the base > widget operations" to solve the problem. Now we do have and we better > use it. > You're right. Thanks for the detail explanation. I wanted to understand the philosophy and direction of new elementary And now I confirm user needs to understand the hierarchy. By the way, does this scheme have performance degression? I am curious if there was a measure for the performance. > >> Anyhow, thanks for the great job. > > Glima is doing a nice work, but man it's being quite harder than we > anticipated. The problem is that some internals are completely upside > down given the "unplanned organic growth" of elementary. If we started > to create Elementary from scratch like that, we'd have less code and > by far less inconsistencies. For instance, the theme API breakage is > due that, some objects did not followed the same name scheme as the > others :-/ > Yes, that's sigh part. I can understand how glima had a hard time. Because even just reading the code is not easy. Thanks. Daniel Juyung Seo (SeoZ) > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] evas_ojbect_textblock, ellipsis handling
DEAR TOM, PLEASE REVIEW THIS. IT'S NOT MORNING. HAHAHA.. 2012/5/4 Kim Shinwoo : > Please leave your attention from the previous patch. > I have newly revised the patch on both backport and trunk. > > 2012/5/4 Kim Shinwoo : >> Dear Tom, >> >> I have attached a patch to make proper edje which uses the textblock >> with ellipsis! >> Please review the patch and keep it on upstream. >> >> Sincerely, >> Shinwoo Kim. >> >> 2012/5/4 Kim Shinwoo : >>> Dear Tom, Good afternoon again! ;p >>> I'm back with gd news!! The "fixed:1 x" resolved this issue >>> finally. Thank you for your help!! >>> >>> 2012/5/4 Kim Shinwoo : Dear Tom, Good afternoon! :p Thanks for your response. Tomorrow.. actually today.. I will check it with revised edje which has "fixed:1 x";. > maybe a calculation hmm.. it would be able to be caused by calculation, then we cannot say.. "Now, issue is resolved."? Doesn't the calculation problem occur, if I use the "fixed:1 x;"? then we can say.. "Now, issue is resolved."! Anyhow, test is the best way to check.. > I don't think it can easily be fixed, especially since it's currently > just a not supported behaviour. How would you expect it to behave? Does it mean "fixed: 0 x;" - textblock with ellipsis is used for sizing - ? yeap, we cannot expect the behavior.. ah.. delayed calculation.. dead lock.. :-/ I will be back. -.,-)=b Shinwoo Kim. 2012년 5월 3일 목요일에 Tom Hacohen님이 작성: > Dear Shinwoo, > > I've checked your issue and I indeed managed to reproduce it using your > patch (actually, only half of your patch was needed, the text was > enough, no need for the style). > > It's not really a textblock issue. It's just a matter of a bad edje, or > maybe a calculation, can't tell. The problem is that the size of the > textblock is very "unstable" because of the ellipsis. In such cases, the > textblock should not be used for sizing, so it must be defined as fixed: > 1 X; (height doesn't really matter, the width is the issue) as I > suggested before. > > I don't think it can easily be fixed, especially since it's currently > just a not supported behaviour. How would you expect it to behave? > > -- > Tom. > > On 24/04/12 05:29, cnook wrote: >> Dear Mr. Tom, >> >> Finally!! I have attacked patch for your example. To make the issue, >> please >> follow as below. >> >>elementary_test> popup> popup-center-title + text +1 button >> >> Then the popup needs some time to display itself with following log. >> >>ERR<32658>:evas_main evas_object_smart.c:599 >> evas_object_smart_need_recalculate_set() Object 0xb76d5df8 is not stable >> during recalc loop >>ERR<32658>:evas_main evas_object_smart.c:599 >> evas_object_smart_need_recalculate_set() Object 0xb76d5df8 is not stable >> during recalc loop >>... >> >> Please check this on the textblock side. Thanks a lot. >> >> Sincerely, >> Shinwoo Kim. >> >> 2011/11/21 Tom Hacohen >> >>> On 21/11/11 16:04, cnook wrote: >>> Dear Mr. Tom, The issue comes again with different example. So I have attached previous patch for resolving. (Actually I have made from the latest version) >>> >>> >>> Dear Shinwoo, >>> >>> As I said in a previous email to the list, a compilable example or an >>> edje >>> I can run with edje_player would be very appreciated. I currently can't >>> reproduce the issue and thus I can't even check you solution works (I >>> trust >>> you that it works, but still...), nor can I verify the problem. >>> >>> As for your patch: >>> >>> c->w will be smaller than c->wmax in A LOT of cases, that's actually >>> intentional, setting c->wmax to c->w makes no sense in textblock, as >>> it'll >>> break a lot of code. >>> >>> c->wmax is used to determine the actual *used* width, and c->w is the >>> width of the textblock object. >>> >>> So for example, if we have a textblock with a size of 300x300 and >>> assuming the string "a" * 100 (100 'a's in a row) have a width of 1000 >>> and >>> that the textblock contains that string: >>> c->w = 300; >>> c->wmax = 1000; >>> >>> Making edje know that 300 is just not enough to show this string. That's >>> how the min size calculation actually works. >>> >>> You can try adding "fixed: 1 1;" to the textblock part if you wish to >>> implement your behaviour, that's exactly what it does. >>> >>> >>> With that being said, there might be a bug there, as your condition >>> should >>> always be false in that place (or at least in the cases that matter), >>> and >>> for that, I need the example I asked for. :) >>> >
Re: [E-devel] [Patch] evas_ojbect_textblock, ellipsis handling
Hm... ? On 14/05/12 13:24, Kim Shinwoo wrote: > DEAR TOM, PLEASE REVIEW THIS. IT'S NOT MORNING. HAHAHA.. > > 2012/5/4 Kim Shinwoo: >> Please leave your attention from the previous patch. >> I have newly revised the patch on both backport and trunk. >> >> 2012/5/4 Kim Shinwoo: >>> Dear Tom, >>> >>> I have attached a patch to make proper edje which uses the textblock >>> with ellipsis! >>> Please review the patch and keep it on upstream. >>> >>> Sincerely, >>> Shinwoo Kim. >>> >>> 2012/5/4 Kim Shinwoo: Dear Tom, Good afternoon again! ;p I'm back with gd news!! The "fixed:1 x" resolved this issue finally. Thank you for your help!! 2012/5/4 Kim Shinwoo: > Dear Tom, Good afternoon! :p > Thanks for your response. Tomorrow.. actually today.. I will check it with > revised edje which has "fixed:1 x";. > >> maybe a calculation > hmm.. it would be able to be caused by calculation, then we cannot say.. > "Now, issue is resolved."? > Doesn't the calculation problem occur, if I use the "fixed:1 x;"? then we > can say.. "Now, issue is resolved."! > Anyhow, test is the best way to check.. > > >> I don't think it can easily be fixed, especially since it's currently >> just a not supported behaviour. How would you expect it to behave? > Does it mean "fixed: 0 x;" - textblock with ellipsis is used for sizing - > ? > yeap, we cannot expect the behavior.. ah.. delayed calculation.. dead > lock.. > :-/ > > I will be back. -.,-)=b > Shinwoo Kim. > > 2012년 5월 3일 목요일에 Tom Hacohen님이 작성: > >> Dear Shinwoo, >> >> I've checked your issue and I indeed managed to reproduce it using your >> patch (actually, only half of your patch was needed, the text was >> enough, no need for the style). >> >> It's not really a textblock issue. It's just a matter of a bad edje, or >> maybe a calculation, can't tell. The problem is that the size of the >> textblock is very "unstable" because of the ellipsis. In such cases, the >> textblock should not be used for sizing, so it must be defined as fixed: >> 1 X; (height doesn't really matter, the width is the issue) as I >> suggested before. >> >> I don't think it can easily be fixed, especially since it's currently >> just a not supported behaviour. How would you expect it to behave? >> >> -- >> Tom. >> >> On 24/04/12 05:29, cnook wrote: >>> Dear Mr. Tom, >>> >>> Finally!! I have attacked patch for your example. To make the issue, >>> please >>> follow as below. >>> >>> elementary_test> popup> popup-center-title + text +1 button >>> >>> Then the popup needs some time to display itself with following log. >>> >>> ERR<32658>:evas_main evas_object_smart.c:599 >>> evas_object_smart_need_recalculate_set() Object 0xb76d5df8 is not stable >>> during recalc loop >>> ERR<32658>:evas_main evas_object_smart.c:599 >>> evas_object_smart_need_recalculate_set() Object 0xb76d5df8 is not stable >>> during recalc loop >>> ... >>> >>> Please check this on the textblock side. Thanks a lot. >>> >>> Sincerely, >>> Shinwoo Kim. >>> >>> 2011/11/21 Tom Hacohen >>> On 21/11/11 16:04, cnook wrote: > Dear Mr. Tom, > > The issue comes again with different example. > So I have attached previous patch for resolving. (Actually I have made > from the latest version) > Dear Shinwoo, As I said in a previous email to the list, a compilable example or an edje I can run with edje_player would be very appreciated. I currently can't reproduce the issue and thus I can't even check you solution works (I trust you that it works, but still...), nor can I verify the problem. As for your patch: c->w will be smaller than c->wmax in A LOT of cases, that's actually intentional, setting c->wmax to c->w makes no sense in textblock, as it'll break a lot of code. c->wmax is used to determine the actual *used* width, and c->w is the width of the textblock object. So for example, if we have a textblock with a size of 300x300 and assuming the string "a" * 100 (100 'a's in a row) have a width of 1000 and that the textblock contains that string: c->w = 300; c->wmax = 1000; Making edje know that 300 is just not enough to show this string. That's how the min size calculation actually works. You can try adding "fixed: 1 1;" to the textblock part if you wish to implement your behaviour, that's exactly what it does. With that being said, there migh
Re: [E-devel] [Patch] evas_ojbect_textblock, ellipsis handling
On 04/05/12 08:15, Kim Shinwoo wrote: > Please leave your attention from the previous patch. > I have newly revised the patch on both backport and trunk. You accidentally included some irrelevant changelog information. Anyhow, it's in. Sorry for the time it took me, it somehow slipped between the chairs. In svn, commit: 70994 I didn't commit the backport, as I don't have a checkout of the backport ATM, someone please do it. -- Tom. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New elm internal code
* Tom Hacohen [2012-05-09 11:52:12 +0300]: > On 09/05/12 11:13, Daniel Juyung Seo wrote: > > Welcome back glima! > > Yes the tree has to be auto generated. > > It was time spending to draw that diagram. > > It's super easy to auto-generate... Just parse the smart class parent > from the source and put every pair in a dot file. Graphviz will take > care of the rest. Sure it is. I'll handle this job to a co-worker soon, so that I can concentrate on the porting work myself :) > > -- > Tom > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: glima trunk/elementary/src/lib
On Mon, May 14, 2012 at 6:19 AM, Daniel Juyung Seo wrote: > On Mon, May 14, 2012 at 12:14 AM, Gustavo Sverzut Barbieri > wrote: >> On Thu, May 10, 2012 at 5:10 AM, Daniel Juyung Seo >> wrote: >>> Thanks for the great effort. >>> But I have a question about this commit. >>> >>> It describes that >>> - elm_object_xxx APIs will be deprecated later. Use elm_layout_xxx APIs >>> instead. >>> - all elm_layout_* namespaced fuctions will function on objects >>> inheriting from this base: >>> >>> So it means to set the actionslider text, we will be using >>> elm_layout_text_set(actionslider, "left", "Left"); >>> Isn't this confusing for app developers? >>> And app developers have to understand the inheritance structure of >>> elementary. >>> >>> It will be great if you give me further explanation about this. >> > > Hello, > >> That's the single sane way to do it, and the case for every toolkit >> out there, be ObjC, C++ or C. The developer needs to understand the >> hierarchy in order to use, you can't call a method in a object that >> did not implement, but admittedly C makes it more cumbersome as you >> must type the namespace and class name, while C++ and ObjC does that >> for you. >> >> If you think about that now, although not having to think about the >> hierarchy to type the name, the user indeed needs to know if the >> object supports parts setting, and which. If you call part set on a >> box, it will do nothing. >> >> We could keep the backwards compatibility thing and do not deprecate >> it, but in my opinion it is bad because: >> >> Once we allow extending Elementary from outside, more libraries >> will create more components and these may have their own common >> methods. Imagine a library provides a base widget BW and dozen >> widgets, all with the same methods. You'll have some my_bw_method(). >> You cannot/should not create elm_object_method(), thus you'll generate >> some inconsistency here as out-of-library widgets can't use the same >> pattern. >> >> All in all the elm_object_ methods were mostly hacked in afterwards, >> and that hurts. As we did not had any common "layout" to inherit, >> every widget did the same code over and over again: Button, Checkbox, >> Frame... all had text set on their own. Again, we lacked the >> inheritance, then there was no other way than "move this to the base >> widget operations" to solve the problem. Now we do have and we better >> use it. >> > > You're right. Thanks for the detail explanation. > I wanted to understand the philosophy and direction of new elementary > And now I confirm user needs to understand the hierarchy. if we do a nice output as gtk does, it might solve. It would be nice to have an automated way of doing so, but if we don't then we can do it manually as the hierarchy shouldn't change in future. > By the way, does this scheme have performance degression? > I am curious if there was a measure for the performance. no hard measurements, but it should not degrade. It should actually improve, given that less function will be used, thus avoiding cache being polluted by similar code. Also less memory is used per widget (as methods move to class, instead of instance data). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/clouseau/src: . bin
2012/5/14 Enlightenment SVN : > Log: > clouseau: Created clouseau daemon clouseaud.c stab > > Signed-off-by: Aharon Hillel mixing up mail addresses here? > > Author: tasn > Date: 2012-05-14 07:37:38 -0700 (Mon, 14 May 2012) > New Revision: 71003 > Trac: http://trac.enlightenment.org/e/changeset/71003 > > Added: > trunk/clouseau/src/bin/ trunk/clouseau/src/bin/clouseaud.c > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Leif -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/clouseau/src: . bin
Hello. On 14/05/12 15:46, Leif Middelschulte wrote: > 2012/5/14 Enlightenment SVN: >> Log: >> clouseau: Created clouseau daemon clouseaud.c stab >> >> Signed-off-by: Aharon Hillel > mixing up mail addresses here? I would think he just pushed the changes into svn that Aharon made. As he works on Tasn'S team I would expect Tasn to review them and then push in. Sadly svn does not support --author to clarify such things. regards Stefan Schmidt -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/clouseau/src: . bin
What do you mean? That it's his old email address? Yeah, it's a pretty old commit. :) -- Tom. On 14/05/12 17:46, Leif Middelschulte wrote: > 2012/5/14 Enlightenment SVN: >> Log: >> clouseau: Created clouseau daemon clouseaud.c stab >> >> Signed-off-by: Aharon Hillel > mixing up mail addresses here? >> >> Author: tasn >> Date: 2012-05-14 07:37:38 -0700 (Mon, 14 May 2012) >> New Revision: 71003 >> Trac: http://trac.enlightenment.org/e/changeset/71003 >> >> Added: >> trunk/clouseau/src/bin/ trunk/clouseau/src/bin/clouseaud.c >> >> >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ___ >> enlightenment-svn mailing list >> enlightenment-...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][elm_map] Add elm_map_overlays_get & elm_map_overlay_visible_get
It works well, and pretty nice feature. diffs are good to me. In _overlay_show(Elm_Map_Overlay *overlay), there's many if statements. how about to change switch/case? On Fri, May 4, 2012 at 2:29 PM, Bluezery wrote: > Dear EFL developers, > > I want to add 2 new APIs (elm_map_overlays_get & elm_map_overlay_visible_get). > > There are no way to get the group overlays because group overlay, > something like virtual overlay, is created and deleted dynamically. > So elm_map_overlays_get returns total overlay's list and user can get > any type of overlays including group overlays. > Overlays which is grouped can not be visible. Because overlay grouping > is performed by elm_map, user do not know whether overlays are visible > or not. So elm_map_overlay_visible_get is added for this reason. > > Thanks > > -- > BRs, > Kim. > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/clouseau/src: . bin
2012/5/14 Tom Hacohen : > What do you mean? That it's his old email address? Yeah, it's a pretty old > commit. :) Yes, I was just referring to its outdated state. So people know who to contact if anything is wrong with this commit and won't get annoyed by undeliverable mails. > > -- > Tom. > > > On 14/05/12 17:46, Leif Middelschulte wrote: >> >> 2012/5/14 Enlightenment SVN: >>> >>> Log: >>> clouseau: Created clouseau daemon clouseaud.c stab >>> >>> Signed-off-by: Aharon Hillel >> >> mixing up mail addresses here? >>> >>> >>> Author: tasn >>> Date: 2012-05-14 07:37:38 -0700 (Mon, 14 May 2012) >>> New Revision: 71003 >>> Trac: http://trac.enlightenment.org/e/changeset/71003 >>> >>> Added: >>> trunk/clouseau/src/bin/ trunk/clouseau/src/bin/clouseaud.c >>> >>> >>> >>> -- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> ___ >>> enlightenment-svn mailing list >>> enlightenment-...@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn >> >> >> >> > -- Leif -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Wayland: Port to latest input protocol
The Wayland protocol has changed to used a fixed point representation for positions on the input events. The attached patch adapts the implementation in Ecore to convert to integers where necessary. Cheers, Rob 0001-Ecore_Evas-wayland-Adapt-input-handlers-to-reflect-p.patch Description: Binary data -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/clouseau/src: . bin
On 14/05/12 18:00, Leif Middelschulte wrote: > 2012/5/14 Tom Hacohen: >> What do you mean? That it's his old email address? Yeah, it's a pretty old >> commit. :) > Yes, I was just referring to its outdated state. So people know who to > contact if anything is wrong with this commit and won't get annoyed by > undeliverable mails. Ahh, I just noticed he forgot to update his email address. I thought it was like that only for the old commits, but you are right, it's for all of them. :| -- Tom. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Wayland: Enable vertical/horizontal mouse wheel scrolling
Ecore_wayland: Support vertical/horizontal scrolling Set the direction on the event based on the axis (horizontal/vertical) and z value based on the negative of the value from the compositor. This results in scrolling that is consistent with the X11 implementation. Cheers, Rob 0001-Ecore_wayland-Support-vertical-horizontal-scrolling.patch Description: Binary data -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ 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/edje: . src/lib
* Enlightenment SVN [2012-05-09 22:37:38 -0700]:
> Log:
> edje: preserve user box and table items during call of edje_object_file_set.
>
> NOTE: now you can change theme dynamically in elementary apps more reliably.
> This doesn't handle the case where the swallow was done in a parent object
> and
> the reswallow should happen in a another group. I don't how to fix that use
> case.
> don't see yet how to handle that
Really nice that you've done that :) I don't think that's the cited
case above, so here's a bug: try elm "layout 2" test and go back and
forth b&w and detorious-elm -- the table section is not maintained as
the box one.
>
>
> Author: cedric
> Date: 2012-05-09 22:37:38 -0700 (Wed, 09 May 2012)
> New Revision: 70901
> Trac: http://trac.enlightenment.org/e/changeset/70901
>
> Modified:
> trunk/edje/ChangeLog trunk/edje/NEWS trunk/edje/src/lib/edje_load.c
>
> Modified: trunk/edje/ChangeLog
> ===
> --- trunk/edje/ChangeLog 2012-05-10 05:06:51 UTC (rev 70900)
> +++ trunk/edje/ChangeLog 2012-05-10 05:37:38 UTC (rev 70901)
> @@ -434,3 +434,7 @@
> * Check that the file changed on disk when trying to reopen it.
> * Emit ['edje,change,file', 'edje'] when the file change on disk.
> * Automatically reload edje file when it change in edje_player.
> +
> +2012-05-10 Cedric Bail
> +
> + * Preserve user box and table items during call of edje_object_file_set.
>
> Modified: trunk/edje/NEWS
> ===
> --- trunk/edje/NEWS 2012-05-10 05:06:51 UTC (rev 70900)
> +++ trunk/edje/NEWS 2012-05-10 05:37:38 UTC (rev 70901)
> @@ -15,6 +15,7 @@
> * Add missing files in the tarballs.
> * Prevent crash when running nested edje_object_signal_emit with
> edje_object_signal_callback_{add,del}.
> * Do actually verify that the file on disk is different from the file we
> have loaded.
> +* Preserve user bix and table items during call of edje_object_file_set.
>
> Edje 1.2.0
>
>
> Modified: trunk/edje/src/lib/edje_load.c
> ===
> --- trunk/edje/src/lib/edje_load.c2012-05-10 05:06:51 UTC (rev 70900)
> +++ trunk/edje/src/lib/edje_load.c2012-05-10 05:37:38 UTC (rev 70901)
> @@ -1,5 +1,16 @@
> #include "edje_private.h"
>
> +typedef struct _Edje_Table_Items Edje_Table_Items;
> +struct _Edje_Table_Items
> +{
> + Evas_Object *child;
> + const char *part;
> + unsigned short col;
> + unsigned short row;
> + unsigned short colspan;
> + unsigned short rowspan;
> +};
> +
> #ifdef EDJE_PROGRAM_CACHE
> static Eina_Bool _edje_collection_free_prog_cache_matches_free_cb(const
> Eina_Hash *hash, const void *key, void *data, void *fdata);
> #endif
> @@ -7,6 +18,8 @@
> static void _cb_signal_repeat(void *data, Evas_Object *obj, const char
> *signal, const char *source);
>
> static Eina_List *_edje_swallows_collect(Edje *ed);
> +static Eina_List *_edje_box_items_collect(Edje *ed);
> +static Eina_List *_edje_table_items_collect(Edje *ed);
>
> /** API Routines **/
>
> @@ -281,6 +294,8 @@
> Eina_List *sources = NULL;
> Eina_List *externals = NULL;
> Eina_List *old_swallows;
> + Eina_List *old_table_items;
> + Eina_List *old_box_items;
> unsigned int n;
> Eina_List *parts = NULL;
> int group_path_started = 0;
> @@ -304,6 +319,8 @@
> tev = evas_object_evas_get(obj);
> evas_event_freeze(tev);
> old_swallows = _edje_swallows_collect(ed);
> + old_table_items = _edje_table_items_collect(ed);
> + old_box_items = _edje_box_items_collect(ed);
>
> if (_edje_script_only(ed)) _edje_script_only_shutdown(ed);
> if (_edje_lua_script_only(ed)) _edje_lua_script_only_shutdown(ed);
> @@ -844,6 +861,39 @@
> }
> }
>
> + if (old_box_items)
> + {
> + while (old_box_items)
> +{
> + const char *name;
> + Evas_Object *child;
> +
> + name = eina_list_data_get(old_box_items);
> + old_box_items = eina_list_remove_list(old_box_items,
> old_box_items);
> +
> + child = eina_list_data_get(old_box_items);
> + old_box_items = eina_list_remove_list(old_box_items,
> old_box_items);
> +
> + edje_object_part_box_append(obj, name, child);
> + eina_stringshare_del(name);
> +}
> + }
> +
> + if (old_table_items)
> + {
> + Edje_Table_Items *item;
> +
> + EINA_LIST_FREE(old_table_items, item)
> +{
> + edje_object_part_table_pack(obj,
> +
Re: [E-devel] [PATCH] python-elementary: Align Window to C api.
Great, thanks! in rev 71083. davemds 2012/5/14 Kai Huuhko > --- > python-elementary/elementary/__init__.py | 28 + > .../elementary/elementary.c_elementary_window.pxi | 625 > +++- > .../include/elementary/c_elementary.pxd| 85 ++- > 3 files changed, 596 insertions(+), 142 deletions(-) > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric branches/elementary-1.0/src/lib
Arghh, sorry, my fault.
Ok, now we are destroying the 1.0 branch! also your fix is wrong :(
atm this code is working only because Listing_Request struct and
Widget_Request struct
have the same first field (Widget_Data), but the void* is wrong! we are
accessing
Widget_Request->wd instead of Listing_Request->sd.
I think we should revert both commit and don't make this backport again.
no?
davemds
2012/5/14 Enlightenment SVN
> Log:
> elementary: fix backport 70967 and close bug #1008.
>
>
> Author: cedric
> Date: 2012-05-13 17:25:09 -0700 (Sun, 13 May 2012)
> New Revision: 70980
> Trac: http://trac.enlightenment.org/e/changeset/70980
>
> Modified:
> branches/elementary-1.0/src/lib/elc_fileselector.c
>
> Modified: branches/elementary-1.0/src/lib/elc_fileselector.c
> ===
> --- branches/elementary-1.0/src/lib/elc_fileselector.c 2012-05-14
> 00:12:17 UTC (rev 70979)
> +++ branches/elementary-1.0/src/lib/elc_fileselector.c 2012-05-14
> 00:25:09 UTC (rev 70980)
> @@ -71,6 +71,17 @@
>Eina_Bool first : 1;
> };
>
> +typedef struct _Listing_Request Listing_Request;
> +struct _Listing_Request
> +{
> + Widget_Data *sd;
> + Elm_Object_Item *parent_it;
> +
> + Evas_Object *obj;
> + const char *path;
> + Eina_Bool first : 1;
> +};
> +
> typedef enum {
> ELM_DIRECTORY = 0,
> ELM_FILE_IMAGE = 1,
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][elm_map] Add elm_map_overlays_get & elm_map_overlay_visible_get
2012/5/14 Hyoyoung Chang : > It works well, and pretty nice feature. > diffs are good to me. > > In _overlay_show(Elm_Map_Overlay *overlay), > there's many if statements. how about to change switch/case? Thank you for your comments :) Yes, "switch" looks better than "if" in this case. I fixed that. And Merged NEWS, Changelog also. Please review again. > > On Fri, May 4, 2012 at 2:29 PM, Bluezery wrote: >> Dear EFL developers, >> >> I want to add 2 new APIs (elm_map_overlays_get & >> elm_map_overlay_visible_get). >> >> There are no way to get the group overlays because group overlay, >> something like virtual overlay, is created and deleted dynamically. >> So elm_map_overlays_get returns total overlay's list and user can get >> any type of overlays including group overlays. >> Overlays which is grouped can not be visible. Because overlay grouping >> is performed by elm_map, user do not know whether overlays are visible >> or not. So elm_map_overlay_visible_get is added for this reason. >> >> Thanks >> >> -- >> BRs, >> Kim. >> >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- BRs, Kim. map@overlay_api_2.diff Description: Binary data -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ 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/edje: . src/lib
On Tue, May 15, 2012 at 1:35 AM, Gustavo Lima Chaves wrote: > * Enlightenment SVN [2012-05-09 22:37:38 -0700]: > >> Log: >> edje: preserve user box and table items during call of edje_object_file_set. >> >> NOTE: now you can change theme dynamically in elementary apps more >> reliably. >> This doesn't handle the case where the swallow was done in a parent object >> and >> the reswallow should happen in a another group. I don't how to fix that use >> case. >> don't see yet how to handle that > > Really nice that you've done that :) I don't think that's the cited > case above, so here's a bug: try elm "layout 2" test and go back and > forth b&w and detorious-elm -- the table section is not maintained as > the box one. Yep, I know that test ! I have been looking at fixing all of this issue due to my change to edje. Try edje_watch on elementary theme, change the edc, see it recompile the edj (slowly) and then reload it automatically in elementary_test. Then a few things are reset or lost when they shouldn't. That what I am trying to fix at the moment. So yes, this table layout is on my todo list to. And it's a weird one ! -- Cedric BAIL -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric branches/elementary-1.0/src/lib
On Tue, May 15, 2012 at 7:13 AM, Davide Andreoli wrote: > Arghh, sorry, my fault. > > Ok, now we are destroying the 1.0 branch! also your fix is wrong :( > > atm this code is working only because Listing_Request struct and > Widget_Request struct > have the same first field (Widget_Data), but the void* is wrong! we are > accessing > Widget_Request->wd instead of Listing_Request->sd. > > I think we should revert both commit and don't make this backport again. > > no? Arg ! Could you try to fix it for real ? And yes, this kind of issue is now complex due to the amount of change between trunk and branch. So I am also ok, if we just revert the fix. -- Cedric BAIL -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: glima trunk/elementary/src/lib
On Sun, 13 May 2012 12:14:37 -0300 Gustavo Sverzut Barbieri wrote: > On Thu, May 10, 2012 at 5:10 AM, Daniel Juyung Seo > wrote: > The problem is that some internals are completely upside down given > the "unplanned organic growth" of elementary. If we started to create > Elementary from scratch like that, we'd have less code and by far > less inconsistencies. Yes, that's always been my problem with elementary. I'm trying it out on a little project now though. I'm happy that people are looking at how to beat it into saner shape now, though not happy that this effort might be hobbled by having to not break API now that it's released. Oh well, ten years ago I described the proper way to do a widget set, but no one was interested. Now it's not even on the web any more. Some day I might actually do it. lol For an upcoming really huge project, I'm thinking about reimplementing parts of that system I created that unwritten widget set design for. For this project I also have to deal with someone else's really lousy UI system (I need to automate translation to something sane). I may yet write that widget set on top of edje. Gotta start by rewriting the old project into C first. sigh /me stops hijacking this thread and wanders off for brekky. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Wayland: Enable vertical/horizontal mouse wheel scrolling
Thanks Robert :) I will have a look at these today. I still do not have my svn firewall exception at work yet so I cannot commit these just yet, but I will combine them with the changes I have here locally, and when I can finally commit stuff from work, then it will go in along with the other changes that I have awating. Cheers, dh - Original Message - From: "Robert Bradford" To: "Enlightenment developer list" Sent: Monday, May 14, 2012 5:32:25 PM Subject: [E-devel] Wayland: Enable vertical/horizontal mouse wheel scrolling Ecore_wayland: Support vertical/horizontal scrolling Set the direction on the event based on the axis (horizontal/vertical) and z value based on the negative of the value from the compositor. This results in scrolling that is consistent with the X11 implementation. Cheers, Rob -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
