Re: [E-devel] EFL Portability (need BSD, Solaris and Windows input!)
Hi Gustavo, I'd have to agree with you on how the includes should be done, the only issue I see is that there are some things that you just can't do that way. Without actually testing, I can't guarantee it will just work, but from what I remember, we had to include Escape.h in some places because of some missing defines. In the case of the ps3, there is a unistd.h file but it doesn't have everything, that's why we have escape_unistd.h. The #include_next trick that Lucas suggested could fix that and it's a great idea. Looking at Escape.h, what I see though is that there's a define for some of the CLOCK_* macros, the _UNUSED_ macro and the EAPI macro. I'm guessing the _UNUSED_ and EAPI are not defined maybe because the configure takes care of that in the config.h and it doesn't recognize the system in order to determine how it should be set, that's why I had to add them in Escape.h. As for the CLOCK_* defines, I guess they could go in their own .h and another #include_next would do the trick in this case. The problem remains that you still need to have a Escape.h file in order to do the #include_next call.. and honestly, I don't see how a diff of : -#include escape_unistd.h +#include_next unistd.h would make any real difference in the end... There are however some things that might need to react differently whether or not the platform supports it. For example, on the ps3, there is no multiprocess support, so execv, signals, and all that don't exist. It makes more sense to have #ifdefs in the EFL to handle such a case rather than assume it works and do things as if it was working, and have the compatibility layer just return errors or something. I know this multi-process thing is an extreme case and it's probably best not to have special code for it in the EFL (and I'd agree), but it's just the example that I have off the top of my head. There might be other cases where it's best to handle them differently rather than try to work around it. Just my 2c. KaKaRoTo On Thu, Jan 3, 2013 at 1:40 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Thu, Jan 3, 2013 at 12:34 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hi people, I'm reviewing the checks in efl/configure.ac and some are quite weird, which I want to remove if there is no valid reason for their existence. IMO the way Evil, Escape and Exotic are done are a bit cumbersome for the libraries to use. For instance, evil_libgen.h matches libgen.h, however the user code must have the following: #ifdef HAVE_LIBGEN_H #include libgen.h #endif ... #ifdef HAVE_EVIL #include Evil.h /* includes evil_libgen.h */ #endif why not call evil_libgen.h just libgen.h and let the user include it normally? We just -I$(top_srcdir)/src/lib/evil if building for Evil, then it makes life simpler. In my mind Evil.h and Exotic. doesn't even need to exist... they could exist in some cases where the system file exists but lacks something. Say libgen.h in PS3 lacked basename, then we could have: * escape_libgen.h: basename() definition * Escape.h: includes escape_libgen.h to match complete libgen.h or you use #include_next libgen.h inside Escape's libgen.h and don't bother with never ever creating Escape.h http://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html Not sure if other compilers support this, though Lucas De Marchi -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/bin
Hello again, So I looked at the 1.7 branch and the code there is very different so the bug wasn't in it. The trunk uses a hash table with a free function that frees the Part_Lookup structure, and the bug was that it was manually freeing one item without removing it from the hash table. In 1.7, it's actually using a list, and the hashtable is created with eina_hash_string_superfast_new (so, no free func) and it actually removes it from that hash table when it frees it. Basically, the bug in trunk was a side-effect/remnant from the refactoring of the code from the branch.. so there is no need to backport it. On Wed, Nov 28, 2012 at 1:46 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Oh cool, I'll backport it tomorrow! Thanks! I never realized there were branches, I thought new releases were always taken from the trunk! Thanks for the answers! On Tue, Nov 27, 2012 at 9:59 PM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 27 Nov 2012 11:45:20 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: Backported? Sorry, what do you mean ? Are there different development branches now ? (I haven't paid much attention to E develpment lately) If yes, then yeah, it should be backported as it's a critical fix in my opinion. look in branches (not in trunk)... we have a branch per stable release of efl where we backport to.. thats how 1.7.1 and 1.7.2 come out.. from the stable branch. we've done this since 1.0 :) not new. :) On Mon, Nov 26, 2012 at 4:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Nov 24, 2012 at 8:15 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: edje: Fix segfault when deleted part stays in the hash table Shouldn't that be backported ? -- Cedric BAIL -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ 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 -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/bin
Backported? Sorry, what do you mean ? Are there different development branches now ? (I haven't paid much attention to E develpment lately) If yes, then yeah, it should be backported as it's a critical fix in my opinion. On Mon, Nov 26, 2012 at 4:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Nov 24, 2012 at 8:15 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: edje: Fix segfault when deleted part stays in the hash table Shouldn't that be backported ? -- Cedric BAIL -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/bin
Oh cool, I'll backport it tomorrow! Thanks! I never realized there were branches, I thought new releases were always taken from the trunk! Thanks for the answers! On Tue, Nov 27, 2012 at 9:59 PM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 27 Nov 2012 11:45:20 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: Backported? Sorry, what do you mean ? Are there different development branches now ? (I haven't paid much attention to E develpment lately) If yes, then yeah, it should be backported as it's a critical fix in my opinion. look in branches (not in trunk)... we have a branch per stable release of efl where we backport to.. thats how 1.7.1 and 1.7.2 come out.. from the stable branch. we've done this since 1.0 :) not new. :) On Mon, Nov 26, 2012 at 4:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Nov 24, 2012 at 8:15 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: edje: Fix segfault when deleted part stays in the hash table Shouldn't that be backported ? -- Cedric BAIL -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ 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 -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/GAMES/eskiss/data/edje
Ah ok, thanks for the clarification. Issue was that edje_cc complains now with an error, so eskiss wasn't compiling anymore. On Sat, Jul 21, 2012 at 4:28 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sat, Jul 21, 2012 at 1:50 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Eskiss: default part type is not RECT anymore so we need to explicitely specify it actually it was never rect, but image. But images were handled exactly like rects in the clipper case. We expect to have special case to clip to images some day, so the warning right now. -- 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] [e-users] Exquisite bootsplash release
Resuscitating this old thread... It's now done and committed to SVN. If there are any issues with it, or ideas of things to potentially add, now might be a good time. As discussed previously, I've taken the opportunity to also modify the tags used by the theme, using success and failure tags instead of the enum's 0 and 1 tags. I think it makes it much clearer this way. However, I found a bug in edje's style handling and I filed a new ticket about it here : http://trac.enlightenment.org/e/ticket/1198 I also fixed a small 'bug' with usage of snprintf which was : snprintf(s, strlen(t-status_text)+5, %sbr/, t-status_text); Making it safer this way : snprintf(s, sizeof(buf2)-strlen(buf2), %sbr/, t-status_text); (since 's' is a pointer to somwhere within buf2) I think I'll blog about it if that's fine with everyone.. That's it, enjoy :) KaKaRoTo On Mon, Feb 20, 2012 at 5:09 AM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 20 Feb 2012 04:00:16 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sun, Feb 19, 2012 at 11:44 PM, Carsten Haitzler ras...@rasterman.comwrote: On Fri, 17 Feb 2012 01:16:12 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: (FYI: for those who didn't read from IRC, when Carsten realized I meant to transform exquisite into a library+tools, and not add a new library to the set, he agreed to it). yeah. yet-another-lib was something we really dont need atm - and it's better rolled into an existing one, but since it'd just be a lib provided by exquisite - moving its own functions into that lib and thus providing it for others to use too - that's not bad. So I've done it, just finished, but I have a couple of questions : - what should I use for creating an object? exquisite_object_add, or exquisite_object_new ? I think _add makes more sense and follows with the edje API. _add. - What version should I give it ? Should I keep it to 1.0.0 (or 1.0.99 to be more exact), or bump it to match the core efl libs versions (1.1.99)? same version as exquisite. so 1.0.0 - we'll have to bump that for a release tho. - Do you have any documentation written for exquisite that I could reuse? Especially with regards to the format to follow for creating themes for it? nup. as it was all internal to exquisite (the api anyway), and for themes - well none other than here's an example. follow and repeat Ok, well, I'll try to write documentation for how to write themes while I'm doing it for the API. - Why is the tag 1 for success and 0 for failure in the edc, why not success failure ? Would make it more logical, and I can use an enum for the status without hardcoding the values of the enum. if you want to change it, now's the time. but 0 or 1 is just a simpler more compact way of handling the enums as all enums boil down to numbers anyway :) Ok, I think I'd rather change it if you're ok with it. Would also like to allow for normal tag rather than assume it doesn't have any style modifiers. Are there any themes out there for exquisite (other than default) that might be affected? none i know of. - There seems to be a bug in the default theme, where the last line of text appears cropped after you add a text, I just tried with ./run-demo.sh and part of the last text is cropped after adding one line, then a bigger part after adding another line, then the last lines don't even show up. I tracked it to the shift_text embryo script in the edj, which does y = y - 8; however, the font size is not fixed to 8 pixels height, I changed it to y - 13 and it worked. A better solution must be used to make sure the text always shows independently of your default font size or whatever might affect it. yeah. that's a theme bug there - it should do text scrolling another way. If you find a better way, let me know so it gets fixed at the same time. Thanks, KaKaRoTo On Tue, Feb 14, 2012 at 12:25 AM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 14 Feb 2012 00:07:38 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: well it's more because it really has very little additional beyond a progressbar and it functions for the same purpose - it just can have a large fill my window style. :) Humm... it may go as a widget in elementary, although it seems more like a megawidget than a simple generic widget, so I'm not sure its place is inside elementary. But you know best what should go in there. I however do not use elementary for the ps3 (because it hasn't been fully ported yet) so I prefer to stay with pure edje. And since exquisite is already written.. it's not much trouble to expose its functions
Re: [E-devel] [e-users] Exquisite bootsplash release
On Sun, Feb 19, 2012 at 11:44 PM, Carsten Haitzler ras...@rasterman.comwrote: On Fri, 17 Feb 2012 01:16:12 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: (FYI: for those who didn't read from IRC, when Carsten realized I meant to transform exquisite into a library+tools, and not add a new library to the set, he agreed to it). yeah. yet-another-lib was something we really dont need atm - and it's better rolled into an existing one, but since it'd just be a lib provided by exquisite - moving its own functions into that lib and thus providing it for others to use too - that's not bad. So I've done it, just finished, but I have a couple of questions : - what should I use for creating an object? exquisite_object_add, or exquisite_object_new ? I think _add makes more sense and follows with the edje API. _add. - What version should I give it ? Should I keep it to 1.0.0 (or 1.0.99 to be more exact), or bump it to match the core efl libs versions (1.1.99)? same version as exquisite. so 1.0.0 - we'll have to bump that for a release tho. - Do you have any documentation written for exquisite that I could reuse? Especially with regards to the format to follow for creating themes for it? nup. as it was all internal to exquisite (the api anyway), and for themes - well none other than here's an example. follow and repeat Ok, well, I'll try to write documentation for how to write themes while I'm doing it for the API. - Why is the tag 1 for success and 0 for failure in the edc, why not success failure ? Would make it more logical, and I can use an enum for the status without hardcoding the values of the enum. if you want to change it, now's the time. but 0 or 1 is just a simpler more compact way of handling the enums as all enums boil down to numbers anyway :) Ok, I think I'd rather change it if you're ok with it. Would also like to allow for normal tag rather than assume it doesn't have any style modifiers. Are there any themes out there for exquisite (other than default) that might be affected? - There seems to be a bug in the default theme, where the last line of text appears cropped after you add a text, I just tried with ./run-demo.sh and part of the last text is cropped after adding one line, then a bigger part after adding another line, then the last lines don't even show up. I tracked it to the shift_text embryo script in the edj, which does y = y - 8; however, the font size is not fixed to 8 pixels height, I changed it to y - 13 and it worked. A better solution must be used to make sure the text always shows independently of your default font size or whatever might affect it. yeah. that's a theme bug there - it should do text scrolling another way. If you find a better way, let me know so it gets fixed at the same time. Thanks, KaKaRoTo On Tue, Feb 14, 2012 at 12:25 AM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 14 Feb 2012 00:07:38 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: well it's more because it really has very little additional beyond a progressbar and it functions for the same purpose - it just can have a large fill my window style. :) Humm... it may go as a widget in elementary, although it seems more like a megawidget than a simple generic widget, so I'm not sure its place is inside elementary. But you know best what should go in there. I however do not use elementary for the ps3 (because it hasn't been fully ported yet) so I prefer to stay with pure edje. And since exquisite is already written.. it's not much trouble to expose its functions into a header. So if you don't need/want it in elementary yourself, then don't bother since I probably won't be using it anyways. Thanks On Mon, Feb 13, 2012 at 4:07 AM, Carsten Haitzler ras...@rasterman.com wrote: On Mon, 13 Feb 2012 03:46:22 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: hmm well if mainloop is alive... making an elementary widget would be the way to go... :) call it the splash widget - u can fill a window with it, just put it on the left/bottom half of your screen/window or whatever. :) it's really more of a progressbar PLUS a few more text fields that pb doesnt have... in fact u can do all of it with progressbars and setting text elements in the progressbar if we added another 1. you can do the end anim with signal emits - in fact u'd want the callback when done and an api for this... i'd actually suggest adding some more features to progressbar as above and adding this as a style for it. only thing then is the text log scroll - should this be in progressbar or not - do you want/need it? Yes, I've read the code, I know how small and easy it is, however, if there's a library
Re: [E-devel] EFL documentation
Good stuff! :) Any chance this will cover internals too (maybe as a secondary objective) ? While the public API is generally well documented, internal APIs aren't. I'm referring anyways to the difficulty to understand how to write a new evas engine for example. On Fri, Feb 17, 2012 at 3:22 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Fri, 17 Feb 2012 11:40:38 -0200 Jonas M. Gastal jgas...@profusion.mobi wrote: Hello all, ProFUSION, sponsored by Samsung, is starting a documentation project(yes, another one =). This means we'll be going over any pieces of documentation we fell are incomplete or that could use some improvement and give it some work. The EFL though is huge and we could use everyone's help. In this spirit I'd like to kindly ask everyone who commits new code to document it and, even more importantly, whenever you cause a behaviour change remember to change the documentation! Happy coding, Gastal any chance this will cover ecore-x? there's zero documentation there. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Exquisite bootsplash release
(FYI: for those who didn't read from IRC, when Carsten realized I meant to transform exquisite into a library+tools, and not add a new library to the set, he agreed to it). So I've done it, just finished, but I have a couple of questions : - what should I use for creating an object? exquisite_object_add, or exquisite_object_new ? I think _add makes more sense and follows with the edje API. - What version should I give it ? Should I keep it to 1.0.0 (or 1.0.99 to be more exact), or bump it to match the core efl libs versions (1.1.99)? - Do you have any documentation written for exquisite that I could reuse? Especially with regards to the format to follow for creating themes for it? - Why is the tag 1 for success and 0 for failure in the edc, why not success failure ? Would make it more logical, and I can use an enum for the status without hardcoding the values of the enum. - There seems to be a bug in the default theme, where the last line of text appears cropped after you add a text, I just tried with ./run-demo.sh and part of the last text is cropped after adding one line, then a bigger part after adding another line, then the last lines don't even show up. I tracked it to the shift_text embryo script in the edj, which does y = y - 8; however, the font size is not fixed to 8 pixels height, I changed it to y - 13 and it worked. A better solution must be used to make sure the text always shows independently of your default font size or whatever might affect it. Thanks, KaKaRoTo On Tue, Feb 14, 2012 at 12:25 AM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 14 Feb 2012 00:07:38 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: well it's more because it really has very little additional beyond a progressbar and it functions for the same purpose - it just can have a large fill my window style. :) Humm... it may go as a widget in elementary, although it seems more like a megawidget than a simple generic widget, so I'm not sure its place is inside elementary. But you know best what should go in there. I however do not use elementary for the ps3 (because it hasn't been fully ported yet) so I prefer to stay with pure edje. And since exquisite is already written.. it's not much trouble to expose its functions into a header. So if you don't need/want it in elementary yourself, then don't bother since I probably won't be using it anyways. Thanks On Mon, Feb 13, 2012 at 4:07 AM, Carsten Haitzler ras...@rasterman.com wrote: On Mon, 13 Feb 2012 03:46:22 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: hmm well if mainloop is alive... making an elementary widget would be the way to go... :) call it the splash widget - u can fill a window with it, just put it on the left/bottom half of your screen/window or whatever. :) it's really more of a progressbar PLUS a few more text fields that pb doesnt have... in fact u can do all of it with progressbars and setting text elements in the progressbar if we added another 1. you can do the end anim with signal emits - in fact u'd want the callback when done and an api for this... i'd actually suggest adding some more features to progressbar as above and adding this as a style for it. only thing then is the text log scroll - should this be in progressbar or not - do you want/need it? Yes, I've read the code, I know how small and easy it is, however, if there's a library for it, then apps could reuse the same .edc from other apps, it would give a sort of 'standard' way of doing this kind of splash screens, with a standard set of features, and a set of themes for it that people can reuse.. and obviously, if someone wants it a bit different, they can always just do their own edc instead. I just saw exquisite (release announcement on planet E) and thought it was cool, wanted to look at the API then realized it was an app, and I thought it would be better as a lib. As for uses, I do have a use for it, there are many tools for the PS3 that take a while and do many things but have no output on the screen and I thought they could benefit from that, like the messages dumping ram, patching kernel, flashing NAND, formatting flash, etc.. as well as having a progress bar.. Telling someone (who has no idea what the EFL even is) to write an EDC and set up his canvas and send signals, etc.. just for a progress bar or for printing a message on screen is a big turn off. Also, I think games may benefit from it, it's not always about boot time, but it would be for loading game levels for example, you often see a Loading screen in games, and this could be used for example. And for my immediate use, I have a tool that unzips largs packages into the PS3 HDD and I'd like to use it as a progress bar for when I unzip files, it could be used for the progress
Re: [E-devel] [e-users] Exquisite bootsplash release
Yes, I've read the code, I know how small and easy it is, however, if there's a library for it, then apps could reuse the same .edc from other apps, it would give a sort of 'standard' way of doing this kind of splash screens, with a standard set of features, and a set of themes for it that people can reuse.. and obviously, if someone wants it a bit different, they can always just do their own edc instead. I just saw exquisite (release announcement on planet E) and thought it was cool, wanted to look at the API then realized it was an app, and I thought it would be better as a lib. As for uses, I do have a use for it, there are many tools for the PS3 that take a while and do many things but have no output on the screen and I thought they could benefit from that, like the messages dumping ram, patching kernel, flashing NAND, formatting flash, etc.. as well as having a progress bar.. Telling someone (who has no idea what the EFL even is) to write an EDC and set up his canvas and send signals, etc.. just for a progress bar or for printing a message on screen is a big turn off. Also, I think games may benefit from it, it's not always about boot time, but it would be for loading game levels for example, you often see a Loading screen in games, and this could be used for example. And for my immediate use, I have a tool that unzips largs packages into the PS3 HDD and I'd like to use it as a progress bar for when I unzip files, it could be used for the progress bar as well as for listing the files being unpacked. And yeah, the app is alive and running the mainloop in those use cases, and unzipping 1GB takes time I was going to implement a progress bar+messages system in my code, and write the edc and write a spec for people to retheme it, etc... but since I've seen exquisite, I don't think it's worth it to rewrite the same thing when I could just reuse existing code. Any suggestions on how you'd like me to proceed ? or should I just go and do it (I'll probably do it tomorrow). Thanks, KaKaRoTo On Mon, Feb 13, 2012 at 2:03 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 12 Feb 2012 07:13:39 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: ummm... if an app wants to do this its as easy as loading an edje obj and sending signals/setting text and dragables. that's a VERY thin library there. you want this for app splashes while apps start up? are the apps that start actually alive and running the mainloop for a long period before they are usable? This looks pretty good! I've been thinking that this could be used for applications as well, not just for the init scripts. So I'm thinking of modifying exquisite into a libexquisite (which the exquisite tool itself would use). It's basically just about having a way of creating an exquisite (edje) object and translating those IPC commands into API functions. I think it could be used by apps for doing progress bars (with a sort of 'standard' edje specs) and generic splash screens (for games loading levels and stuff like that). What do you think ? Any suggestions before I start ? KaKaRoTo On Fri, Feb 10, 2012 at 4:37 AM, P Purkayastha ppu...@gmail.com wrote: On Friday, February 10, 2012 4:40:33 PM UTC+8, The Rasterman Carsten Haitzler wrote: On Thu, 9 Feb 2012 23:04:00 -0800 (PST) P Purkayastha ppu...@gmail.com said: Is there some guide on how to set this up? I know that Exquisite has existed for many years but I could never set it up due to the lack of a noobie-friendly guide. read README? look at the run-demo.sh as such you only want to be integrating this into a boot if you know your boot stuff (systemd/systvinit/whatever) and you need to put the status writes into your startup scripts or modify systemd to do it for you. (write to fifo or scoket directly). other than that u need to hack up all your init setup to start exquisite before everything else (and make sure efl libs are available to it at that time) and then send status and done messages from your init scripts or whatever. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com Ah yeah. Now I remember why I didn't pursue it further. I wasn't comfortable with hacking init scripts. :) -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Exquisite bootsplash release
Humm... it may go as a widget in elementary, although it seems more like a megawidget than a simple generic widget, so I'm not sure its place is inside elementary. But you know best what should go in there. I however do not use elementary for the ps3 (because it hasn't been fully ported yet) so I prefer to stay with pure edje. And since exquisite is already written.. it's not much trouble to expose its functions into a header. So if you don't need/want it in elementary yourself, then don't bother since I probably won't be using it anyways. Thanks On Mon, Feb 13, 2012 at 4:07 AM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 13 Feb 2012 03:46:22 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: hmm well if mainloop is alive... making an elementary widget would be the way to go... :) call it the splash widget - u can fill a window with it, just put it on the left/bottom half of your screen/window or whatever. :) it's really more of a progressbar PLUS a few more text fields that pb doesnt have... in fact u can do all of it with progressbars and setting text elements in the progressbar if we added another 1. you can do the end anim with signal emits - in fact u'd want the callback when done and an api for this... i'd actually suggest adding some more features to progressbar as above and adding this as a style for it. only thing then is the text log scroll - should this be in progressbar or not - do you want/need it? Yes, I've read the code, I know how small and easy it is, however, if there's a library for it, then apps could reuse the same .edc from other apps, it would give a sort of 'standard' way of doing this kind of splash screens, with a standard set of features, and a set of themes for it that people can reuse.. and obviously, if someone wants it a bit different, they can always just do their own edc instead. I just saw exquisite (release announcement on planet E) and thought it was cool, wanted to look at the API then realized it was an app, and I thought it would be better as a lib. As for uses, I do have a use for it, there are many tools for the PS3 that take a while and do many things but have no output on the screen and I thought they could benefit from that, like the messages dumping ram, patching kernel, flashing NAND, formatting flash, etc.. as well as having a progress bar.. Telling someone (who has no idea what the EFL even is) to write an EDC and set up his canvas and send signals, etc.. just for a progress bar or for printing a message on screen is a big turn off. Also, I think games may benefit from it, it's not always about boot time, but it would be for loading game levels for example, you often see a Loading screen in games, and this could be used for example. And for my immediate use, I have a tool that unzips largs packages into the PS3 HDD and I'd like to use it as a progress bar for when I unzip files, it could be used for the progress bar as well as for listing the files being unpacked. And yeah, the app is alive and running the mainloop in those use cases, and unzipping 1GB takes time I was going to implement a progress bar+messages system in my code, and write the edc and write a spec for people to retheme it, etc... but since I've seen exquisite, I don't think it's worth it to rewrite the same thing when I could just reuse existing code. Any suggestions on how you'd like me to proceed ? or should I just go and do it (I'll probably do it tomorrow). Thanks, KaKaRoTo On Mon, Feb 13, 2012 at 2:03 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 12 Feb 2012 07:13:39 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: ummm... if an app wants to do this its as easy as loading an edje obj and sending signals/setting text and dragables. that's a VERY thin library there. you want this for app splashes while apps start up? are the apps that start actually alive and running the mainloop for a long period before they are usable? This looks pretty good! I've been thinking that this could be used for applications as well, not just for the init scripts. So I'm thinking of modifying exquisite into a libexquisite (which the exquisite tool itself would use). It's basically just about having a way of creating an exquisite (edje) object and translating those IPC commands into API functions. I think it could be used by apps for doing progress bars (with a sort of 'standard' edje specs) and generic splash screens (for games loading levels and stuff like that). What do you think ? Any suggestions before I start ? KaKaRoTo On Fri, Feb 10, 2012 at 4:37 AM, P Purkayastha ppu...@gmail.com wrote: On Friday, February 10, 2012 4:40:33 PM UTC+8, The Rasterman Carsten Haitzler wrote: On Thu, 9 Feb 2012 23:04:00 -0800 (PST) P Purkayastha
Re: [E-devel] [e-users] Exquisite bootsplash release
This looks pretty good! I've been thinking that this could be used for applications as well, not just for the init scripts. So I'm thinking of modifying exquisite into a libexquisite (which the exquisite tool itself would use). It's basically just about having a way of creating an exquisite (edje) object and translating those IPC commands into API functions. I think it could be used by apps for doing progress bars (with a sort of 'standard' edje specs) and generic splash screens (for games loading levels and stuff like that). What do you think ? Any suggestions before I start ? KaKaRoTo On Fri, Feb 10, 2012 at 4:37 AM, P Purkayastha ppu...@gmail.com wrote: On Friday, February 10, 2012 4:40:33 PM UTC+8, The Rasterman Carsten Haitzler wrote: On Thu, 9 Feb 2012 23:04:00 -0800 (PST) P Purkayastha ppu...@gmail.com said: Is there some guide on how to set this up? I know that Exquisite has existed for many years but I could never set it up due to the lack of a noobie-friendly guide. read README? look at the run-demo.sh as such you only want to be integrating this into a boot if you know your boot stuff (systemd/systvinit/whatever) and you need to put the status writes into your startup scripts or modify systemd to do it for you. (write to fifo or scoket directly). other than that u need to hack up all your init setup to start exquisite before everything else (and make sure efl libs are available to it at that time) and then send status and done messages from your init scripts or whatever. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com Ah yeah. Now I remember why I didn't pursue it further. I wasn't comfortable with hacking init scripts. :) -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje aspect.preference big-endian issue
No, I hadn't cause I got quite busy with something else, and I still needed to take the time to check if there were any other enums affected by the same kind of bug. I committed it yesterday though. On Wed, Jan 18, 2012 at 3:04 AM, Carsten Haitzler ras...@rasterman.comwrote: On Wed, 18 Jan 2012 01:01:45 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: i expected you would have already... ? commit! :) hehe, well, I just looked over edje_private.h and I didn't see any enum being used like aspect_preference was.Although maybe it's best if someone else had a quick look. I'm going to commit the patch I had as is. On Tue, Jan 17, 2012 at 11:06 PM, Carsten Haitzler ras...@rasterman.comwrote: On Fri, 13 Jan 2012 22:47:38 +0100 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 13, 2012 at 8:30 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Fri, Jan 13, 2012 at 10:32 AM, Cedric BAIL cedric.b...@free.fr wrote: On Fri, Jan 13, 2012 at 8:12 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I've had an issue recently when I tried to run my app (using edje) on the PS3, the aspect ratio of all the images were wrong, and it looked really bad. I investigated the issue and found out that the aspect_preference was the cause and that when it's set to 'BOTH' for example, the desc-aspect.prefer value is 50331648 which is.. 0x300 .. so it's a big endian vs. little endian issue since the EDJE_ASPECT_PREFER_BOTH value in the enum is '3'. So I figured the reading of the .edj is wrong, so I looked and it seems to read it as a 'EET_T_CHAR', but the structure contains the enum as type, which makes it an int.. so what happens is that it stores 1 byte (the char) in the 32bit variable.. on little endian, it's fine, it works, but on big endian, it makes the value huge. So I fixed it by changing the declaration of he 'aspect.prefer' structure to a char instead of the enum it represents. I tested and it seems to work and not break anything (and fixes the bug). However, since this seems a bit sensitive, I thought it's best to send the patch here to make sure I'm not doing something wrong. Thanks for reviewing this simple one liner patch : http://pastie.org/3176835 I have noticed other structures do the same thing, 'fill mode' for example is defined as EET_T_UCHAR in the eet data description and as 'unsigned char' in the structure, that's why I fixed it this way. Note also that this shouldn't break the .edj file's compatibility or anything. Good, you figured out why it was broken. The fix sounds fine for me. Did you check that the only enum, we are using directly in one of our saved structure or should I check ? Ok cool, I will commit it then. I checked and didn't see any other enum being used, but I didn't do an extensive check. I will make sure it was the only one and fix any other I might see. Cool, thanks ! awesome. all handled before i got to it! eexcellent! :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ 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 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio
Re: [E-devel] Windows installer
On Thu, Jan 19, 2012 at 12:15 AM, Sanjeev as290...@samsung.com wrote: Hi Vincent, I tested the windows installer, it installed without any issues. (Windows 7 Enterprise Edition) I think the following can be made better. 1. Picks up the default install folder as C:\Program Files\Efl. We could set it to c:\Efl by default, instead of %WINDIR% or some default path. I agree, that's a good idea, I personally didn't even notice the enter a destination directory screen, so it installed in program files, and when I tried to run edje_cc, it failed. Forced me to uninstall, reinstall.. so having C:\Efl as default is a good idea, and many apps do that already (python, tcl/tk, mingw, etc..) 2. After installation, there is only one menu item under EFL - Uninstall. It would help to port elementary_test as an example and put it as a menu item. Good point, it could also have a edje examples submenu with the examples running in edje_player for example.. there are a few things that can be done, not sure though if it's necessary.. as an optional checkbox maybe. The installation seems to have a collection of libraries and some binaries. Do you need some test apps written using these libraries ? I have never written embryo scripts before. Kindly let me know some more details about the testing. I can help. Regards, Sanjeev -Original Message- From: Vincent Torri [mailto:vincent.to...@gmail.com] Sent: Thursday, January 19, 2012 2:06 AM To: Enlightenment developer list Subject: [E-devel] Windows installer Hey, I've fixed a lot of bugs with the installer and the tarballs. The installer is here: http://dev.enlightenment.fr/~doursse/NSIS/Efl-1.1.0.exe it is better to install the EFL in a path without spaces (like c:\Efl). If some people could test it, especially with themes using embryo scripts, that would help me a lot thank you Vincent Torri -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Windows installer
On Thu, Jan 19, 2012 at 1:15 AM, Vincent Torri vincent.to...@gmail.comwrote: hey On Thu, Jan 19, 2012 at 6:32 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Thu, Jan 19, 2012 at 12:15 AM, Sanjeev as290...@samsung.com wrote: Hi Vincent, I tested the windows installer, it installed without any issues. (Windows 7 Enterprise Edition) I think the following can be made better. 1. Picks up the default install folder as C:\Program Files\Efl. We could set it to c:\Efl by default, instead of %WINDIR% or some default path. I agree, that's a good idea, I personally didn't even notice the enter a destination directory screen, so it installed in program files, and when I tried to run edje_cc, it failed. Forced me to uninstall, reinstall.. so having C:\Efl as default is a good idea, and many apps do that already (python, tcl/tk, mingw, etc..) I can use c:\Efl by default, it's trivial to do. Note that is you run the installer while a previous installation has been done, the previous installation will be uninstalled first. yeah, that's how it gets uninstalled :p 2. After installation, there is only one menu item under EFL - Uninstall. It would help to port elementary_test as an example and put it as a menu item. Good point, it could also have a edje examples submenu with the examples running in edje_player for example.. there are a few things that can be done, not sure though if it's necessary.. as an optional checkbox maybe. If I'm not mistaken, edje_player requires an edje file at least. So it's useless to add it. But I can try to look if I can associate .edj files with edje_player. Oh that's a great idea to associate .edj files to edje_player! But what I meant was to have in programs-Efl-edje examples - pong.lnk with the command in pong.lnk being edje_player.exe c:\efl\examples\edje\pong.edj for example. Well, the installer is for EFL 1.1.0. That's why I didn't add Elementary. But I can add Expedite. I don't know if Expedite should be installed with the same installer, or with another installer. Good point about elementary. Yes, expedite could be disabled by default but added as a checkbox for example/test suite/expedite or something like that The installation seems to have a collection of libraries and some binaries. Do you need some test apps written using these libraries ? I have never written embryo scripts before. Kindly let me know some more details about the testing. I can help I think that Elementary theme has some embryo scripts. thank you for testing. Vincent -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Windows installer
On Thu, Jan 19, 2012 at 1:50 AM, Vincent Torri vincent.to...@gmail.comwrote: On Thu, Jan 19, 2012 at 7:41 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Thu, Jan 19, 2012 at 1:15 AM, Vincent Torri vincent.to...@gmail.com wrote: hey On Thu, Jan 19, 2012 at 6:32 AM, Youness Alaoui Oh that's a great idea to associate .edj files to edje_player! But what I meant was to have in programs-Efl-edje examples - pong.lnk with the command in pong.lnk being edje_player.exe c:\efl\examples\edje\pong.edj for example. haa, ok. I'll try to do it. Maybe it will mean to fix the compilation of the examples :/ I've never tried to compile them on Windows. In that case, maybe it will also a good idea to install .edc files. Yeah good idea. But since my edc compiles now on windows, I bet those example edc will aso compile without problem. Well, the installer is for EFL 1.1.0. That's why I didn't add Elementary. But I can add Expedite. I don't know if Expedite should be installed with the same installer, or with another installer. Good point about elementary. Yes, expedite could be disabled by default but added as a checkbox for example/test suite/expedite or something like that Just an 'Expedite' submenu will be sufficient, I think Yeah, I meant in the installer, you have checkboxes for each library, you could add another checkbox that says Examples or Test suite or Expedite or something like that.. I didn't mean for that to sound like subdirectories in the programs menu :) Vincent -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina_lock_void issue
On Tue, Jan 17, 2012 at 11:26 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 14 Jan 2012 23:19:59 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Sat, 14 Jan 2012 23:15:37 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hi, I've just updated my EFL build for the PS3 and it was broken. eina_init isn't working anymore because eina_value doesn't init itself correctly. The issue is that if it's unable to iitialize a lock, it will fail the init which fails eina_init (and ecore_init, etc..) The problem is that on the PS3, there is no pthread library so threads are disabled on eina and eina_lock uses eina_inline_lock_void.x which just returns FALSE/FAIL for every API call. This also causes another issue with evas which slows it down because it tries a eina_lock_take_try (which fails) and forces it to wait a bit before doing anything then it spams my terminal with warnings about not being able to get a lock. I would suggest to change the behavior of eina_lock (on 'void' platforms, which do not support locks) to always return TRUE/SUCCEED so it doesn't break everything below it. What do you think ? Thanks, KaKaRoTo unfortunately this would be an api break since eina_lock was present in the 1.1 release... actually the void impl really should just work as if there were no threads at all so i'd say this is a bug in return value. i.e. its a platform on which threads cannot exist thus locking is pointless. though my position on this is... it will be not long when we simply will not work without threads. it is my intention to move us to having more internal threads and reduce the maintenance cost of having non-threaded modes/paths as then its a vector for bugs and problems. so reality is the void thread impl will basically be like an appendix - useless legacy stuff :) Yeah, I know your plan, in the meantime, I'm happy playing the lazy card until it becomes mandatory. Either way I don't think it was working before I came in, as I found many bugs on the no-threads part of the code as it was never tested by anyone. But I do agree, it's a bug in my opinion as it should just work as if locks were successful (no threads means no race conditions).. on the other hand some might see it as you try to create a mutex but it failed because it's not supported as being the expected behavior. it's a though call to be honest.. but all I know, is that without that patch, it just won't work for me right now. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje aspect.preference big-endian issue
hehe, well, I just looked over edje_private.h and I didn't see any enum being used like aspect_preference was.Although maybe it's best if someone else had a quick look. I'm going to commit the patch I had as is. On Tue, Jan 17, 2012 at 11:06 PM, Carsten Haitzler ras...@rasterman.comwrote: On Fri, 13 Jan 2012 22:47:38 +0100 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 13, 2012 at 8:30 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Fri, Jan 13, 2012 at 10:32 AM, Cedric BAIL cedric.b...@free.fr wrote: On Fri, Jan 13, 2012 at 8:12 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I've had an issue recently when I tried to run my app (using edje) on the PS3, the aspect ratio of all the images were wrong, and it looked really bad. I investigated the issue and found out that the aspect_preference was the cause and that when it's set to 'BOTH' for example, the desc-aspect.prefer value is 50331648 which is.. 0x300 .. so it's a big endian vs. little endian issue since the EDJE_ASPECT_PREFER_BOTH value in the enum is '3'. So I figured the reading of the .edj is wrong, so I looked and it seems to read it as a 'EET_T_CHAR', but the structure contains the enum as type, which makes it an int.. so what happens is that it stores 1 byte (the char) in the 32bit variable.. on little endian, it's fine, it works, but on big endian, it makes the value huge. So I fixed it by changing the declaration of he 'aspect.prefer' structure to a char instead of the enum it represents. I tested and it seems to work and not break anything (and fixes the bug). However, since this seems a bit sensitive, I thought it's best to send the patch here to make sure I'm not doing something wrong. Thanks for reviewing this simple one liner patch : http://pastie.org/3176835 I have noticed other structures do the same thing, 'fill mode' for example is defined as EET_T_UCHAR in the eet data description and as 'unsigned char' in the structure, that's why I fixed it this way. Note also that this shouldn't break the .edj file's compatibility or anything. Good, you figured out why it was broken. The fix sounds fine for me. Did you check that the only enum, we are using directly in one of our saved structure or should I check ? Ok cool, I will commit it then. I checked and didn't see any other enum being used, but I didn't do an extensive check. I will make sure it was the only one and fix any other I might see. Cool, thanks ! awesome. all handled before i got to it! eexcellent! :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina_lock_void issue
Oh, I just did a rebase on svn and you already committed a patch that did this. I thought it needed more discussion before a decision is made. Thanks! :) On Wed, Jan 18, 2012 at 12:32 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Tue, Jan 17, 2012 at 11:26 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 14 Jan 2012 23:19:59 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Sat, 14 Jan 2012 23:15:37 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hi, I've just updated my EFL build for the PS3 and it was broken. eina_init isn't working anymore because eina_value doesn't init itself correctly. The issue is that if it's unable to iitialize a lock, it will fail the init which fails eina_init (and ecore_init, etc..) The problem is that on the PS3, there is no pthread library so threads are disabled on eina and eina_lock uses eina_inline_lock_void.x which just returns FALSE/FAIL for every API call. This also causes another issue with evas which slows it down because it tries a eina_lock_take_try (which fails) and forces it to wait a bit before doing anything then it spams my terminal with warnings about not being able to get a lock. I would suggest to change the behavior of eina_lock (on 'void' platforms, which do not support locks) to always return TRUE/SUCCEED so it doesn't break everything below it. What do you think ? Thanks, KaKaRoTo unfortunately this would be an api break since eina_lock was present in the 1.1 release... actually the void impl really should just work as if there were no threads at all so i'd say this is a bug in return value. i.e. its a platform on which threads cannot exist thus locking is pointless. though my position on this is... it will be not long when we simply will not work without threads. it is my intention to move us to having more internal threads and reduce the maintenance cost of having non-threaded modes/paths as then its a vector for bugs and problems. so reality is the void thread impl will basically be like an appendix - useless legacy stuff :) Yeah, I know your plan, in the meantime, I'm happy playing the lazy card until it becomes mandatory. Either way I don't think it was working before I came in, as I found many bugs on the no-threads part of the code as it was never tested by anyone. But I do agree, it's a bug in my opinion as it should just work as if locks were successful (no threads means no race conditions).. on the other hand some might see it as you try to create a mutex but it failed because it's not supported as being the expected behavior. it's a though call to be honest.. but all I know, is that without that patch, it just won't work for me right now. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and epp
Good point about the authors.. There are 22 total who contributed to
edje_cc* files and only 6 to edje_cc.c specifically.
git log edje_cc* | grep Author | awk '{print $2}' | sort | uniq | wc
22
I definitely agree that it would be stupid to change the other libs or even
edje itself to GPL, and I would definitely disagree with that myself. I
also don't like how GPL is a kind of viral like license, but the way I
usually do it (personally) is : GPL for apps, LGPL for libraries.
That being said, releasing *only* the edje_cc binary in GPL (keeping edje
library and edje_decc, etc.. as BSD-like) would be a good solution to this
epp problem.
In order to avoid having to get approval from all 22 authors on the edje_cc
files, how about a compromise, write a new edje_cc, which would use the
BSD-like code from the existing code base (edje_cc_handlers.c,
edje_cc_parse.c, etc..) but just write the 'main' function in a GPL-ed file
which includes and calls those BSD-like functions/files. That is of course,
assuming that a GPL .o can be 'legally' linked with a BSD .o (I think it
is, but I'm not sure about it) to provide the final binary.
edje_cc.c is only 250 lines of code, so it should be quite easy to rewrite
it, or we could just ask permission from the 6 authors of edje_cc.c :
barbieri
caro
cedric
lucas
mike_m
raster
We could also have a edje_cc_gpl alongside edje_cc which would not depend
on epp and integrates it... This is particularly useful for windows where
it's a bit tricky to get edje_cc.exe to find epp.exe (although that works
fine and is not too hard, it's a bit of a hassle).
Anyways, I'm just throwing ideas, doesn't mean any makes sense :)
On Sun, Jan 15, 2012 at 3:51 AM, Michael Blumenkrantz
michael.blumenkra...@gmail.com wrote:
On Sun, 15 Jan 2012 09:48:34 +0100
Vincent Torri vincent.to...@gmail.com wrote:
On Sun, Jan 15, 2012 at 9:33 AM, David Seikel onef...@gmail.com wrote:
Only two are listed as an author
for epp, might be easier to get epp license changed? Though this might
make things hard (from epp) -
* Copyright (C) 1995 Free Software Foundation, Inc.
* Written by Per Bothner, 1994-95.
* Copyright (C) 2003-2011 Kim Woelders
that's something to try, indeed, though some changes has been done to
epp by other devs :
http://trac.enlightenment.org/e/log/trunk/edje/src/bin/epp
Vincent
I don't consider anything I've done there worth attribution.
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] eina_lock_void issue
Hi, I've just updated my EFL build for the PS3 and it was broken. eina_init isn't working anymore because eina_value doesn't init itself correctly. The issue is that if it's unable to iitialize a lock, it will fail the init which fails eina_init (and ecore_init, etc..) The problem is that on the PS3, there is no pthread library so threads are disabled on eina and eina_lock uses eina_inline_lock_void.x which just returns FALSE/FAIL for every API call. This also causes another issue with evas which slows it down because it tries a eina_lock_take_try (which fails) and forces it to wait a bit before doing anything then it spams my terminal with warnings about not being able to get a lock. I would suggest to change the behavior of eina_lock (on 'void' platforms, which do not support locks) to always return TRUE/SUCCEED so it doesn't break everything below it. What do you think ? Thanks, KaKaRoTo -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina_lock_void issue
On Sat, Jan 14, 2012 at 11:38 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Jan 15, 2012 at 2:19 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 14 Jan 2012 23:15:37 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hi, I've just updated my EFL build for the PS3 and it was broken. eina_init isn't working anymore because eina_value doesn't init itself correctly. The issue is that if it's unable to iitialize a lock, it will fail the init which fails eina_init (and ecore_init, etc..) The problem is that on the PS3, there is no pthread library so threads are disabled on eina and eina_lock uses eina_inline_lock_void.x which just returns FALSE/FAIL for every API call. This also causes another issue with evas which slows it down because it tries a eina_lock_take_try (which fails) and forces it to wait a bit before doing anything then it spams my terminal with warnings about not being able to get a lock. I would suggest to change the behavior of eina_lock (on 'void' platforms, which do not support locks) to always return TRUE/SUCCEED so it doesn't break everything below it. What do you think ? Thanks, KaKaRoTo unfortunately this would be an api break since eina_lock was present in the 1.1 release... actually a bug, then it must be fixed. @Michael That's true, it was in 1.1 release, but it wouldn't be an API break, rather a behavior change (does that count as api break?) But yes, it should be thought of careful, that's why I wrote the mail. The thing is that a eina_lock on a system that does not support threads is basically an undefined behavior (and as far as I know, it is not documented how it would react in such a case). How many systems do you have/support which make use of the eina_lock_void (compiled without threads support) ? Also, I'd actually think that this is the right behavior.. if you do eina_lock_take on a system without threads, then it shouldn't fail as if the other thread is still holding the lock.. it should tell you yes, you can continue safely, so it should return TRUE. @Gustavo: yes it's a bug because right now, this configuration will not be able to initialize anything. What did you mean by #ifdef if ? you mean only do the lock init if threads are enabled ? That might fix the current bug of eina_init failing, but it wouldn't fix the eina_lock_take_try issues I discussed. For now, locally, I made eina_lock return TRUE on the ps3, so I'm not stuck, but I'd like to have this properly fixed, hopefully without any hacks. Thanks -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina_lock_void issue
On Sun, Jan 15, 2012 at 1:52 AM, David Seikel onef...@gmail.com wrote: On Sat, 14 Jan 2012 23:15:37 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hi, I've just updated my EFL build for the PS3 and it was broken. eina_init isn't working anymore because eina_value doesn't init itself correctly. The issue is that if it's unable to iitialize a lock, it will fail the init which fails eina_init (and ecore_init, etc..) The problem is that on the PS3, there is no pthread library so threads are disabled on eina and eina_lock uses eina_inline_lock_void.x which just returns FALSE/FAIL for every API call. This also causes another issue with evas which slows it down because it tries a eina_lock_take_try (which fails) and forces it to wait a bit before doing anything then it spams my terminal with warnings about not being able to get a lock. I would suggest to change the behavior of eina_lock (on 'void' platforms, which do not support locks) to always return TRUE/SUCCEED so it doesn't break everything below it. I'm wondering how come a hyperthreaded CPU with a dozen extra specialized cores has no thread support? It might not have pthread, but it might have some other sort of thread support that could be used instead? Yes it has threads support, and the official SDK (Which we can't legally use) has pthread, but we don't have an open source port of pthread to their own system calls. So for now I'm working with it without threading support. I will eventually (some day) port pthread to it then all of this will go away, in the meantime, I prefer to concentrate on other things (it also helped me find a few bugs in the EFL for when it gets compiled without threads) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina_lock_void issue
Yes I could, but I don't really see the point to be honest, I think porting pthreads would be much more convenient rather than porting every library that uses pthread into using the ps3 specific API. I just lack time/motivation to do it, but it should be pretty straighforward... On Sun, Jan 15, 2012 at 2:27 AM, Vincent Torri vincent.to...@gmail.comwrote: On Sun, Jan 15, 2012 at 8:06 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sun, Jan 15, 2012 at 1:52 AM, David Seikel onef...@gmail.com wrote: On Sat, 14 Jan 2012 23:15:37 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hi, I've just updated my EFL build for the PS3 and it was broken. eina_init isn't working anymore because eina_value doesn't init itself correctly. The issue is that if it's unable to iitialize a lock, it will fail the init which fails eina_init (and ecore_init, etc..) The problem is that on the PS3, there is no pthread library so threads are disabled on eina and eina_lock uses eina_inline_lock_void.x which just returns FALSE/FAIL for every API call. This also causes another issue with evas which slows it down because it tries a eina_lock_take_try (which fails) and forces it to wait a bit before doing anything then it spams my terminal with warnings about not being able to get a lock. I would suggest to change the behavior of eina_lock (on 'void' platforms, which do not support locks) to always return TRUE/SUCCEED so it doesn't break everything below it. I'm wondering how come a hyperthreaded CPU with a dozen extra specialized cores has no thread support? It might not have pthread, but it might have some other sort of thread support that could be used instead? Yes it has threads support, and the official SDK (Which we can't legally use) has pthread, but we don't have an open source port of pthread to their own system calls. So for now I'm working with it without threading support. I will eventually (some day) port pthread to it then all of this will go away, in the meantime, I prefer to concentrate on other things (it also helped me find a few bugs in the EFL for when it gets compiled without threads) if there's thread support, you can try to use the native one, like i did for Windows, right ? Vincent -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina_lock_void issue
The PS3 OS's system call for threads/mutex/cond/sem is almost the same as pthread, so it shouldn't be very compilcated.. I already ported pthread-embeded to the ps3 but I don't like their implementation (and it causes some issues with the newlib headers used by the toolchain. I will think about it though, it might be easier to just write ps3 specific code for it in eina. But it wouldn't help porting efforts of other non-efl applications to the PS3 that depend on pthread. On Sun, Jan 15, 2012 at 2:47 AM, Vincent Torri vincent.to...@gmail.comwrote: On Sun, Jan 15, 2012 at 8:40 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Yes I could, but I don't really see the point to be honest, I think porting pthreads would be much more convenient rather than porting every library that uses pthread into using the ps3 specific API. I just lack time/motivation to do it, but it should be pretty straighforward... well, porting pthread to a system == being POSIX compliant (wrt threads) so it's not so simple. I saw the code of pthread-win32 and it's an horror (because of that). Just locking a mutex is complicated and in fine uses the win32 API. So i decided to use native win32 API. One call and that's all, it's faster than pthread-win32 and it consumes less memory. Vincent On Sun, Jan 15, 2012 at 2:27 AM, Vincent Torri vincent.to...@gmail.com wrote: On Sun, Jan 15, 2012 at 8:06 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sun, Jan 15, 2012 at 1:52 AM, David Seikel onef...@gmail.com wrote: On Sat, 14 Jan 2012 23:15:37 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hi, I've just updated my EFL build for the PS3 and it was broken. eina_init isn't working anymore because eina_value doesn't init itself correctly. The issue is that if it's unable to iitialize a lock, it will fail the init which fails eina_init (and ecore_init, etc..) The problem is that on the PS3, there is no pthread library so threads are disabled on eina and eina_lock uses eina_inline_lock_void.x which just returns FALSE/FAIL for every API call. This also causes another issue with evas which slows it down because it tries a eina_lock_take_try (which fails) and forces it to wait a bit before doing anything then it spams my terminal with warnings about not being able to get a lock. I would suggest to change the behavior of eina_lock (on 'void' platforms, which do not support locks) to always return TRUE/SUCCEED so it doesn't break everything below it. I'm wondering how come a hyperthreaded CPU with a dozen extra specialized cores has no thread support? It might not have pthread, but it might have some other sort of thread support that could be used instead? Yes it has threads support, and the official SDK (Which we can't legally use) has pthread, but we don't have an open source port of pthread to their own system calls. So for now I'm working with it without threading support. I will eventually (some day) port pthread to it then all of this will go away, in the meantime, I prefer to concentrate on other things (it also helped me find a few bugs in the EFL for when it gets compiled without threads) if there's thread support, you can try to use the native one, like i did for Windows, right ? Vincent -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and epp
On Sun, Jan 15, 2012 at 2:36 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sun, 15 Jan 2012 08:26:17 +0100 Vincent Torri vincent.to...@gmail.com wrote: On Sun, Jan 15, 2012 at 8:06 AM, David Seikel onef...@gmail.com wrote: On Sun, 15 Jan 2012 08:00:06 +0100 Vincent Torri vincent.to...@gmail.com wrote: as we have epp source code, why creating a program and trying to execute it, instead of having a function that takes a buffer as input and create a preprocessed buffer as ouput ? Imho, it would be cleaner. I suspect the epp licence is the reason. aaaggg. You're right :( Vincent confirmed. Humm.. edje is LGPL (afaik) and epp is GPL.. how about making edje_cc (only) a GPLv2 app and keep the rest of the lib to its current license.. that could be a solution. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] devilhorms: elementary broken
Hi, According to a user on #edevelop, the latest SVN version of elementary is broken since SVN r67129, the following chang eintroduced by devilhorns broke it : http://trac.enlightenment.org/e/changeset/67129 This removes an API from ecore_evas which causes an undefined symbol in libelementary : undefined symbol: ecore_evas_wayland_shm_resize The changeset removes a function from the API without removing it from Ecore_Evas.h and without removing its uses from libelementary (changelog/NEWS change is also missing, unless it was added in a later commit) Please fix it correctly, thank you, KaKaRoTo -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje aspect.preference big-endian issue
On Fri, Jan 13, 2012 at 10:32 AM, Cedric BAIL cedric.b...@free.fr wrote: Hi, On Fri, Jan 13, 2012 at 8:12 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I've had an issue recently when I tried to run my app (using edje) on the PS3, the aspect ratio of all the images were wrong, and it looked really bad. I investigated the issue and found out that the aspect_preference was the cause and that when it's set to 'BOTH' for example, the desc-aspect.prefer value is 50331648 which is.. 0x300 .. so it's a big endian vs. little endian issue since the EDJE_ASPECT_PREFER_BOTH value in the enum is '3'. So I figured the reading of the .edj is wrong, so I looked and it seems to read it as a 'EET_T_CHAR', but the structure contains the enum as type, which makes it an int.. so what happens is that it stores 1 byte (the char) in the 32bit variable.. on little endian, it's fine, it works, but on big endian, it makes the value huge. So I fixed it by changing the declaration of he 'aspect.prefer' structure to a char instead of the enum it represents. I tested and it seems to work and not break anything (and fixes the bug). However, since this seems a bit sensitive, I thought it's best to send the patch here to make sure I'm not doing something wrong. Thanks for reviewing this simple one liner patch : http://pastie.org/3176835 I have noticed other structures do the same thing, 'fill mode' for example is defined as EET_T_UCHAR in the eet data description and as 'unsigned char' in the structure, that's why I fixed it this way. Note also that this shouldn't break the .edj file's compatibility or anything. Good, you figured out why it was broken. The fix sounds fine for me. Did you check that the only enum, we are using directly in one of our saved structure or should I check ? Ok cool, I will commit it then. I checked and didn't see any other enum being used, but I didn't do an extensive check. I will make sure it was the only one and fix any other I might see. Thanks, KaKaRoTo Regards, -- Cedric BAIL -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/eina/src: include lib tests
You use 'timercmp' which is not POSIX and you're not checking for it in the configure... you should use something else instead or provide a replacement if it's not found. After the include of sys/time.h, I added a simple : #ifndef timercmp #define ... /* copy/pasted from /usr/include/sys/time.h */ #endif Should I commit that or wait until it's properly fixed ? On Wed, Jan 11, 2012 at 9:26 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Wed, 11 Jan 2012 17:31:21 -0800 Enlightenment SVN no-re...@enlightenment.org wrote: Log: eina_value: add struct timeval. may be useful for esskyuehl. Author: barbieri Date: 2012-01-11 17:31:21 -0800 (Wed, 11 Jan 2012) New Revision: 67106 Trac: http://trac.enlightenment.org/e/changeset/67106 Modified: trunk/eina/src/include/eina_value.h trunk/eina/src/lib/eina_value.c trunk/eina/src/tests/eina_test_value.c o -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/eina/src: include lib tests
ok, that's another possible solution :) Thanks, I'll revert my local changes then. On Thu, Jan 12, 2012 at 11:45 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Jan 12, 2012 at 6:16 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: You use 'timercmp' which is not POSIX and you're not checking for it in the configure... you should use something else instead or provide a replacement if it's not found. After the include of sys/time.h, I added a simple : #ifndef timercmp #define ... /* copy/pasted from /usr/include/sys/time.h */ #endif Should I commit that or wait until it's properly fixed ? nah, too much work... I'll do the manual comparison, it's trivial. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Edje aspect.preference big-endian issue
Hi, I've had an issue recently when I tried to run my app (using edje) on the PS3, the aspect ratio of all the images were wrong, and it looked really bad. I investigated the issue and found out that the aspect_preference was the cause and that when it's set to 'BOTH' for example, the desc-aspect.prefer value is 50331648 which is.. 0x300 .. so it's a big endian vs. little endian issue since the EDJE_ASPECT_PREFER_BOTH value in the enum is '3'. So I figured the reading of the .edj is wrong, so I looked and it seems to read it as a 'EET_T_CHAR', but the structure contains the enum as type, which makes it an int.. so what happens is that it stores 1 byte (the char) in the 32bit variable.. on little endian, it's fine, it works, but on big endian, it makes the value huge. So I fixed it by changing the declaration of he 'aspect.prefer' structure to a char instead of the enum it represents. I tested and it seems to work and not break anything (and fixes the bug). However, since this seems a bit sensitive, I thought it's best to send the patch here to make sure I'm not doing something wrong. Thanks for reviewing this simple one liner patch : http://pastie.org/3176835 I have noticed other structures do the same thing, 'fill mode' for example is defined as EET_T_UCHAR in the eet data description and as 'unsigned char' in the structure, that's why I fixed it this way. Note also that this shouldn't break the .edj file's compatibility or anything. Thanks, KaKaRoTo -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
Alright, we reached the deadline (actually it was yesterday but I was busy) and there's still no real agreement about this, however it seems most of you want the patch reverted, so I will remove it and document it properly. Thanks for your input. On Mon, Jan 9, 2012 at 5:14 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Bruno, while your example is valid, it's not how it will usually be. Most of the time people will use animations, which are bound to keyboard/mouse events. In my code for example, I can scroll a list using the arrow keys, but if you press the arrow twice, then two signals are sent, thus canceling the first animation.so the state of the swalowed object is undefined as it all depends on the elapsed milliseconds between the first and second press of the arrow key. I consider this a race condition. I also doubt that anyone is using edje, then suddenly unswallows the object and decides to keep it there and start to handle it manually in C.If he wanted to handle it in C directly, it wouldn't have been a swallowed part in the first place. i don't disagree though that this might chance the behavior of some really rare apps. As for trusting the .edj, you'd trust it to have specific groups/parts and handle/send specific signals, but you can't trust it to have an object as a specific position. The whole purpose of the edj is to allow the UI dev to decide where to position everything, what sizes to give them and what states. On Mon, Jan 9, 2012 at 11:19 AM, Bruno Dilly bdi...@profusion.mobiwrote: On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. You know that edje_object_part_swallow return an EINA_BOOL, do you ? I do, you can print something in your terminal and quit the application. What doesn't mean it is not working as intended. Anyway, there are signals that should be emitted to code and you don't emit that on your theme. So it will break your application and you can't detect. Going further, you can make every part invisible, and you application will be completely useless. So, yeah, I believe you need to trust your edj someway, and they need to be considered part of the application. -- Cedric BAIL
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
Bruno, while your example is valid, it's not how it will usually be. Most of the time people will use animations, which are bound to keyboard/mouse events. In my code for example, I can scroll a list using the arrow keys, but if you press the arrow twice, then two signals are sent, thus canceling the first animation.so the state of the swalowed object is undefined as it all depends on the elapsed milliseconds between the first and second press of the arrow key. I consider this a race condition. I also doubt that anyone is using edje, then suddenly unswallows the object and decides to keep it there and start to handle it manually in C.If he wanted to handle it in C directly, it wouldn't have been a swallowed part in the first place. i don't disagree though that this might chance the behavior of some really rare apps. As for trusting the .edj, you'd trust it to have specific groups/parts and handle/send specific signals, but you can't trust it to have an object as a specific position. The whole purpose of the edj is to allow the UI dev to decide where to position everything, what sizes to give them and what states. On Mon, Jan 9, 2012 at 11:19 AM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi wrote: On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. It isn't documented. But it's defined, IMHO, since you can predict it. As you said, in an animation it will keep the state, if it was visible, it will stay visible. So applications can be considering a unswallowed object will be visible, since it was visible, and now it will be hidden. No, as it is defined in the theme, it doesn't depend on the application. If you change the theme, the animation, anything in the .edj, it will change the behaviour in the application itself. It's full of race condition. There is no sane way to expect any kind of behaviour in the app. It is definitivly an undefined behaviour, as their is no way you could know the state of the object without requesting it after the unswallow. OK, my concept of application is code and theme. Anyway, a simple case is to add an rectangle to a swallow in a layout. I've attached a quick example. As you can see, no luck required. After 3 seconds the rectangle is unswallowed and displayed at 0,0. Ok, I see the difference. From my point of view, the application should never trust an edj file. So if I can break your consistent behaviour by just touching the edc file, then their is a bug in the application from my point of view. In your example. I just need to set visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break your app. So you are just lucky that no one touched your edc file. Ok, but don't you trust the edj file will have a swallow with name X ? It's easy to break an application changing the edj if you want to do so. You know that edje_object_part_swallow return an EINA_BOOL, do you ? I do, you can print something in your terminal and quit the application. What doesn't mean it is not working as intended. Anyway, there are signals that should be emitted to code and you don't emit that on your theme. So it will break your application and you can't detect. Going further, you can make every part invisible, and you application will be completely useless. So, yeah, I believe you need to trust your edj someway, and they need to be considered part of the application. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
@Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. I'm pretty sure it's wrong to implement things that completely change expected behavior like this in a non-major version... It's not changing any expected behaviour. When edje unswallow an object, you are not supposed to expect it in any particular state. Now you can expect it to be hidden. That's just what it does. It defines the output state, something that wasn't before. The point that make sense is the one that Gustavo raise. With previous behaviour, in some case you will notice that an object was not handle by edje anymore, because it was visibly lying around. I may be wrong, but if the part was not visible, unswallow would have issued an hidden object, like this patch does. So I don't know now, if the best is to force its visibility or to hide. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ridiculously easy VDI. With Citrix
Re: [E-devel] E SVN: kakaroto trunk/ecore/src/lib/ecore_con
No, on the ps3 :) On Sat, Jan 7, 2012 at 9:10 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 03:39:23 -0800 Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore-con: Let's not break compilation if net/if.h is not found (or old system) Author: kakaroto Date: 2012-01-07 03:39:23 -0800 (Sat, 07 Jan 2012) New Revision: 66956 Trac: http://trac.enlightenment.org/e/changeset/66956 Modified: trunk/ecore/src/lib/ecore_con/ecore_con_socks.c compiling on debian sarge again, eh? -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
Understood, but I don't consider this behavior as a tool :p I don't know about others who use unswallow, but in my case, the unswallow was happening after an animation put the part in a 0x0 geometry state, so it wasn't visible anyways. Either way, what do you think the behavior should be? should I understand from your comment that unswallow should not hide it ? On Sat, Jan 7, 2012 at 9:12 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 7 Jan 2012 20:50:26 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: the real issue here is, leak-wise, that there is no tool to help u find such leaks as the object will never appear in any leak checker as it is tracked by evas anyway. :( (nb - unswallow == edje releases control of the object.) @Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. I'm pretty sure it's wrong to implement things that completely change expected behavior like this in a non-major version... It's not changing any expected behaviour. When edje unswallow an object, you are not supposed to expect it in any particular state. Now you can expect it to be hidden. That's just what it does. It defines the output state, something that wasn't before. The point that make sense is the one that Gustavo raise. With previous behaviour, in some case you will notice that an object was not handle by edje anymore, because it was visibly lying around. I may be wrong
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
I still personally see it as just confusing and an abnormal behavior, and it wasn't helpful at all in finding leaks (because in my case the unswallow happens after the part is 0x0, so the glitch/artifact only happened on race conditions). I will wait for cedric/gustavo's opinion on this, if one of them agrees with you, I'll revert my patch, if not, we can discuss it a bit more. If we can't reach a consensus by monday, I'll just revert my patch and add a note in the documentation instead (although there is already a note about the object not being deleted in the docs). Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 11:45 PM, Daniel Juyung Seo seojuyu...@gmail.comwrote: Yes, I understand what you mean. Both opinion have their own reasons. I was so confused when I first unswallowed my object :( Even I agree with both opinions, how about just letting them as is and just document it? reason1. As Gustavo and Raster said, this is a warning that we have to handle unswallowed object and it's not deleted/hided at all. reason2. We already released edje 1.1 and changing this default behavior doesn't look good at the moment because this will confused our existing customers. If we really need to change it, do this edje 2.0 or whatever. My 2 cents. I'm actually poor so no more 10 cents. Daniel Juyung Seo (SeoZ) On Sun, Jan 8, 2012 at 10:50 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: @Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) sachi...@gmail.com wrote: 2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Edje: hide an object after unswallow Simply doing an unswallow would leave the object where it was in the evas, visible, but edje would not be handling it anymore. nah, you're supposed to do this in the application or edje user. Very likely you'll delete the object, sometimes hide it. If you hide by default, novice will not see the object and will leak... it's like a warning. And if for some reason the change stays in, it's one of those very special things that deserve big bold letters in Changelog and NEWS files. I'm
Re: [E-devel] NSIS installer for the EFL 1.1.0 on Windows
Hi Vincent, I tried the installer, it's all nice and everything, however, I've had a little issue with the content. It seems edje_player doesn't show you the window, or rather it has a size of 0x0 and you can't resize it. I've tried giving the -Z640x480 argument to it and then I saw the window, but when I tried to resize it, it switched back to 0x0. As for the development files, I found an issue, the .pc files have prefix set to /opt/efl, however you get them installed in C:\Program Files\Efl. That's fine though, pkg-config doesn't seem to like spaces in paths so I had to put them in /opt/efl anyways, but you may want to generate the .pc files from the installer by giving them the right prefix. Finally, I'm having issues compiling my app because the .pc files depend on fontconfig, freetype2, lua and libcares which are not bundled and are not available in mingw, so I have to compile them myself in mingw... not great, but I don't think you can do much about it (unless you add a 'support libraries' section to the installer and bundle those libs with it if dev files are selected?) Another issue is that edje_cc fails with the error : ERR:edje_cc edje_cc_parse.c:754 compile() Error. Cannot run epp: /opt/efl/lib/edje/utils/epp.exe and indeed, the epp.exe file is missing from the installation (I did enable all dev files to be installed). Just my 2c. Thanks, the installers are great otherwise :) p.s.: humm.. I just realized you are shipping the fontconfig/freetype/lua dlls with the efl, so it's just the dev files for those that are missing... something else missing is that my app now complains that it can't find libxml2-2.dll which is weird since Dependency Walker doesn't show it anywhere as a dependency... Maybe it should also be included ? KaKaRoTo On Wed, Dec 21, 2011 at 1:15 AM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 19 Dec 2011 19:53:28 +0100 Vincent Torri vincent.to...@gmail.com said: wow. that installs... nice... even has an uninstall. slick. :) hey for those who want to try it, here is the installer: http://dev.enlightenment.fr/~doursse/NSIS/Efl-1.1.0.exe the available EFL are up to edje. So expedite here. It's a temporary installer, as i haven't well tested. The official one will be available around the 7/8 january 2012 Vincent -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ 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 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje bugs?
On Thu, Dec 29, 2011 at 1:00 AM, David Seikel onef...@gmail.com wrote: On Thu, 29 Dec 2011 00:37:35 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: p.s: Anyone knows how to use lua to get a part's object? all I saw in the doc is edje.edje() to create a new edje object.. but what if I want to write a script to get an existing part (like a text part) and modify it in lua? That sort of thing was vetoed by raster, though I had a design and was ready to start coding it. Edje Lua is supposed to be entirely sandboxed, not being allowed to mess with external things. Not being allowed to use external image files, not being allowed to do stuff to edje parts it did not create itself, etc. euhh... ok, then it's completely useless, no? Why did raster veto it ? what were his reasons? I just want a simple edje script (embryo or lua) that would update a 'clock' TEXT part with the current time. I could do it in C but it's so simple I don't feel the need for doing it in C (+ I don't want to make it a requirement, I want to let the theme designer decide if he wants to put one or not). I really don't understand the design decision on this, any pointers? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Edje bugs?
Hi, I'm trying to develop a small GUI using edje, and I've run into a few problems already... it seems that the 'clip_to' keyword screws up some stuff. Unless I'm understanding this wrong, the clip_to only means do not draw anything that's outside of this area.. but if you do a clip_to on a TEXT or IMAGE and the clipping is a rect, it seems to actually override the other part, and apply it as a mask.. I'm not sure I can explain this properly so here's a test : http://dl.dropbox.com/u/22642664/edje_clip_to_bug.edc http://dl.dropbox.com/u/22642664/gnome-run.png (needed file) and here's a screenshot of the result (this is of course with latest SVN) : without clip_to : http://dl.dropbox.com/u/22642664/edje_clip_to_bug1.png as expected, we have a red background with the image on top with clip_to : http://dl.dropbox.com/u/22642664/edje_clip_to_bug2.png The background is now black and the image seems to have been xor-ed with the red... Another bug is apparently with the 'aspect' attribute of an IMAGE type part. If you set the aspect attribute, then the part will forget about its real size. More precisely, if I have an image in a group, and I create in another group a part of type GROUP and embed that group in it, then the image will overflow from its part. Hard to explain, so here's a sample code : http://dl.dropbox.com/u/22642664/edje_aspect_bug.edc Here's the result of the test without aspect: 1.0 1.0; http://dl.dropbox.com/u/22642664/edje_aspect_bug1.png And here it is again when you enable the aspect keyword : http://dl.dropbox.com/u/22642664/edje_aspect_bug2.png All I want basically is to have the image inside its group but with the proper aspect ratio. Note that adding 'to: bg;' in the relative positions doesn't seem to change anything, once aspect keyword is there, it just seems to take its size/position relative to the full window. I haven't tried without this GROUP part, but it might be reproducable just by doing a relative to keyword. Thanks for looking into this. p.s: Anyone knows how to use lua to get a part's object? all I saw in the doc is edje.edje() to create a new edje object.. but what if I want to write a script to get an existing part (like a text part) and modify it in lua? or in embryo how to change a TEXT part's text... Thanks, KaKaRoTo -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] new build tree for efl.
Hi all, A bit late to the party, I've been (and still am) very busy lately! What a nice surprise! Carsten, that's a very good idea, I agree and support the move to a single tree! Actually, what do you think about having one tree for core libs and one for toolkits like glib and gtk having separate trees? Just an idea, a would still personally prefer a single tree. For the other subjects thrown in this thread, I'm very happy to hear about the possible move to git, it's really great! And yes, I definitely agree that the move shouldn't happen until after the release.. there's no reason to do it right now, and it would just slow down the release at this point. So I think single tree move should be done asap, but the git move only after the release. As for the cmake debate.. I don't like cmake, honestly.. I've had to deal with it a couple of times and it was hell.. I ended up knowing how to use it (not how to create/modify it) and it is ok.. it just feels so weird and alien from the usual autofoo stuff that I don't feel at ease using it. However, seeing Gustavo's arguments, I tend to agree that it is probably preferable and it does have many good advantages. As for cross-compilation, it actually works great, you just need to give it the argument -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain/file and it will just cross-compile it.. I have made (with difficulty) a cmake toolchain file for the ps3, and I just give that as argument and it seems to work and properly create the libs I need with cmake, so it does make things simpler.. and I do like how fast it configures itself and the progress bar, etc... Yes, autofoo is bad, but we all know it and love it.. but yes, modifying configure.ac and makefile.am can be a huge pain. I would like to see the efl have cmake for testing purposes only (post single-tree with autofoo) before a decision is made. One thing I remember seeing in a project was autoffo around cmake.. so basically the ./configure would mkdir build and run the cmake command in it, and the Makefile would just run make in the build dir. This allowed people not used to cmake to just ./configure make normally and get the expected result without wondering how it should be done. I believe that if there is a move to cmake, that this kind of thing would be necessary. For the distcheck, I don't really know what to say, it's a very good point and I'm actually surprised that cmake doesn't support something like that. Implementing it with makefile.am could be a solution.. but the cost of maintaining both cmake and makefile files would be too high. Gustavo, find a solution for that if you want cmake to even be considered! (I think Carsten already made that clear) :) Anyways, good stuff, keep it up! I'm glad to see this happening! KaKaRoTo On Wed, Dec 14, 2011 at 8:04 PM, David Seikel onef...@gmail.com wrote: On Wed, 14 Dec 2011 13:40:16 -0200 Iván Briano (Sachiel) sachi...@gmail.com wrote: 2011/12/14 Cedric BAIL cedric.b...@free.fr: No, don't do that ! We were happily trolling on cmake and you try to divert the troll from it by focusing people on git. Now people will start to argue again about git... Every one, back to cmake troll ! Please forget about this minor things called git. :-) It's time for all of you to see the light. These build systems you like to praise so much are but the work of the Devil. They are tools to make you lazy and accustomed to go the easy way with things. Before you know it, you will find yourself selling your own souls to avoid a few more keystrokes. The only true path is to manually call the right compiler and linker lines on each file of the project I actually did that with my embedded project. Figured I did not really need pkgconfig and it's circular dependency on glib. The actual app itself is so easy to compile that a small shell script does it. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___
Re: [E-devel] Planning next Release of EFL
On Mon, Dec 12, 2011 at 10:15 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 4 Dec 2011 10:32:36 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: Hi all, To avoid getting into the same situation as the current one, I'd like to have a plan for the next release. I believe we should move to time-based releases such as kernel, firefox and others do, making the life of distributions easier as well. Freeze: 22-February Alpha: 1-March Beta: 8-March Release: 15-March (guess, if no extra beta/alpha is required) It would be also great to define the policy of new features. With the recent release we got some last-minute features to a codebase that was very stable (multisense and lua for Edje), this added some turbulence to the process and part of them were disabled at the end. With that said, if you have big features please merge them complete and at least somehow tested by more than you (ie: create a branch, send patches to maillist, ...). Otherwise wait 4 weeks more and you'll get it in! During this time you can easily keep the aforementioned branch or patchset for broader test. What do you think? i'm totally against timed releases. so lets sat 22nd of feb rolls around and we have added NO new features... we just do a release anyway? or 22nd of feb rolls around and a feature is in the middle of being ironed out? we release half done? we have to unpatch the feature because of a magic date? no. not to mention the unholy mass of work it is to release so many god forsaken libraries all at once. i've had enough of this multi-library tree thing. things are going to change come hell or high water. forget setting release dates until releases are more manageable. i'll send a new mail on this shortly. I think everybody agrees though... But I think that if 22nd of feb rolls over and there were no added features, then you got a bigger problem with the project than the release (it's dead!). As for a half-finished feature, if it's not finished by freeze time, then it should be discarded until the next release (which is fine since the next release shouldn't take too long to happen). Anyways, the release management should be easier once the efl are all merged into a single build tree, so that eliminates your other argument. Do you have a plan/ETA for the single-tree change? Hopefully by feb 22nd? :) KaKaRoTo -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][Ecore][Win32] Resolving the issue of mouse-down inside and mouse-up outside
Hi, Thank you for the patch! I had a quick look, I don't know anything about the Set/ReleaseCapture, so I don't know if that's good or not and I can't comment on it. I noticed though you added a free callback in your code for the event, but it's not needed since ecore will free the event itself. See the code here : https://github.com/kakaroto/e17/blob/master/ecore/src/lib/ecore/ecore_events.c#L272 And the documentation to ecore_event_add also states : If @p func_free is NULL, free() will be called with the private structure pointer. Let's wait for someone else to comment on the Set/ReleaseCapture changes you added. Thanks again, KaKaRoTo On Wed, Nov 16, 2011 at 7:43 AM, cnook kimci...@gmail.com wrote: Dear All, Hello~ I think you (especially Mr. Vincent, Raster) know this issue. If user mouse-down on the one of items in elementary_test, move(drag) the mouse to the outside of window, and mouse-up, Then.. it works improperly.. For example.. You can scroll the list of elementary_test without mouse-down. The attached patch will resolve this issue. Please review the patch and give any feedbacks. Thanks. Sincerely, Shinwoo Kim. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, 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-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] New EFL release cycle 1.1/1.5 ALPHA
Humm.. the PS3 toolchain doesn't have pthreads and it all works fine without it. Make sure you also add --disable-async-render --disable-pipe-render --disable-async-preload just in case... (in my case, it doesn't detect pthread at all, in your case, you seem to force disable it). On Wed, Nov 16, 2011 at 2:40 PM, David Seikel onef...@gmail.com wrote: On Wed, 16 Nov 2011 18:31:40 +1000 David Seikel onef...@gmail.com wrote: On Wed, 16 Nov 2011 15:20:24 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: We'd like to announce a new release cycle alpha release of several Enlightenment components http://download.enlightenment.org/releases/eina-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/eina-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/eet-1.5.0-alpha.tar.gz http://download.enlightenment.org/releases/eet-1.5.0-alpha.tar.bz2 http://download.enlightenment.org/releases/evas-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/evas-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/ecore-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/ecore-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/embryo-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/embryo-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/edje-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/edje-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/efreet-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/efreet-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/e_dbus-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/e_dbus-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/eeze-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/eeze-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/expedite-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/expedtie-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/evas_generic_loaders-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/evas_generic_loaders-1.1.0-alpha.tar.bz2 /me updates his embedded project to use these tarballs, and sees what happens. Though I only use the first six. Got stuck on evas. Even with --disable-pthreads, it still tries (and fails) to build with pthreads. So I can't test any further on my embedded project. Half way there. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, 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-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, 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-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: About release, snapshots and openBSD port
--- Resending from my server, it seems gmail's IP has been blocked by sourceforge because of abuse ... Thanks Stefan for another well written email, I guess that psychology minor is indeed useful :) Thanks Mike also for some of the things you said.. I didn't like most of it, but I did find some interesting points that you've made, the most important one being that this discussion should have been taken off list and I agree with that. Anyways, this discussion is clearly leading nowhere at this point, and I can see how my reactions weren't the most adequate. I think it's time to close this chapter of the drama, and for that (and to avoid writing another long email), I will refrain from commenting on anything you guys said. Instead, I would like to simply apologize to raster in case I ever offended you with anything I've said. This was not a personal vendetta against you and I have nothing against you, but I did not like our interactions in the past and I wanted to make you aware of that. That being said, I hope we can all move on and continue working together towards a common goal, with no bad blood within the community. Again sorry for my previous outbursts, and sorry if I annoyed or offended anyone. Thanks, KaKaRoTo On Sun, Nov 13, 2011 at 06:31:55PM +0100, Stefan Schmidt wrote: Hello. [Long delay, mothers birthday, sick, etc] On Sat, 2011-11-12 at 21:58, Youness Alaoui wrote: Thank you for this well written and thought out email, I agree with you on everything you said (even the bits in which you criticize me), so thanks again for that. The psychology minor should be worth at least something. :) I would just like to add a few explanations, you seem to see me as someone who barks up at raster and tries to change him by forcing him into a corner, and you are right to believe that because I guess that's what I show somehow. However that is and was not my initial intention, so here is my story : Initially, I've had a few interactions with raster which always seemed to end up with me feeling bad because of how he talks to me, I kept feeling almost bullied, but I didn't give it too much attention, I was told by others not to take it personal as that's just how raster is. My excitement for the project was getting hit everytime I spoke to raster. I cannot point out a log and say this sentence was harsh, it was just the general mood of the discussions, the way he talks to you makes you feel dumb and he seems condescending, even if he's trying to be nice. And while I understand the stress issues you've brought up, I did not take these into consideration at the time, as all I could see was someone's attitude being that of a condescending leader who takes charge, is very stubborn, and doesn't accept any criticism. As a side joke, someone told me that he was able to change raster's opinion once, and it was an accomplishment. So I believe he is stubborn, he sees his designs, his ideas as better than everyone else's and he understands everything while others cannot understand what he knows, so when you give a suggestion, he turns it down in such a way that it feels I know better, you are stupid, your intellect cannot begin to grasp the infinite knowledge needed to understand the issue at hand, so I will tell you what to do and you must accept it.. this is not what he says, but this is what it feels when you talk to him, and in the end, he looks arrogant and almost like a bully. I'm not saying that's who he is, I'm just saying that's what it feels like to others who talk to him (ie. me in this case). This attitude made me feel bad a few times and demotivated me, thankfully, I've had some excellent chats with other devs in #e.fr and the community there is warm and welcoming and now I usually just hang there instead of #edevelop. Now I've seen many people talk the same about raster, many feel the same way, and many simply tell me not to talk to him, or that we shouldn't discuss anything with him, and I've seen a lot of 'hate', anger, disappointment with some of the things he does, but noone seems to just tell him. One thing I really hate, it's that excuse of he is like that, so let him. That sentence pisses me off to no extent and I usually reply with he's a pedophile, so let him rape children because that's just how he is?, it's an extreme counter example, and that's how I always feel when people have to tiptoe around someone else's defects. If someone is being an ass, you tell him he's an ass and he must fix himself, you should not have to endure him just because it's his personality. Everytime, the pedophile example pops to my mind, and I get frustrated when I see people tiptoeing around others. Well, the unpleasent example aside, tiptoeing around other peoples defects is what other people actually call social skills. :) If you work with people you need to understand what
[E-devel] Fwd: About release, snapshots and openBSD port
On Fri, Nov 11, 2011 at 10:26 PM, Carsten Haitzler ras...@rasterman.comwrote: On Fri, 11 Nov 2011 21:49:46 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: WE were asked to generate the tarballs. WE... not him. if he wants tarballs he can make them himself. i would never have said no. i can't and won't stop him - he can make the tarballs all he likes! but WE were asked to make them. that means one of us - presumably me, has to generate them UPLOAD them and then TELL SOMEONE they are uploaded and exist! if HE wants tarballs and wants to build them himself.. absolutely. go ahead! by all means! he can also just use make dist which is simpler. but that isn't what was asked for. 1 - read what I wrote, I said that for now he used the script, until the script gets put on a server on which I don't have access 2 - why presumably me ? I haven't proven your point, I don't see where I did. On the contrary, I proved that you can create a simple script that does it. Who asked for any announcements? who even asked for uploads? The guy used my script to generate the tarballs from svn on his own machine and then used the tarballs in his build system and was happy about it. Ideally, the script should run on a server in a cron job and copy the files to a publically available directory, I'm not uploading the files because I don't have access to such server. But that is outside the scope of what was asked, I helped him get what he wanted, he's happy about it, he'll continue porting to BSD or whatever he wants to do with it. In the end, we didn't lose a contributor, and that's the final goal that was reached (who btw said that he got demotivated after talking to you because of the way you spoke). Of course, it's less useful than a make distcheck, that's why an actual build system would be needed for continuous integration checks, but that is besides the point. They wanted a tarball, I provided a tarball, nothing more, nothing less. Stop assuming what the other person wants, and then make judgment calls on what you think they may or may not want. That's not how you can build your community, by closing all doors in the face of everyone who wants to help. dude... did you READ AT ALL WHAT VTORRI ASKED FOR? my god! you really want to just run around with your opinions without ever reading the facts. they asked to HAVE daily snapshots. they aren't asking how THEY can do it themselves. they are asking for them to BE done for them. you OFFERED an alternative. man - YOU demotivate ME. your snide comments, grandstanding on your soapbox without ever bothering to READ the discussion or facts at hand - which you very clearly didn't bother to read, or your understanding of english is not so great. when someone asks to have snapshots - they ask for tarballs, which need to be generated and uploaded. we can generate them on the server, but a cron job is no better than a random svn checkout done by them. if you READ the emails and READ the irc discussion you might have the facts. on email i asked what's so hard about svn. on irc i got the response that they have no idea when to svn checkout because they don't know if it works or not. put that together with a cron job either done by them OR us is the same thing. nothing has improved. pointless email as you're simply not reading the actual content. you don't seem to read what I wrote, you ignore the facts.. the facts are not the commits or how bad they were, the facts were your attitude and condescending bullshit. but yeah,you don't seem to be able to acknowledge that, since you're perfect and everyone else is wrong. Thank you Vincent and Gustavo for sharing your concerns about this, and it's too sad that the new contributor has become another victim of raster's poor social skills. That's what I wanted to avoid, that's what I wanted raster to understand, and I was hoping for him to reply with something like sorry if I offended you, that wasn't my purpose and that's it, the guy stays with us, but I guess raster has too much pride and is too self-centered to recognize his own faults. I think I will follow Vincent's advice and not reply to this thread anymore, raster clearly showed he has no comprehension of what people are trying to tell him here, so this is just an endless drama with no possible resolution. On Fri, Nov 11, 2011 at 8:30 PM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Nov 2011 15:55:46 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: so you've basically proven my point - it's the same as an svn checkout... and that script still doesn't upload them, or make any announcement that they have been created. it's actually less useful than make distc (or distcheck) and much longer. there is no quality checking there... and which point it's busywork. Here, I just wrote a script : http
Re: [E-devel] Fwd: About release, snapshots and openBSD port
not trying to change raster or to force him into a corner. I'm trying to make him realize what he's doing because I honestly believe that he's killing the project in some way. He's building the project, but killing it at the same time. I don't think he has much leadership skills, he demotivates people, he drives away contributors, he makes decisions that are what he thinks is right and you cannot contradict it even if you know it's the wrong move. It's a double edged sword, E17 wouldn't be where it is today without him, but at the same time, it might have been in a better state without him (more contributors, huge community, main WM in a major distro, etc...), you never really know how it could have turned out. Either way, the issue here is not him being in charge of the project, I have zero personal issues with raster, honestly. The only thing that I decided to do was not to keep my mouth shut only to avoid drama or to avoid offending raster. Like in this mail, I see a contributor offended, I poke at raster for it. I feel like everyone decided to let it go, to shut up and let raster be raster, in my mind, I cannot accept that. And this would apply to anyone, not just raster of course. I don't want to force him into a corner so he apologizes, I just want to tell him if you got nothing good to say, then don't say anything and I hope he's smart enough to realize that and understand that he's poisoning the project and put his pride aside for the benefit of the project, but I know it's almost impossible for someone (especially stubborn like him) to see his own faults and accept them. I think that's pretty much my story as to this whole deal and I hope you can understand me better, I'll answer your specific comments inlined below. On Sat, Nov 12, 2011 at 8:26 PM, Stefan Schmidt ste...@datenfreihafen.orgwrote: Hello. I have not joined any of these flame wares before as I don't think to change anything significant but only start to hurt peoples feelings for each other. But I had to join here as it started to look like a witch hunt on raster here. Please take a moment when reading this. Thanks for your time. Not a witch hunt on raster, honestly. Simply frustration at a dying community. If someone else is causing issues, I will speak out just the same (and if I am the one causing issues, I would not want it any other way than people calling me out for my mistakes). On Sat, 2011-11-12 at 13:43, Youness Alaoui wrote: you don't seem to read what I wrote, you ignore the facts.. the facts are not the commits or how bad they were, the facts were your attitude and condescending bullshit. but yeah,you don't seem to be able to acknowledge that, since you're perfect and everyone else is wrong. Great, personal insults are getting us really forward here. This is one of the social skills you are calling here for. Discussing with others without getting into personal insults. Given this mail and the long rant where you behaved like a dick (citation from you) are letting me wonder if you are able to call others for things you do not handle very well on your own. Something to thing about. Sorry, I don't see the personal insult in the quoted text. I do see sarcasm though. I know quite well my issues, I am usually a nice person until you make me snap, at which point, you won't recognize me. I have absolutely no problem in being a dick towards people who, I believe, deserve it. I'm a reactionary dick if you want.. I see raster as being a dick by default. However, I am pointing out what annoys me in raster's behavior, and I believe I am entitled to do that without the need for me to perfect.. noone is perfect anyways, so no reason for me to shut up until I fix my own personal issues. Thank you Vincent and Gustavo for sharing your concerns about this, and it's too sad that the new contributor has become another victim of raster's poor social skills. That's what I wanted to avoid, that's what I wanted raster to understand, and I was hoping for him to reply with something like sorry if I offended you, that wasn't my purpose and that's it, the guy stays with us, but I guess raster has too much pride and is too self-centered to recognize his own faults. And you wanted that to happen by forcing him into a corner? That is almost always the best recipe to get the opposite of what you wanted. Forcing people trigger over reactions from them. Self protection, naturally for humans. Changing the behaviour of people is a long and exhausting process. Nothing you can do by sending of several mails. And before people even accept what they here from others they need to respect them. Respect them for their doings and ideas they have come up with over time. Again nothing you can achieve in some weeks. He may not respect me, so he has no reason to listen to me and change his behavior. But I was hoping to maybe trigger others to finally speak out. I see a lot of people angry at raster
Re: [E-devel] About release, snapshots and openBSD port
On Fri, Nov 11, 2011 at 8:49 AM, Bruno Dilly bdi...@profusion.mobi wrote: On Fri, Nov 11, 2011 at 11:19 AM, Jonathan Armani d...@asystant.net wrote: Hi, On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler ras...@rasterman.com wrote: On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: Hey I'm talking a lot with an openBSD dev, and currently it's very hard for them to follow the changes in the trunk. What they would like to have is snapshots to provide easily patches for the EFL. how is that hard? svn checkout or update instead of wget. u also need to run autogen.sh. Would it be possible to have, during the freeze period, some daily snashots ? It would be nice to fix the openBSD port for the release. open to patches, but none have been submitted. Are you kidding ? I though you were reading the svn log. I take a lot of my time pushing / polishing these diff (special thanks to vtorrin, bluebugs and billiob). So you come from nowhere and make all this work looking bad, here and on irc, that's amazing. Sometimes he acts this way. Don't take it personal, don't let it demotivate you. Keep the good work ! =) Reminds me of some of the stuff I've been saying... As for don't have time to do tarballs everyday.. well, that's why there's something called scripts and cron jobs.. those things exist, might be good to use these awesome technologies. if they require tarballs to test and can't just run svn instead to fetch the source... i don't have the time each day to make tarballs when they can just as easily fetch from svn. it's the same work on their part. making tarballs is MORE work on our part. You missed the point, we want to be sure that the final archive will be ok. I'm not asking for snapshot on a daily basis, only some rc before the final archive. (Wait no project did alpha rc, right ?) Note that i discuss also with a Mageia e17 maintainer, and he told me that such snapshots will help him too. a snapshot has no more quality than an svn checkout, so other than a mental block thinking svn == totally unstable/unusable and an unwillingness to use it because of a mental block, i don't see the point. yeah a mental block, I think you don't want to know how many time I have to reroll a dist to get all working and how frustating it is. a release that has had quality assurance done on it is a different matter - but we arent doing them every day. hell no - not with al the efl trees we have. only chance of that is if we stopped having separate libs and just merged them into a single efl tree. Vincent -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Senior Developer ProFUSION embedded systems http://profusion.mobi -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] sound api plan
Carsten, a few people have noted their disappointment (and anger) at this
being merged and some requested it to be reverted, you didn't even take the
time to answer them and address their concerns.. Could you please take the
time to do that, since you obviously had time to respond to David with such
a long email, it looks bad for you to respond to only what you want and
ignore everyone else.
On Fri, Nov 11, 2011 at 1:33 AM, Carsten Haitzler ras...@rasterman.comwrote:
On Thu, 10 Nov 2011 18:50:45 +1000 David Seikel onef...@gmail.com said:
On Tue, 8 Nov 2011 16:33:42 +0900 Carsten Haitzler (The Rasterman)
ras...@rasterman.com wrote:
On Tue, 8 Nov 2011 07:23:27 +0100 (CET) Vincent Torri
vto...@univ-evry.fr said:
On Mon, 7 Nov 2011, Carsten Haitzler (The Rasterman) wrote:
attached. this was a sample edc that would be able to play audio,
not just single samples but whole sequences across multiple
tracks as well as control specific channels and tracks. it didn't
specify looping params yet or other additional stuff.
i've never heard about that sound plan before the commit. The patch
was not public and we could not have discussed about it before the
commit. So I really don't like the way it came into edje.
i'm not sure this is much different from anything else that goes on
in efl. i have done work for a decade+ without discussing patches on
the mailing list first. so have most developers. as such this patch
this time was going through me. the comments on the patch so far
havent actually commented on the edc api it adds at all which
everyone is up in arms about for release. so since everyone
complaining isn't actually talking about that... i'll write it here
in short form. it adds: sounds {
sample {
name: NAME ENCODING;
source: SAMPLE_FILE;
}
...
tone: NAME FREQ;
...
}
and 2 more actions:
PLAY_SAMPLE NAME SPEED;
PLAY_TONE NAME DURATION;
that's it. unfortunately to make this WORK u need a chunk of infra
like being able to load and encode samples into edj files, decode
them, play and mix them, resample them, etc. all of which is opaque
to the api.
/me picks a spot in this thread to actually discuss the API. Here
seems the best.
hooray! :)
A quick look over it, and the example, and the plan, and it seems
mostly sane. One thing that stands out straight away in the examples is
the way that a bit of music was defined.
First thing is that you are using something that looks like a typical
tracker, which is fine in itself. Lots of people are familiar with
that. It's a bit verbose though.
well my hope actually was that later we can provide a mod/xm/s3m converter
that
can load one of these files and produce a bunch of edc to include. the only
reason i didn't go right to use libmikmod and just inline mods in your
edj was
that these mod formats don't support ogg/mp3 etc. style sample compression
and i
really want that for space efficiency reasons. i actually wasn't expecting
peolpe to write music in edc. it's POSSIBLE and to be honest - when i did
tracking you literallly did almost what the edc says in text. u arrow down
7,
hit a key to play the sample at that speed (c-3/b-3/f#-2 etc.). you'd
literally just have the sound played at that time as the added bonus.. :)
I think it would be great to also provide an alternative that is more
like MIDI, as that is also used by a lot of people. Have both, that
would cover most things. Actually, the plan includes using a program
per note, which is a bit more MIDI like, but even more verbose than the
pattern style.
a program per note would be bad. programs dont guarantee any timings of any
sort. if u want N channels synced you're in trouble. :( but if u want to
use
embryo.lua then u can write CODE to play but u'll be writing code to have a
timer and call play funcs... maybe from a passed in table/array.. but it'll
boil down to the same thing.
can you expand on the midi thing with some details? last i knew of midi it
was
roughly the same as a single track of a tracker with no defined length -
just
commands to play instr id X at note Y like thngs - much like a tracker.
Can we cut the verbosity levels? Though I guess edje has a similar
problem, and the solution is to go to embryo, or lua (which so far
seems to end up being about half as verbose as embryo, though YMMV).
i'd say the verbosity is on par with a tracker... is that bad?
Second is what you are doing to provide a scale. I see you are
basically dividing an octave into 7 equal parts, then doing maths to
arrive at the numbers to feed into the system. Now I'll admit that
oh.. thats just making use of edje_cc's math handler. speed is 1.0 for
play
note at given samplerate ie - if sample is 44.1khz - then play at
44.1khz. 2.0
== play at 88.2khz. 0.5
Re: [E-devel] sound api plan
On Fri, Nov 11, 2011 at 12:18 PM, David Seikel onef...@gmail.com wrote: On Fri, 11 Nov 2011 11:50:08 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Carsten, a few people have noted their disappointment (and anger) at this being merged and some requested it to be reverted, you didn't even take the time to answer them and address their concerns.. Could you please take the time to do that, since you obviously had time to respond to David with such a long email, it looks bad for you to respond to only what you want and ignore everyone else. Actually, raster has replied a couple of times to those concerns in this thread. I checked before writing that, he only replied to Vincent's mail with : i'm not sure this is much different from anything else that goes on in efl. i have done work for a decade+ without discussing patches on the mailing list first. so have most developers. as such this patch this time was going through me. which isn't let's talk about your concerns but rather a it's fine,I've always done that. Then Mike, Gustavo, Tom and Rafael all responded, agreeing with Vincent and adding their own concerns, and I haven't seen an answer to any of their mails. For the record, I'm not really interested in whether or not it goes in for this release or not. It does not do anything for me within the time frame of this release that I had not already done for the relevant projects. For future projects I'm planning, sure it will be great. So my efforts are on the let's actually talk about the API, and not saying anything about it's release timing. I personally like the API, it is probably too complex for what most people would use it for, but as long as you can do the simple things easily but use more complex constructs for complex stuff, I'm fine with that (I haven't actually looked at how easy it would be for a simple play this .wav when the button is clicked, so can't see if the easy requirement is satisfied). One issue though is that from what I was told, the sound engine is modular inside edje and an alsa module was written. I find this completely absurd to have a sound abstraction module inside edje. It clearly should go into ecore (ecore_sound or something) and have edje use that, because then you'd have people writing alsa/oss/pulse/ps3 modules for edje, but noone can use them outside of edje. That's a big design flaw right there and that's something I disagree with. I am truly excited about having something powerful like that in edje though, but I see Mike/Gustavo/Tom/Rafael's concerns + some of the stuff said on IRC and I have to agree with them. While this is cool, it is not the right time for it to get merged, the API should have been discussed, and it's an important feature that needs to be matured before a release and the 2 week feature freeze is definitely not enough to mature it. Its place is in edje 1.2 or whatever and not to be thrown into svn right before the deadline. While the feature freeze means you can't add new features, it doesn't mean that you can add anything just before it. This isn't the right way of doing things, and it feels like this feature might have been committed at the last minute out of pressions from samsung rather than from a consensus of this is needed and it's the right thing to do amongst the EFL developers. Just my 2 cents. KaKaRoTo -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] About release, snapshots and openBSD port
On Fri, Nov 11, 2011 at 12:42 PM, Carsten Haitzler ras...@rasterman.comwrote: On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: Reminds me of some of the stuff I've been saying... As for don't have time to do tarballs everyday.. well, that's why there's something called scripts and cron jobs.. those things exist, might be good to use these awesome technologies. hooray for your snide comments. wonderful attitude. you were not there on irc, nor did you even seem to have read the material at hand (the patches). seriously, what's up with you? It wasn't my remarks, it was the remarks from someone who wants to contribute to the project and who got offended by the way you talked to him. All I did was point out what I said before in the hopes that you'll realize that your own attitude is a problem. do i suddenly have to be mr. nice to everything? oh wow! how wonderful! so awesome that you broke evas's api on your openbsd packages. so great to see. we'll love hearing the app developers ask us for help about their apps not working on openbsd, when we will have zero clue that it was an api/abi breakage added specifically on openbsd. that's just awesome. please - make more patches just like that!. if its bad, it's bad. reasons were explicitly given for it being bad. This has nothing to do with the patches, I didn't know there were patches, I didn't see any patches, and I don't care about them either. My point is you should learn how to talk to people if you don't want to drive away all the contributors and end up alone in the project. and as for well just use scripts - have to write and test those too. and if its just a cron job... then its NO BETTER THAN A RANDOM SVN CHECKOUT. that was my point... which you failed to read. if you don't sit down and spend at least some qa time on the tarballs... then its pointless. this is my point on a mental block. i keep hearing it from people omg svn trunk must be so unstable!!! how can i use it? - it's the image that just because its in trunk (or head/master/whatever) that it must be so unstable and a tarball made every day is going to be better. it's a RELEASE process of freezing and fixing just bugs that improves quality... not make dist; scp *.tar.gz For you it's no better than a random svn checkout, good, but if they want a tarball, give them a tarball, as for what if it doesn't build, well it should always build, noone should even commit anything without testing his work and making sure it doesn't break anything.. while breakage does happen, it's not something that happens 10 times a day, and it's still fine, if a tarball is fucked, then you can always say use the one from tomorrow. There is a difference between having a build system do a wget and a build system do a svn checkout, maybe that's why they need tarballs, so they prepare their build system and when the release is out, they just change the URL instead of changing the whole system of downloading the image... And it's not about svn is unstable mentality, it's about tarballs are more convenient. As for the scripts, no you don't have to write and test those, you can say ok fine, someone write it and we'll put it on the server as a cron job, if noone does write the script for you, then too bad for them, it's not your responsability. If you wanted, I would have made the script myself.. we already have a script that creates a svn tarball everyday for aMSN, you could reuse the same script basically, and I could adapt it to the EFL. It's the same as svn? yeah, so what? it's better to help them by giving out the tarball even if it's the same as svn rather than telling them to fuck off. if they require tarballs to test and can't just run svn instead to fetch the source... i don't have the time each day to make tarballs when they can just as easily fetch from svn. it's the same work on their part. making tarballs is MORE work on our part. You missed the point, we want to be sure that the final archive will be ok. I'm not asking for snapshot on a daily basis, only some rc before the final archive. (Wait no project did alpha rc, right ?) Note that i discuss also with a Mageia e17 maintainer, and he told me that such snapshots will help him too. a snapshot has no more quality than an svn checkout, so other than a mental block thinking svn == totally unstable/unusable and an unwillingness to use it because of a mental block, i don't see the point. yeah a mental block, I think you don't want to know how many time I have to reroll a dist to get all working and how frustating it is. a release that has had quality assurance done on it is a different matter - but we arent doing them every day. hell no - not with al the efl trees we have. only chance of that is if we stopped having separate
Re: [E-devel] About release, snapshots and openBSD port
Here, I just wrote a script : http://svn.enlightenment.org/svn/e/trunk/devs/kakaroto/create_tarballs.sh It defaults to building tarballs for eina eet evas ecore embryo edje efreet e_dbus eeze (list suggested by Vincent), but you can specify any libs you want as arguments. It does the svn export (no .svn dirs) autogens then tars them. I didn't make it do a make distcheck because that requires a Makefile, which requires configure to run, which itself will require dependent libraries. This should be enough for the purposes of providing a simple mechanism (a tarball) to those who do not want to bother with checking out svn. If this could go into whatever server as a cron job, and make it dump the tarballs to a directory somewhere (and let the web server's indexing take care of listing the files), I think that should be enough. Jonathan, let me know if that's all you need or if you need something else. And if Carsten was right and you need a guarantee that those tarballs are 'tested and stable', then let the answer be yes, and let's just assume it is stable, the code in svn should be stable and we are in feature freeze already.. also that's what we all use daily so it should be fine. I hope that helps. Youness. On Fri, Nov 11, 2011 at 2:55 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Fri, Nov 11, 2011 at 12:42 PM, Carsten Haitzler ras...@rasterman.comwrote: On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: Reminds me of some of the stuff I've been saying... As for don't have time to do tarballs everyday.. well, that's why there's something called scripts and cron jobs.. those things exist, might be good to use these awesome technologies. hooray for your snide comments. wonderful attitude. you were not there on irc, nor did you even seem to have read the material at hand (the patches). seriously, what's up with you? It wasn't my remarks, it was the remarks from someone who wants to contribute to the project and who got offended by the way you talked to him. All I did was point out what I said before in the hopes that you'll realize that your own attitude is a problem. do i suddenly have to be mr. nice to everything? oh wow! how wonderful! so awesome that you broke evas's api on your openbsd packages. so great to see. we'll love hearing the app developers ask us for help about their apps not working on openbsd, when we will have zero clue that it was an api/abi breakage added specifically on openbsd. that's just awesome. please - make more patches just like that!. if its bad, it's bad. reasons were explicitly given for it being bad. This has nothing to do with the patches, I didn't know there were patches, I didn't see any patches, and I don't care about them either. My point is you should learn how to talk to people if you don't want to drive away all the contributors and end up alone in the project. and as for well just use scripts - have to write and test those too. and if its just a cron job... then its NO BETTER THAN A RANDOM SVN CHECKOUT. that was my point... which you failed to read. if you don't sit down and spend at least some qa time on the tarballs... then its pointless. this is my point on a mental block. i keep hearing it from people omg svn trunk must be so unstable!!! how can i use it? - it's the image that just because its in trunk (or head/master/whatever) that it must be so unstable and a tarball made every day is going to be better. it's a RELEASE process of freezing and fixing just bugs that improves quality... not make dist; scp *.tar.gz For you it's no better than a random svn checkout, good, but if they want a tarball, give them a tarball, as for what if it doesn't build, well it should always build, noone should even commit anything without testing his work and making sure it doesn't break anything.. while breakage does happen, it's not something that happens 10 times a day, and it's still fine, if a tarball is fucked, then you can always say use the one from tomorrow. There is a difference between having a build system do a wget and a build system do a svn checkout, maybe that's why they need tarballs, so they prepare their build system and when the release is out, they just change the URL instead of changing the whole system of downloading the image... And it's not about svn is unstable mentality, it's about tarballs are more convenient. As for the scripts, no you don't have to write and test those, you can say ok fine, someone write it and we'll put it on the server as a cron job, if noone does write the script for you, then too bad for them, it's not your responsability. If you wanted, I would have made the script myself.. we already have a script that creates a svn tarball everyday for aMSN, you could reuse the same script basically, and I could adapt it to the EFL. It's the same as svn? yeah, so what? it's better to help them
Re: [E-devel] About release, snapshots and openBSD port
On Fri, Nov 11, 2011 at 8:37 PM, Carsten Haitzler ras...@rasterman.comwrote: On Fri, 11 Nov 2011 14:55:14 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Fri, Nov 11, 2011 at 12:42 PM, Carsten Haitzler ras...@rasterman.comwrote: On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui kakar...@kakaroto.homelinux.net said: Reminds me of some of the stuff I've been saying... As for don't have time to do tarballs everyday.. well, that's why there's something called scripts and cron jobs.. those things exist, might be good to use these awesome technologies. hooray for your snide comments. wonderful attitude. you were not there on irc, nor did you even seem to have read the material at hand (the patches). seriously, what's up with you? It wasn't my remarks, it was the remarks from someone who wants to reminds me... wasn't? reminds me was about a different thread that I suppose (hope) you remember, which correlates what this guy's opinion was. contribute to the project and who got offended by the way you talked to him. All I did was point out what I said before in the hopes that you'll realize that your own attitude is a problem. maybe you should read this: http://www.enlightenment.org/~raster/e.fr.txt whatever. i was asked to review - i was talking to vtorri about the patches and going eh? wtf? why did they change api? that's really bad! why do all this work to disable chained_mempool?... armani turned up and got offended at me having ... oh dear.. a negative opinion of the patches... gasp. shock. horror. how dare someone think negatively of them~ yes. everyone is a hero and everyone is #1. no one can ever do anything bad/wrong. we must praise everyone at all times. I don't need to read that (and I have better things to do than fight an endless war on who is right). And again, it's not about your criticism of the patches, it's about the way you say it. I don't know how you said it, but in the end, the contributor was offended, and my point was that the way you said it offends people. if you actually READ the exchange my comments boiled down to: * evaluating patches with some level of bewilderment at many of them. * expressing exasperation that these patches were being used for openbsd builds and breaking api without talking to us - wishing they'd come and discuss. remember this is the FIRST i saw of these patches when vincent pointed me to them to have a look/review. * saying that tarballs and svn checkouts are the same and you have to invest time to make tarballs, test, make announcements etc. to raise the quality and that isn't appreciably better than an svn checkout. * saying that i was still at work, busy and i have no time and then being given the well i'm a cto and you have a haughty tone lines. if anything i should be offended at someone pretty much not caring that i'm busy and pulling the well i'm busy too line implying that it's irrelevant and i should just do as requested. of course without any knowledge of the conversation you are instantly deciding i'm going off and saying things i didn't. i didn't say anything like you are a bunch of useless people or you'll never get those patches right - give up. i gave a frank and direct evaluation without sugarcoating. people who cannot handle that are going to have trouble in every FOSS project out there. the patch evaluations from them are pretty much the same as what i did. It doesn't matter if your comments were right or not, the way you say them is bad, that's all I'm saying, and I'm not the only one saying that. do i suddenly have to be mr. nice to everything? oh wow! how wonderful! so awesome that you broke evas's api on your openbsd packages. so great to see. we'll love hearing the app developers ask us for help about their apps not working on openbsd, when we will have zero clue that it was an api/abi breakage added specifically on openbsd. that's just awesome. please - make more patches just like that!. if its bad, it's bad. reasons were explicitly given for it being bad. This has nothing to do with the patches, I didn't know there were patches, I didn't see any patches, and I don't care about them either. My point is you should learn how to talk to people if you don't want to drive away all the contributors and end up alone in the project. you need to learn to actually understand the topic before spouting your opinions. you were not there for the conversation. for your reference i linked to it above. you didn't see the patches being reviewed so again - how can you comment? how can you know that the review was justified based on the content? Again, nothing to do with the review, the end result is what I commented on, the guy was pissed/annoyed/offended/whatever, and that is the end result that I'm talking about. Whether your comments were justified
Re: [E-devel] Improving Elementary for the release
On Tue, Nov 8, 2011 at 9:18 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Nov 7, 2011 at 10:40 PM, Youness Alaoui
kakar...@kakaroto.homelinux.net wrote:
Ok, I checked Ecore.h and I see what you mean, but that's only useful if
you break the API, the padding is useful for not breaking the API but
keeping the .so ABI-compatible.
For example, if you only add a function to the API, you add the @since in
the docs, and all the software that was linked to your .so will still
work
because the other functions are the same and their behavior is the same,
so
it's not an API break, but you incremented the API with a new function
that
can be used by future apps.
If that new function needs a variable in the structure, then you can just
replace one of the void * paddings and that's it, it works..
If you don't have padding and you add a new field in the struct, the
sizeof(struct whatever) will change, so anything that instanciates your
structure will be allocating wrongly sized memory and that can lead to
memory corruption (since your old API will be compiled with the new
sizeof). Thus breaks the ABI and it forces every app using your library
to
get recompiled (no code change, it just needs a recompile) for it to
work..
this also means that your .so version will need to change, .so.1.1
instead
of .so.1.0 for example, it basically amounts to the same as breaking the
API even though it's not necessary if you had padding.
Of course, any internal structure doesn't need that, so if you allocate a
structure using a function call and the user of the lib only sees it as
an
opaque struct pointer, then you don't need padding, but if the struct
itself is defined in the .h and is public, then it would need the padding
to avoid breaking the ABI/API for compatible+incremental API changes.
This is a stupid workaround used in Gtk world. With version you can do
that and even more, you can even reorder fields, like below:
yes it's a workaround in gtk world, doesn't make it stupid though.
And no, you missed my point completely, you can't do that with version.
if (st-version == 1) {
Old_St *s = (Old_St *)st;
code_accessing_the_old_way(s);
} else if (st-version == 2) {
code_accessing_the_new_way(st);
}
In other words, you can know exactly what to do, and not just assume
you won't break because there is enough allocated memory to access.
yes, that is *only* valid if you write your app after both version 1 and 2
have been released, and it means that the structure needs to be renamed
between both versions so it doesn't conflict, and mostly it means that your
version 2 breaks the API from version 1. If you read what I wrote, you'd
understand that the purpose is to release a new version without breaking
the API, without forcing every app to recompile itself or to change its
code... you cannot do that with version.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
In my opinion, Elementary.h should be split into smaller files that it includes, kind of like what Eina.h does. If structures are made public, they should have a 'void *padding[MAX_PADDING];' added to the end, makes it easier to not break the ABI when adding new stuff. Other than that, I don't know elm enough to comment on anything else. On Mon, Nov 7, 2011 at 8:12 AM, Cedric BAIL cedric.b...@free.fr wrote: Hi all, We are going to try releasing Elementary soon after the release of the EFL 1.1. I would like to start a discussion now on what should be done to prepare Elementary for a release. I have been doing a quick overview of Elementary.h. The first problem is that we have a lot of structure in it that should be allocated by the application and they don't have any information about version or size, so we will not be able to touch them after the release anymore. That's bad, I think we need to fix that by adding function that will do the allocation and zero the memory before giving the pointer to the app. The second point is about both gengrid and genlist. I would like to add a few new callback : - content_set/content_unset: when set, content_get will return an object, but it will be reused and it's real content will be set and unset later. This permit the implementation of some cache mechanisme directly inside elm_gen. - label_free: if set, it will be able to override the call to free. This could help, I have found many times that I am using stringshare or static string that really don't need to be strdup. Btw I don't like the name of that callback This second list of change should not break API/ABI once the first change are done. So not a big hurry, but they are simple to do and should help provide better performance. Of course I don't plan to play with this until the EFL 1.1 are out, so you have time for comment. I put here only the thing I want to do and how I plan to fix them. If you have some idea of what need to be fixed in Elementary before the release and how you want to do it, maybe answering to this thread will be a good idea. Have fun, -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
Could you explain what you mean by versioning or give me a link to something that explains it ? padding is useful so you can change your structure (and add new APIs) without breaking the ABI and forcing every app to recompile (changed sizeof). On Mon, Nov 7, 2011 at 2:35 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I'm strongly against padfings. Just have versioning and check it On Monday, November 7, 2011, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: In my opinion, Elementary.h should be split into smaller files that it includes, kind of like what Eina.h does. If structures are made public, they should have a 'void *padding[MAX_PADDING];' added to the end, makes it easier to not break the ABI when adding new stuff. Other than that, I don't know elm enough to comment on anything else. On Mon, Nov 7, 2011 at 8:12 AM, Cedric BAIL cedric.b...@free.fr wrote: Hi all, We are going to try releasing Elementary soon after the release of the EFL 1.1. I would like to start a discussion now on what should be done to prepare Elementary for a release. I have been doing a quick overview of Elementary.h. The first problem is that we have a lot of structure in it that should be allocated by the application and they don't have any information about version or size, so we will not be able to touch them after the release anymore. That's bad, I think we need to fix that by adding function that will do the allocation and zero the memory before giving the pointer to the app. The second point is about both gengrid and genlist. I would like to add a few new callback : - content_set/content_unset: when set, content_get will return an object, but it will be reused and it's real content will be set and unset later. This permit the implementation of some cache mechanisme directly inside elm_gen. - label_free: if set, it will be able to override the call to free. This could help, I have found many times that I am using stringshare or static string that really don't need to be strdup. Btw I don't like the name of that callback This second list of change should not break API/ABI once the first change are done. So not a big hurry, but they are simple to do and should help provide better performance. Of course I don't plan to play with this until the EFL 1.1 are out, so you have time for comment. I put here only the thing I want to do and how I plan to fix them. If you have some idea of what need to be fixed in Elementary before the release and how you want to do it, maybe answering to this thread will be a good idea. Have fun, -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Improving Elementary for the release
Ok, I checked Ecore.h and I see what you mean, but that's only useful if you break the API, the padding is useful for not breaking the API but keeping the .so ABI-compatible. For example, if you only add a function to the API, you add the @since in the docs, and all the software that was linked to your .so will still work because the other functions are the same and their behavior is the same, so it's not an API break, but you incremented the API with a new function that can be used by future apps. If that new function needs a variable in the structure, then you can just replace one of the void * paddings and that's it, it works.. If you don't have padding and you add a new field in the struct, the sizeof(struct whatever) will change, so anything that instanciates your structure will be allocating wrongly sized memory and that can lead to memory corruption (since your old API will be compiled with the new sizeof). Thus breaks the ABI and it forces every app using your library to get recompiled (no code change, it just needs a recompile) for it to work.. this also means that your .so version will need to change, .so.1.1 instead of .so.1.0 for example, it basically amounts to the same as breaking the API even though it's not necessary if you had padding. Of course, any internal structure doesn't need that, so if you allocate a structure using a function call and the user of the lib only sees it as an opaque struct pointer, then you don't need padding, but if the struct itself is defined in the .h and is public, then it would need the padding to avoid breaking the ABI/API for compatible+incremental API changes. @Boris: technically, only one void * could be enough, but that means that if you need 2 new fields, you'd have to create a substructure and set that as your void *padding, and add padding in it too in case you still need to add stuff to your substructure, and it complicates everything.. usually you'd set 10 or 20 padding pointers or something so you can keep adding stuff to the struct in the future. You could also not put any padding, but just have a void *priv; at the end, then put any additional thing in this priv pointer to a private structure, but it will limit you in the sense that you won't be able to add new public fields to the struct, and any additions will have to be private. As an example, this would be impractical in the case of a MouseEvent structure, if you wanted to add a new field to it, then it probably needs to be public, not hidden in a private opaque structure. What do you think ? On Mon, Nov 7, 2011 at 4:42 PM, Boris Faure bill...@gmail.com wrote: On Mon, Nov 7, 2011 at 22:37, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Could you explain what you mean by versioning or give me a link to something that explains it ? padding is useful so you can change your structure (and add new APIs) without breaking the ABI and forcing every app to recompile (changed sizeof). You should only need a spare (void *). -- Boris Faure -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
And I'm back! Been sick so haven't check my mails lately.. and I wanted to answer this thread. I tried to answer only the important bits to avoid making it super long to read/reply again. On Tue, Nov 1, 2011 at 12:59 AM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 1 Nov 2011 00:17:01 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Mon, Oct 31, 2011 at 9:42 PM, Carsten Haitzler ras...@rasterman.com wrote: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to that list there on the release page was a result of a group of e devs getting together at cebit and refining the existing more vague list. it was not just me. i was there. Alright, if that TODO was a group effort, then my apologies on the specific parts where I stated your todo. I'd like to point out though that when I said that, I wasn't just referring to you wrote it, but rather on you decided what to put in it, those who disagreed got ignored. You always seem to have the final word, and that's why I consider it your todo. But yes, I was not there, so I cannot know, so againt, just a hypothesis. actually others put things on that todo too - but yes i do act as final arbiter of it, but it most definitely was not entirely my todo just with others nodding their heads. yes - i did put a fair few items on that list. Being the final arbiter is fine as long as you consider everyone's opinions. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. and yes i need to Sorry, this seems unclear, yes I need to? what do you mean? yes you need me to spell it out? or yes, you need those 3 things I listed == an alpha is needed ? yes - need a freeze before release. yes need to fix bugs. but we have a mountain of bugreports ALREADY! have u looked in trac? check the active tickets. :) 250 or so of them. Are they all valid? If not, maybe it needs some triaging, anyone taking care of that? It doesn't matter that they are at the same time, what does matter is to have a fixed date for it. I said at the same time as efl 1.1 because cedric suggested that (at the conference). And this isn't a sudden desire, it's a desire that's been there for years, you just don't want to see it. You need time to rest post efl 1.1 release, fine, but set a reasonable date. why does it have to BE A FIXED DATE? why do i have to repeat this question - what is so MAGIC about that date. i s The date itself is not magic, we're not saying december 25th, or january 1st, or whatever other 'special dates'. But what will A DATE create is a deadline, and the deadline in itself will drive the development. Not everyone works like that, for sure, but I believe that most people will get more shit done if they have a deadline rather than whenever you can. And I've experienced this so many times.. no commits for 6 months on amsn, then we say we'll release next week, start building packages then 100 or 200 commits get sent in that single week (seriously). A deadline is a i've seen the reverse. deadlines come, deadlines go. no action. sure, but the most 'popular' behavior is people work best under pressure and deadlines help achieve that and get things done. motivational factor and you don't seem to get it. But more than that, a fixed date will force a release, and without that, it's like a it will never happen kind of deal. Get it out, then concentrate on the next release, then iterate. i can lie and invent dates and then keep rescheduling like most projects. i really hate doing that. when those todo things are done i feel confident calling an alpha and then maybe 4 weeks to beta (fix bugs). but that's assuming that todo is done (as i said - with the items for alpha - the worst of efm issues fixed like dnd, copy paste, tasks (done now), keymap, xrandr). as of today we only have randr, keymap, efm - keymap has been promised by quaker66 now since march. randr i just patched into my e today for some testing and looking around. i have to move over to an intel laptop to do this as i need randr working. so we're -||- that close to doing exactly what people want - an alpha then release after bugs are fixed. lol, that's not the point, for sure, if people know that the deadline can be moved, the motivation is not the same as sorry, too late. Anyways, I think it's ok to stick to a TODO
Re: [E-devel] itask, taskbar and engage
On Tue, Nov 1, 2011 at 12:17 AM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 22:56:03 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: Because I bumped into the problem myself so of course I'll try to debug it, and I didn't do it because you told me to. As for the fix, did you have a i can't order you to do anything - but you need to read what i wrote. as a summary, i said - help out and do things, instead of telling others what to do. if this had been done since the last major review of the todo list in march we'd be there already. you can tell others what to do all you like. they don't have to listen to a single word, just the same as you don't have to do anything either when i say help out. for sure, I was referring to it wasn't part of the todo, it was part of something I needed for myself. i'm using the release as a stick or a carrot to beat or bait people into helping out. i can't fire you or offer you a bonus or money, so those normal sticks and carrots are not able to be used, so i use a different one. i'm trying to use your own motivation for release. i wish your motivation would make you rise to the challenge rather than just have a release or bust view. open source works at a nuts and bolts level because people do things. projects start and move forward because someone does the hard yards. almost every open source project started life as a one-man project and it was that one man that got it up and running and to the point others might pitch in and scratch their itches or help even do things that are needed. it then became a team effort with no hard way to control the people working on it. projects offer carrots in the following ways: 1. name attached to project for bragging rights, 2. the ability to influence, control etc. something. 3. the satisfaction of a job well done in the end (seeing what u slaved on going gold), 4. if u are lucky the project may create a way to generate income from it for yourself. the sticks available are: 1. shaming people into doing things (guilt trips etc.), 2. ejection from privileges (like commit access, banning from irc, removal from mailing lists etc.). that's about it. i'm trying to use both a stick and a carrot. i'm trying to get you to accept some of the blame for a bad e17 release if you are the one pushing for it, as well as then getting some credit if it's good. right now you are pushing for what i believe is a slightly premature action. Yes, most OSS projects start that way or end up with someone leading the project, making the big decisions, mostly because others respect his skills/decisions rather than because he was elected. The way I see it, people will only work on what they want, what motivates them, and it's usually what they personally need. They will sometimes help out, when asked, on something they don't use/care for, it depends on the motivation. The motivation can come from either I want the project to succeed or this looks like an interesting challenge. For example, I doubt people like doing tech support or triage in bugzilla, but they do it for the sake of the project, they feel it's their responsability. As for the sticks, I usually consider it to be svn blame :) look? I'm not sure it's done properly, the 'needed' var seems a bit overkill to do the check (didn't have time figure it out properly). Also, I was wondering if there wouldn't be a better solution to do if no gadget is resizable. yes i looked. that was the first thing i did. along with counting it as your first commit to e17according to logs. actually its right in that the logic is right - i was only testing when i had 1 gadget or more being autoscrollable - thus resizable. i didnt remember about zero gadgets resizable and thus maybe getting that loop. my bad there. i was making taskbar usable. i'm running it myself right now even though i really despise having it on my screen to make sure it at least works for me :) I switched to itask to test it, so I guess I'll go back to taskbar now since I belive it's the one that will get elected as being the stable one. Yes, the logic is right, but the code is not clean enough in my opinion, there must be a better way to handle that case. (also, other than that usecase, you forgot to initialize the variable :p) On Mon, Oct 31, 2011 at 10:05 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 23:59:57 -0200 Iván Briano (Sachiel) sachi...@gmail.com said: 2011/10/31 Carsten Haitzler ras...@rasterman.com: On Mon, 31 Oct 2011 19:27:25 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: is it just me... or are you actually helping out? :) Shhh. Less talking, more doing. hehehehe The fix should be in SVN now, r64588, try it now and see if that gets it fixed. On Mon, Oct 31, 2011 at 7:12 PM, Youness Alaoui kakar
Re: [E-devel] RFC: E17 Release
On Sat, Nov 5, 2011 at 1:21 PM, David Seikel onef...@gmail.com wrote: Lots of snippage, to avoid making it super long to wade through all the stuff that has been said before to get to the new bits. Hope I did not mess up the attributions. On Sat, 5 Nov 2011 12:10:24 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Tue, Nov 1, 2011 at 12:59 AM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 1 Nov 2011 00:17:01 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: we say we'll release next week, start building packages then 100 or 200 commits get sent in that single week (seriously). A deadline is a i've seen the reverse. deadlines come, deadlines go. no action. sure, but the most 'popular' behavior is people work best under pressure and deadlines help achieve that and get things done. Some people do, some don't. It's certainly a very short term management strategy though, that ignores that this sort of thing can and does stress people out. Stressed out people don't do their best. So such a management style might be popular for the managers, but the people being stressed tend to bitch about it. Stress is bad, doing a release shouldn't be about stress, but more about excitement. If you get stressed, then it's a different matter. i don't know - maybe you have spare time. i am in negative time land. i have zero left to spare. i barely get enough sleep - if it were not for weekends, i wouldn't. i am time poor. i dont have luxury like that. a half-done webiste thats then abandoned then causes me to use more time i didnt even have to begin with - so something else suffers (sleep, work, or other e development). i help out a bit where i can - but i wanted him to do his work in parallel without it affecting the main site until it's ready. nope, I'm in negative time land too, I think most of us are. I think your issue is that you should learn to delegate more, you can't do everything, and delegating is a big part of leading a project. The point raster is trying to make is that delegating, which raster does do, is useless if the delgatee does not do the work. I'm guilty of this myself. My life got in the way of E stuff, even though I was being paid for it, so I dropped my E responsibilities a while back. I had some large E things I was looking after. Now I'm doing a little bit here and there, again mostly to support stuff I'm being paid to do. I wont take on any big E responsibilities though. Well, unless someone pays me a fair fee for doing the virtual world project I'm currently dedicating my spare time to. Since I want to use EFL for that. Sure, you need a consistent team otherwise it won't work. And as I've been told numerous times a release is free.. what is it that you lose when you do a release, what's so important and critical about having a release ? API lock in. Configuration file compatibility lock in. These things are important if you actually like your users. Lock in is not free, it removes freedom. Euhh, no, for sure a major version bump is not free, but a cyclic release that doesn't break API/ABI or anything else, that's free, and that's what I was referring to. Yes, people have responsabilities, real life, lack of time, etc.. but everyone has a few free minutes in their lives, and if people know there's a hard deadline in a few weeks then today, even if tired, instead of watching some movie, they will rather spend some of that time fixing what they think is critical for the release. I have zero free time, but when there is something urgent, I can suddenly make time for it, and I think everyone is like that too. NEVER EVER assume that everyone else is just like you. No matter what. It's just a silly notion quite frankly. We are all different in so many ways. sure, not everyone is like that but I do believe that the majority are. i consider them a deal breaker :( a right now i want to not talk dates until AFTER efl 1.1. those dates will depend on if that gets a delay in it or what people do manage to do between now and then with e17. if that todo list still is no further along, then the timeframe has to be longer, if it is, then shorter. Alright, *that* in my opinion is an actual compromise of the subject discussed here (well, on the point I am making). No problems, we can talk dates after efl 1.1, I am fine with that :) It's what was being said all along, by a few of us. Not a compromise at all, just the plan. There was no need to make a big drama about stuff to get to this point. lol Well, if that was the plan, it was never said (to me anyways), this is the first time it was said in this whole thread. Since the start, it has always been the release will be whenever the todo list is done. Also, this wasn't a drama, it was a discussion, the 'drama' might be said about my
Re: [E-devel] EFL 1.1 freeze
I've just committed all the PS3 related changes so I have no more commits in my git that aren't in svn! On Thu, Nov 3, 2011 at 4:36 AM, David Seikel onef...@gmail.com wrote: On Thu, 3 Nov 2011 09:25:10 +0100 Cedric BAIL cedric.b...@free.fr wrote: On Thu, Nov 3, 2011 at 9:15 AM, David Seikel onef...@gmail.com wrote: On Thu, 03 Nov 2011 03:01:17 -0400 Christopher Michael cpmicha...@comcast.net wrote: On 11/02/11 22:42, David Seikel wrote: On Thu, 3 Nov 2011 08:49:46 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Wed, 2 Nov 2011 12:14:07 -0400 Mike Blumenkrantz m...@zentific.com said: Hi, It has been two weeks since the git 'er done mail from raster, so I am calling his bluff. Effective immediately, we are in a 2 week feature freeze for EFL 1.1. no - freeze starts monday :) from my original mail: merge window starts next monday (24th of october). that means from the 7th to the 20th no new features can be added to trunk, only bug fixes. so people have until sunday night... So I have until Sunday to badger raster into just letting me commit the new edje lua stuff? It would really help me a lot if what I have done so far is in the next release. That includes the basic text object support I did last night, approved.. Slip it in onefang ;) Hey wait, you are not listed as one of the edje authors. So that don't count. :-P Oh, that should be fixed, he has been working on edje ! Anyway, I agree with him. As the problem is that we need to review the internal change you do, but also how it should be used from the outside. If you have example that show how each lua API can be used that would help to take a decision. I'm updating the example lua script that was there already with the new stuff as part of my testing. That was in my last patch to. Also using it in my contracted project, but, um, no lookie. Might be time to send a new patch soon. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Sat, Nov 5, 2011 at 2:17 PM, David Seikel onef...@gmail.com wrote: On Sat, 5 Nov 2011 13:46:16 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sat, Nov 5, 2011 at 1:21 PM, David Seikel onef...@gmail.com wrote: And as I've been told numerous times a release is free.. what is it that you lose when you do a release, what's so important and critical about having a release ? API lock in. Configuration file compatibility lock in. These things are important if you actually like your users. Lock in is not free, it removes freedom. Euhh, no, for sure a major version bump is not free, but a cyclic release that doesn't break API/ABI or anything else, that's free, and that's what I was referring to. First release, and this is what we are talking about for E17, is the one where you get locked in. Cyclic releases are for after the first release of E17, so at that point, the API would have already been locked. i consider them a deal breaker :( a right now i want to not talk dates until AFTER efl 1.1. those dates will depend on if that gets a delay in it or what people do manage to do between now and then with e17. if that todo list still is no further along, then the timeframe has to be longer, if it is, then shorter. Alright, *that* in my opinion is an actual compromise of the subject discussed here (well, on the point I am making). No problems, we can talk dates after efl 1.1, I am fine with that :) It's what was being said all along, by a few of us. Not a compromise at all, just the plan. There was no need to make a big drama about stuff to get to this point. lol Well, if that was the plan, it was never said (to me anyways), this is the first time it was said in this whole thread. Umm.. On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: if people WANT A RELEASE, THEN STEPUP AND DO SOMETHING! with those done then we can absolutely do an alpha (though it must wait until after efl 1.1 which is now due in about 3 weeks). On Sun, Oct 30, 2011 at 4:42 AM, David Seikel onef...@gmail.com wrote: The consensus does seem to be that there wont be an e17 release until after the EFL 1.1 release anyway. The amount of passion and time we are spending arguing over the exact timing of that e17 release could be better spent actually working on that e17 TODO and the EFL release. How about we work on it, then see how much e17 TODO is left after the EFL 1.1 release. That will be a better time to argue you case, when it wont distract people from the work that needs to be done. Perhaps by then it will be moot, and the TODO is completed. On Sunday, October 30, 2011, Carsten Haitzler ras...@rasterman.com wrote: i'm working on the todo and efl 1.1 after efl 1.1 its e17 and elm 1.0. e17 involves working on the tasks assigned. It's a very long thread, there are probably other mentions. You even quoted some of these yourself. You must have read them. B-) Well, all those mentions are about e17 release after efl 1.1, yeah, that's fine, what I found interesting and considered a compromise in raster's mail was we can talk about dates after efl 1.1.. in other words, it's not just release after 1.1, or we stick to the todo and never set any dates but rather we can discuss it later. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Sun, Oct 30, 2011 at 9:58 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: i'm already working on taskbar. i've fixed horizontal sizing issues already. i need to fix theme up. t_unix has pending patches for xrandr multi-screen i have yet to look at - if someone wants a release them why not review those patches and try them out while i'm busy? otherwise this just takes longer. we can't set dates because so many people agree to do shit and then DONT DO IT.. in the end... i do most of it. look at: Ok that's cool, just let me know and I can stress test and report bugs on taskbar or any other module. I also need the multiscreen stuff, right now I have a script that uses xrandr, so I got the setup ready and I can test it for you. As for dates, yes, set a date, and if someone doesn't do shit, then too bad, the missing features will be missing features, it shouldn't mean a delay of another year. no - i'm not setting a date. i set a task list. Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to http://trac.enlightenment.org/e/wiki/Release of the list left the following could be dropped: * connman module ui improvement * config modules for missing e config vars the rest are not droppable. of the droppable ones the connman ui is more droppable. but thats MOOT right now as these are not the last 2 things left. We went through the list with Cedric and Gustavo, and this is the list with comments : - Fix EFM to be completely reliable/functional -- That's not a feature, those are bugs, and if they are not fixed by the time RC1 is fixed then it's not an issue to fix them between RC1 and final release. - Redo resolution settings module -- It is important, and I need it myself *but* people can live without it. Those who can't will just have to endure it or wait for the next release. Anyways, if this work has already been started (or not hard enough), then IF it can be done for RC1 then it can be included, otherwise too bad. - Randr config module/integration -- I don't really know what it means, so I can't comment both of the above are the same and i disagree. people can't live without. this decision was agreed on back in march.. actually before that we knew there was a real need. Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. - Keymap config -- Same as the resolution module, while it is necessary, people can live without it, otherwise, they'll endure it or wait. If it can be done by the time of RC1 release, then bugfixes can be added for the final release. disagree. alphas are meant to be feature complete. and so what? so what if we do an alpha now? what will that change? all it will do is encourage people to NOT finish things. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. - Get a default theme 100% ready to ship -- This is a no brainer, that extra polishing (what exactly is missing anyways?) can be done from RC1 to final. - Connman module ui needs to be improved -- I don't use it so not much to say about it, I use nm-applet with the systray module. But I guess it's the same as above, while it's needed, it's not something that will break the release. - Add config modules for all missing E config vars -- Same as above. if people WANT A RELEASE, THEN STEPUP AND DO SOMETHING! with those done then we can absolutely do an alpha (though it must wait until after efl 1.1 which is now due in about 3 weeks). Why not do the alpha (or RC1, it's the same thing, different naming) at the same time as efl 1.1 release? That's what we discussed and I think it's a good idea. This also sets a date for people to get their patches in before the alpha release. hell no - not at the same time. we have enough work to do on efl1.1 - why does it matter that they are at the same time? other than a sudden desire to release from a whole bunch of people not working on the release? It doesn't matter that they are at the same
Re: [E-devel] RFC: E17 Release
On Sun, Oct 30, 2011 at 10:50 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 15:35:01 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: On Sun, 30 Oct 2011, Carsten Haitzler (The Rasterman) wrote: we released efl 1.0 back at the start of the year... is there a massive rise in developers? :) the EFL without kick-ass apps, showing we can do more than the other similar libraries, are useless. So it's not really surprising. sure. Btw, there is not a massive amount of new devs / users, but some new ones appear. And there more people in IRC chans (#edevev and #e.fr) the last few months. Not sure if the 1.0 release (with the puplicity we tried to make) and this increase of devs/users are correlated, but my opinion is that it helped. you know what gets lots and lots of users and attention? going onto a major distribution as the primary desktop. a release wont make that happen. haha, sure it won't.. cause distros will take the svn snapshot... and sure, doing a release in itself will not bring any user or attention, it has to be part of a major distribution... what's your big plan on achieving that? Oh and btw, I heard that if you weren't so stubborn, redhat/fedora/gnome might still be using E as their primary WM. About the release, I see good points and bad points in everything that was said, so I can't make up my mind :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask, taskbar and engage
I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.fr wrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask, taskbar and engage
Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.fr wrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask, taskbar and engage
The fix should be in SVN now, r64588, try it now and see if that gets it fixed. On Mon, Oct 31, 2011 at 7:12 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.frwrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 6:29 PM, hannes.janet...@gmail.com hannes.janet...@googlemail.com wrote: On Mon, Oct 31, 2011 at 10:15 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sun, Oct 30, 2011 at 9:58 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: i'm already working on taskbar. i've fixed horizontal sizing issues already. i need to fix theme up. t_unix has pending patches for xrandr multi-screen i have yet to look at - if someone wants a release them why not review those patches and try them out while i'm busy? otherwise this just takes longer. we can't set dates because so many people agree to do shit and then DONT DO IT.. in the end... i do most of it. look at: Ok that's cool, just let me know and I can stress test and report bugs on taskbar or any other module. I also need the multiscreen stuff, right now I have a script that uses xrandr, so I got the setup ready and I can test it for you. As for dates, yes, set a date, and if someone doesn't do shit, then too bad, the missing features will be missing features, it shouldn't mean a delay of another year. no - i'm not setting a date. i set a task list. Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to http://trac.enlightenment.org/e/wiki/Release of the list left the following could be dropped: * connman module ui improvement * config modules for missing e config vars the rest are not droppable. of the droppable ones the connman ui is more droppable. but thats MOOT right now as these are not the last 2 things left. We went through the list with Cedric and Gustavo, and this is the list with comments : - Fix EFM to be completely reliable/functional -- That's not a feature, those are bugs, and if they are not fixed by the time RC1 is fixed then it's not an issue to fix them between RC1 and final release. - Redo resolution settings module -- It is important, and I need it myself *but* people can live without it. Those who can't will just have to endure it or wait for the next release. Anyways, if this work has already been started (or not hard enough), then IF it can be done for RC1 then it can be included, otherwise too bad. - Randr config module/integration -- I don't really know what it means, so I can't comment both of the above are the same and i disagree. people can't live without. this decision was agreed on back in march.. actually before that we knew there was a real need. Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. - Keymap config -- Same as the resolution module, while it is necessary, people can live without it, otherwise, they'll endure it or wait. If it can be done by the time of RC1 release, then bugfixes can be added for the final release. disagree. alphas are meant to be feature complete. and so what? so what if we do an alpha now? what will that change? all it will do is encourage people to NOT finish things. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. - Get a default theme 100% ready to ship -- This is a no brainer, that extra polishing (what exactly is missing anyways?) can be done from RC1 to final. - Connman module ui needs to be improved -- I don't use it so not much to say about it, I use nm-applet with the systray module. But I guess it's the same as above, while it's needed, it's not something that will break the release. - Add config modules for all missing E config vars -- Same as above. if people WANT A RELEASE, THEN STEPUP AND DO SOMETHING! with those done then we can absolutely do an alpha (though it must wait until after efl 1.1 which is now due in about 3 weeks). Why not do the alpha (or RC1, it's the same thing, different naming) at the same time as efl 1.1 release? That's what we discussed and I think it's
Re: [E-devel] itask, taskbar and engage
Because I bumped into the problem myself so of course I'll try to debug it, and I didn't do it because you told me to. As for the fix, did you have a look? I'm not sure it's done properly, the 'needed' var seems a bit overkill to do the check (didn't have time figure it out properly). Also, I was wondering if there wouldn't be a better solution to do if no gadget is resizable. On Mon, Oct 31, 2011 at 10:05 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 23:59:57 -0200 Iván Briano (Sachiel) sachi...@gmail.com said: 2011/10/31 Carsten Haitzler ras...@rasterman.com: On Mon, 31 Oct 2011 19:27:25 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: is it just me... or are you actually helping out? :) Shhh. Less talking, more doing. hehehehe The fix should be in SVN now, r64588, try it now and see if that gets it fixed. On Mon, Oct 31, 2011 at 7:12 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey, forget what I just said, I've just had the same bug as you described, I just updated and it seems to be a new bug in the latest SVN. I've figured out what causes it, I'll write a bugfix and commit it soon. On Mon, Oct 31, 2011 at 5:40 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: I don't have that issue, I noticed some slow E sometimes, maybe taking 10 or 20% of CPU (and I have 8 virtual desktops and about 5 to 10 windows in each)... cedric said the issue of E being slow for me was caused by my intel GPU.. I don't know about the CPU usage.. I was using taskbar module, now I switched to itask. On Mon, Oct 31, 2011 at 4:33 PM, Philippe Reynes trem...@yahoo.frwrote: Hi all, I've got a problem when I use itask or taskbar or engage and run severals task. After something like 6 or 8 tasks started the process enlightment use 100% of the cpu and the desktop is almost frozen. Task seems to continue, but it can't do anything (change windows, stop a task, ). I use mageia, and I've tried with revision 64519 and 64579. Someone else has got the same problem ? Regards, trem -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 8:46 PM, hannes.janet...@gmail.com hannes.janet...@googlemail.com wrote: On Tue, Nov 1, 2011 at 12:35 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Mon, Oct 31, 2011 at 6:29 PM, hannes.janet...@gmail.com hannes.janet...@googlemail.com wrote: On Mon, Oct 31, 2011 at 10:15 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sun, Oct 30, 2011 at 9:58 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: i'm already working on taskbar. i've fixed horizontal sizing issues already. i need to fix theme up. t_unix has pending patches for xrandr multi-screen i have yet to look at - if someone wants a release them why not review those patches and try them out while i'm busy? otherwise this just takes longer. we can't set dates because so many people agree to do shit and then DONT DO IT.. in the end... i do most of it. look at: Ok that's cool, just let me know and I can stress test and report bugs on taskbar or any other module. I also need the multiscreen stuff, right now I have a script that uses xrandr, so I got the setup ready and I can test it for you. As for dates, yes, set a date, and if someone doesn't do shit, then too bad, the missing features will be missing features, it shouldn't mean a delay of another year. no - i'm not setting a date. i set a task list. Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to http://trac.enlightenment.org/e/wiki/Release of the list left the following could be dropped: * connman module ui improvement * config modules for missing e config vars the rest are not droppable. of the droppable ones the connman ui is more droppable. but thats MOOT right now as these are not the last 2 things left. We went through the list with Cedric and Gustavo, and this is the list with comments : - Fix EFM to be completely reliable/functional -- That's not a feature, those are bugs, and if they are not fixed by the time RC1 is fixed then it's not an issue to fix them between RC1 and final release. - Redo resolution settings module -- It is important, and I need it myself *but* people can live without it. Those who can't will just have to endure it or wait for the next release. Anyways, if this work has already been started (or not hard enough), then IF it can be done for RC1 then it can be included, otherwise too bad. - Randr config module/integration -- I don't really know what it means, so I can't comment both of the above are the same and i disagree. people can't live without. this decision was agreed on back in march.. actually before that we knew there was a real need. Well I don't think so, but if you really think people can't live without it (and can't live without e17), then someone has to make it work by the time the deadline is reached. If not, then too bad, if you can't live without it, then go hang yourself. - Keymap config -- Same as the resolution module, while it is necessary, people can live without it, otherwise, they'll endure it or wait. If it can be done by the time of RC1 release, then bugfixes can be added for the final release. disagree. alphas are meant to be feature complete. and so what? so what if we do an alpha now? what will that change? all it will do is encourage people to NOT finish things. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. - Get a default theme 100% ready to ship -- This is a no brainer, that extra polishing (what exactly is missing anyways?) can be done from RC1 to final. - Connman module ui needs to be improved -- I don't use it so not much to say about it, I use nm-applet with the systray module. But I guess it's the same as above, while it's needed, it's not something that will break the release. - Add config modules for all missing E config vars -- Same as above
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 9:38 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 17:19:17 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: On Sun, Oct 30, 2011 at 10:50 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 15:35:01 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: On Sun, 30 Oct 2011, Carsten Haitzler (The Rasterman) wrote: we released efl 1.0 back at the start of the year... is there a massive rise in developers? :) the EFL without kick-ass apps, showing we can do more than the other similar libraries, are useless. So it's not really surprising. sure. Btw, there is not a massive amount of new devs / users, but some new ones appear. And there more people in IRC chans (#edevev and #e.fr) the last few months. Not sure if the 1.0 release (with the puplicity we tried to make) and this increase of devs/users are correlated, but my opinion is that it helped. you know what gets lots and lots of users and attention? going onto a major distribution as the primary desktop. a release wont make that happen. haha, sure it won't.. cause distros will take the svn snapshot... and sure, doing a release in itself will not bring any user or attention, it has to be part of a major distribution... what's your big plan on achieving that? it won't happen because we are not a sexy desktop environment. there is 1 big mistake i made back in 96/97 - it's that i wasn't all enthused by the desktop environment bandwagon - i thought that apps were apps and should work just fine under any wm. the desktop shell (which i didn't have a name for back then) was what i cared about and what i wanted e to become. e17 is very close to being that. but i made a fatal error. i didn't jump on the DE bandwagon and declare E's path to become a DE of its own to compete. that was a mistake. the big regret. as long as E isn't a DE it doesn't matter as it doesn't INTEGRATE to apps. Qt or GTK based apps just look odd under e. people don't want it. so unless E becomes a DE... this won't happen on any major distro. major meaning ubuntu/suse/fedora/debian levels - the DEFAULT DE they get without asking explicitly. Ok.. so I don't understand, you're saying you'll get devs when it shipped as the default WM for a major distro, but you say it won't happen (kind of expected), so you're basically saying that the project is already doomed? Oh and btw, I heard that if you weren't so stubborn, redhat/fedora/gnome might still be using E as their primary WM. that's a nice vicious rumour either you are making up now or that has been spread. e only was shipped because of accident and that i worked at redhat and that i did my job. i can tell you that when i left redhat there was bad blood between me and redhat. we were not getting along well at all. partly because i was hired away for a better salary to silicon valley and redhat officially fired me because i had accepted an offer and was waiting for visa approvals that at the time were problematic and took time in the USA? lucky for me my new visa came through a few days after that (which is when i was going to put in my 1 month notice anyway). it was not possible to change companies in the US without re-applying for a visa... maybe you didn't know that? and all visa applications were a matter of public record and redhat was watching that so that's how they found out. so sure - use the wm written by the guy you fired because you were pissed off at him moving to a better company in a better location for a better salary? m yeah. sure! Nope, not a rumor I'm making up, but a rumor that I heard. I don't know (never bothered to ask) about any details to be honest, but the rumor was basically that indeed there was bad blood, and that you got fired. Never heard of the job/visa thing though, the rumor states that your vision and the vision of gnome/redhat/whatever was diverging.. you wanted to customize everything and they wanted very little customization but for it to do the right thing by default. Can't remember though if the rumor ended with then you got fired or then you left because of this disagreement. i see you also need a little history lesson on gnome way back when. let's roll back to 1997. i was working on enlightenment. it was up to 0.13 - it worked and looked... different. i was hired by redhat. they had this new gnome thing that miguel started. they wanted me to work on that. ok. i gave imlib a gdk front end to gtk/ apps could sanely use it. i argued on the gnome devel list that they needed a wm as you couldn't do a desktop without integration to one. miguel kept arguing they could do it just fine with all wm's. this went on for about 10 months. i was ready to make e do whatever gnome needed, but they were not interested, so i went my own way with e as gnome was going to work
Re: [E-devel] RFC: E17 Release
On Mon, Oct 31, 2011 at 9:42 PM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 31 Oct 2011 17:15:56 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: Yeah yeah, you've made that pretty clear already, the thing is, we give reasons why this would be better, but your only argument is because I don't want to that list there on the release page was a result of a group of e devs getting together at cebit and refining the existing more vague list. it was not just me. i was there. Alright, if that TODO was a group effort, then my apologies on the specific parts where I stated your todo. I'd like to point out though that when I said that, I wasn't just referring to you wrote it, but rather on you decided what to put in it, those who disagreed got ignored. You always seem to have the final word, and that's why I consider it your todo. But yes, I was not there, so I cannot know, so againt, just a hypothesis. how will it encourage people to not finish things? and what it will achieve? well I thought it was pretty obvious, but since you need me to spell it out for you : - You need a feature freeze in svn before releasing - You need to fix bugs between feature freeze and release - You need an alpha release to get bugreports on what needs to be fixed before the release. and yes i need to Sorry, this seems unclear, yes I need to? what do you mean? yes you need me to spell it out? or yes, you need those 3 things I listed == an alpha is needed ? It doesn't matter that they are at the same time, what does matter is to have a fixed date for it. I said at the same time as efl 1.1 because cedric suggested that (at the conference). And this isn't a sudden desire, it's a desire that's been there for years, you just don't want to see it. You need time to rest post efl 1.1 release, fine, but set a reasonable date. why does it have to BE A FIXED DATE? why do i have to repeat this question - what is so MAGIC about that date. i s The date itself is not magic, we're not saying december 25th, or january 1st, or whatever other 'special dates'. But what will A DATE create is a deadline, and the deadline in itself will drive the development. Not everyone works like that, for sure, but I believe that most people will get more shit done if they have a deadline rather than whenever you can. And I've experienced this so many times.. no commits for 6 months on amsn, then we say we'll release next week, start building packages then 100 or 200 commits get sent in that single week (seriously). A deadline is a motivational factor and you don't seem to get it. But more than that, a fixed date will force a release, and without that, it's like a it will never happen kind of deal. Get it out, then concentrate on the next release, then iterate. you are tired of the rudeness? well sorry about that! And I'm also pretty fucking tired of your condescending arrogant bullshit! Yeah yeah, I'm the new guy, I'm just a user, I haven't contributed anything worthy, so I should shut up, but you know what, I still have a voice, and I've heard so many 'rumors' about you, but now I believe them after I've actually experienced the rasterman ever since I joined. You talk in a condescending manner, you are arrogant, and you piss pretty much everybody off, I don't know how e17 lasted this long with you driving away everyone.. oh wait, yeah, people did leave the team, and maybe if you weren't being the dictator that you're trying to be, the community would be much much much larger. I have a lot of respect for your work, you definitely have a lot of skills that very few people have, but this does not mean you can be a tyrant dictator and do whatever you want, ignoring everyone's opinions. I understand E is basically your baby, and for sure your word is important but you need to listen to what people tell you and stop being so fucking stubborn (and I'm not saying this just about this thread btw)! While I'm on the subject, like what Gustavo said, someone emails and says he wants to help with something and all you could answer him is that he'll fail, how stupid is that? is that how you build a community ? you are if it's the website? then yes - i said that, as i've seen it happen before - several times. from memory he wanted to tear down the current site and rebuild and i said don't do that - it will go like others - it'll end up half done and we have a half done site then others are left to pick up and fix again. do it in parallel and when it's ready, we can shift over. you are indeed new. you may think it's all roses. over the decade+ i have many times relied on people who said i will do X. be that the website, or a piece of code, and countless times they vanish, never do it, do a tiny bit and give up, and then i, or others, are left holding the bag going so.. where is it?. we were expecting it. it didn't happen. or the quality of what
[E-devel] Fwd: RFC: E17 Release
-- Forwarded message -- From: Youness Alaoui kakar...@kakaroto.homelinux.net Date: Sun, Oct 30, 2011 at 3:47 AM Subject: Re: [E-devel] RFC: E17 Release To: Carsten Haitzler ras...@rasterman.com The point is that without a release, you can't expect interest in 'vaporware'. After the release, there is a very good chance that you will see a lot more people interested in it and more contributors. On Sat, Oct 29, 2011 at 10:50 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:10:21 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: we won't catch up because no one works on e17. no one is interested in it anymore and a release won't change that/ 99% of the development effort is on EFL not e. Thanks Gustavo, you said many of the same things that I just said (email was written async) and you made me realize one point... the WM world is constantly changing, when we are ready for release, some new thing will come out and then we need to adapt again... E17 was the most beautiful WM out there, and then compiz was released and it added cool new effects, then gnome 3 was released, and with all that, E17 is starting to get outdated.. if you don't release, you'll never be able to catch up (they caught up to you, but they stole the users who wanted those features but couldn't see a release to get them from). I won't make this any longer :) On Sat, Oct 29, 2011 at 6:01 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sat, Oct 29, 2011 at 12:55 AM, Michael Jennings m...@kainx.org wrote: On Saturday, 29 October 2011, at 11:23:37 (+0900), Carsten Haitzler wrote: i'll post here as a summary. what k-s wants is to just release e17-as is after fixing some efm bugs. who agrees with that? everything stays as-is. the reason xrandr is on the todo is that there are many complaints and questions about how to get multi screen to work and we have no solution. the reason taskbar is there is because engage is compositing based realistically and we have to work without, and we again have had enough users complain and ask for a way to switch tasks. the reason efm is on the list is its mostly working and usable as a simple filemanager - that was its point. it needs some bugs fixed. the reason keymap config is there is for all those europeans (and a few others) with odd keymaps and people have no clue how to configure this on a command-line or in config files. the other todo items could get dropped, though theme does need to be polished. this wasnt unilaterally decided by me. i believe in making a good attempt at a quality release. gustavo just believes in dumping out whatever we have. all the bitching about gnome and others will happen to us if we don't provide these basics that gnome etc. already DO. to many people we are useless. these are not new fangled ideas or standards - this is old hat that we haven't covered. so how do u expect to make those people happy and try or stay with e when we are not functional in some key aspects? Absolutely correct. The way you guys put thing looks like revolutionary stuff is coming before the release. The missing features won't hurt as much others you guys never cited. If the person is willing to use E17 you can be sure that features (even basic) doesn't play a role in his life as he can work out his stuff. If person wants features, they will very likely move between the 3 big ones (GNOME, KDE or Unity). There are tons of other features these people will miss, from indexing files to broader connection management (connman is not as used as networkmanager) to integration with web2.0 services such as sending pictures to picasa or flickr. IMO we're getting people that would be willing to move to awesome or fluxbox. That is, zero features, just speed and control. Like a sportive car. We can compete there. After 10 years of development, releasing nothing is far, far preferable to releasing something half-assed. I can hear the comments now. I've waited this long for crap? 10 years, and this is the best they can do? Never again! This WILL happen. Because of exactly this argument. We don't release, developers go away and we have less man power. Other desktops don't stop, they release and get more developers, they can implement more. Features won't stop showing. In 2007 when I joined to project I was wondering why it was not released. By the time we still had basics like language and efm to do. We did not release and since then we also started to miss Composite Manager (done, while lang was not), Indexer Integration (partially done with Tracker in Everything)... very soon we'll have to implement the new FDO standards for applications
Re: [E-devel] RFC: E17 Release
On Sat, Oct 29, 2011 at 11:22 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:05:20 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: i'm already working on taskbar. i've fixed horizontal sizing issues already. i need to fix theme up. t_unix has pending patches for xrandr multi-screen i have yet to look at - if someone wants a release them why not review those patches and try them out while i'm busy? otherwise this just takes longer. we can't set dates because so many people agree to do shit and then DONT DO IT.. in the end... i do most of it. look at: Ok that's cool, just let me know and I can stress test and report bugs on taskbar or any other module. I also need the multiscreen stuff, right now I have a script that uses xrandr, so I got the setup ready and I can test it for you. As for dates, yes, set a date, and if someone doesn't do shit, then too bad, the missing features will be missing features, it shouldn't mean a delay of another year. http://trac.enlightenment.org/e/wiki/Release of the list left the following could be dropped: * connman module ui improvement * config modules for missing e config vars the rest are not droppable. of the droppable ones the connman ui is more droppable. but thats MOOT right now as these are not the last 2 things left. We went through the list with Cedric and Gustavo, and this is the list with comments : - Fix EFM to be completely reliable/functional -- That's not a feature, those are bugs, and if they are not fixed by the time RC1 is fixed then it's not an issue to fix them between RC1 and final release. - Redo resolution settings module -- It is important, and I need it myself *but* people can live without it. Those who can't will just have to endure it or wait for the next release. Anyways, if this work has already been started (or not hard enough), then IF it can be done for RC1 then it can be included, otherwise too bad. - Randr config module/integration -- I don't really know what it means, so I can't comment - Keymap config -- Same as the resolution module, while it is necessary, people can live without it, otherwise, they'll endure it or wait. If it can be done by the time of RC1 release, then bugfixes can be added for the final release. - Get a default theme 100% ready to ship -- This is a no brainer, that extra polishing (what exactly is missing anyways?) can be done from RC1 to final. - Connman module ui needs to be improved -- I don't use it so not much to say about it, I use nm-applet with the systray module. But I guess it's the same as above, while it's needed, it's not something that will break the release. - Add config modules for all missing E config vars -- Same as above. if people WANT A RELEASE, THEN STEPUP AND DO SOMETHING! with those done then we can absolutely do an alpha (though it must wait until after efl 1.1 which is now due in about 3 weeks). Why not do the alpha (or RC1, it's the same thing, different naming) at the same time as efl 1.1 release? That's what we discussed and I think it's a good idea. This also sets a date for people to get their patches in before the alpha release. mind u - this debate has come up several times in the past, every 6-12 mo or so. and u know what happens? NOTHING. the people who all want it don't DO anything. i give a list of things to do (a rough hand-wavy one) and then they proceed to do nothing. i have learned lessons over the 16 years of doing things. 99% of people like to spout opinions and tell you what you should do. 1% actually get off their butts and make things happen at all. 0.01% of them ACTUALLY have the fortitude to stick it out long enough to get things DONE. Yes, I'm pretty sure it's an old debate.. now I wonder why there still was no release.. maybe it's because it wasn't stable and noone did anything or maybe it's because rasterman vetoed everything, decided to get pissed and scare off everyone. The purpose of this thread (and probably all the previous discussions) is to get a point across, the release is needed, and most people think that there is no point in delaying it, but if you're too stubborn on that, maybe that's the reason no release was ever made, not about people not contributing (which btw, seeing how you sometimes answer aggressively, it might actually have scared away contributors). to everyone debating e17 release - get off your butts and do the todo list. if you actually DID this... it'd have been done long ago. Still missing the point, the TODO list is not the blocker, it seems to be you and your decision. The release can be made now, the TODO list is irrelevant. I tried to compromise, I tried to come up with a solution that would make everyone happy but you simply ignored it. I didn't write a long email to explain things just to have 99% of it ignored. Assign a release manager, set specific dates for feature freezes (which would come with a release
Re: [E-devel] RFC: E17 Release
More users means more exposure means more contributions and how can you be so arrogant as to judge these would-be developers as being not worth talking about before you've actually seen their work, you might be surprised. This attitude is maybe the real reason as to why the dev community is so small, the remaining devs are maybe the few ones who are actually able to keep up with your insane judgmental crap. been there, done that, really ? I guess I missed the e17 release that you've done already.. in that case, forget everything I said! oh and what makes me think we might get a deluge, it's simply because people won't invest their time in something that technically doesn't exist and doesn't have any users. Maybe I'm wrong, maybe you'll only get one more developer, or maybe even zero, it doesn't matter, don't judge too soon and see what happens instead of assuming you can predict the future. On Sun, Oct 30, 2011 at 3:49 AM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Oct 2011 03:47:05 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: we'll get 50x the users complaining and asking for help. we don't get any developers worth talking about to make up for it. been there. done that. if the current developer base is so disinterested in e17 then what makes u think u'll suddenly get a deluge of them? The point is that without a release, you can't expect interest in 'vaporware'. After the release, there is a very good chance that you will see a lot more people interested in it and more contributors. On Sat, Oct 29, 2011 at 10:50 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sat, 29 Oct 2011 11:10:21 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net said: we won't catch up because no one works on e17. no one is interested in it anymore and a release won't change that/ 99% of the development effort is on EFL not e. Thanks Gustavo, you said many of the same things that I just said (email was written async) and you made me realize one point... the WM world is constantly changing, when we are ready for release, some new thing will come out and then we need to adapt again... E17 was the most beautiful WM out there, and then compiz was released and it added cool new effects, then gnome 3 was released, and with all that, E17 is starting to get outdated.. if you don't release, you'll never be able to catch up (they caught up to you, but they stole the users who wanted those features but couldn't see a release to get them from). I won't make this any longer :) On Sat, Oct 29, 2011 at 6:01 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sat, Oct 29, 2011 at 12:55 AM, Michael Jennings m...@kainx.org wrote: On Saturday, 29 October 2011, at 11:23:37 (+0900), Carsten Haitzler wrote: i'll post here as a summary. what k-s wants is to just release e17-as is after fixing some efm bugs. who agrees with that? everything stays as-is. the reason xrandr is on the todo is that there are many complaints and questions about how to get multi screen to work and we have no solution. the reason taskbar is there is because engage is compositing based realistically and we have to work without, and we again have had enough users complain and ask for a way to switch tasks. the reason efm is on the list is its mostly working and usable as a simple filemanager - that was its point. it needs some bugs fixed. the reason keymap config is there is for all those europeans (and a few others) with odd keymaps and people have no clue how to configure this on a command-line or in config files. the other todo items could get dropped, though theme does need to be polished. this wasnt unilaterally decided by me. i believe in making a good attempt at a quality release. gustavo just believes in dumping out whatever we have. all the bitching about gnome and others will happen to us if we don't provide these basics that gnome etc. already DO. to many people we are useless. these are not new fangled ideas or standards - this is old hat that we haven't covered. so how do u expect to make those people happy and try or stay with e when we are not functional in some key aspects? Absolutely correct. The way you guys put thing looks like revolutionary stuff is coming before the release. The missing features won't hurt as much others you guys never cited. If the person is willing to use E17 you can be sure that features (even basic) doesn't play a role in his life as he can work out his stuff. If person wants features, they will very likely move between the 3 big ones (GNOME
Re: [E-devel] RFC: E17 Release
On Sun, Oct 30, 2011 at 4:42 AM, David Seikel onef...@gmail.com wrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: The purpose of this thread (and probably all the previous discussions) is to get a point across, the release is needed, and most people think that there is no point in delaying it, but if you're too stubborn on that, maybe that's the reason no release was ever made, not about people not contributing (which btw, seeing how you sometimes answer aggressively, it might actually have scared away contributors). Most people? You have numbers to back that up? I'm not even seeing that on this thread, just the people that want the quick release making the most noise. No, I don't have any hard numbers for you, but this is the impression I got from this thread as well as from users I've talked to. I didn't say everyone, I did say most people and yes, I do believe that to be true. Since I can't prove it with any scientific number, let's just rephrase as some people, I don't see how that invalidates any of the other stuff I said, unless you want to look for the little misplaced word in every sentence I wrote. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
On Sun, Oct 30, 2011 at 7:57 AM, David Seikel onef...@gmail.com wrote: On Sun, 30 Oct 2011 07:34:57 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Sun, Oct 30, 2011 at 4:42 AM, David Seikel onef...@gmail.com wrote: On Sun, 30 Oct 2011 04:07:30 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: The purpose of this thread (and probably all the previous discussions) is to get a point across, the release is needed, and most people think that there is no point in delaying it, but if you're too stubborn on that, maybe that's the reason no release was ever made, not about people not contributing (which btw, seeing how you sometimes answer aggressively, it might actually have scared away contributors). Most people? You have numbers to back that up? I'm not even seeing that on this thread, just the people that want the quick release making the most noise. No, I don't have any hard numbers for you, but this is the impression I got from this thread as well as from users I've talked to. I didn't say everyone, I did say most people and yes, I do believe that to be true. Since I can't prove it with any scientific number, let's just rephrase as some people, I don't see how that invalidates any of the other stuff I said, unless you want to look for the little misplaced word in every sentence I wrote. You said that it's the point of the thread. That's not every little misplaced word in every sentence, that's your executive summary of your main point. Your point being most people think is a whole other kettle of fish from your point being some people think. No the point was we need a release, and not the some people think, that's just a secondary observation. The consensus does seem to be that there wont be an e17 release until after the EFL 1.1 release anyway. The amount of passion and time we are spending arguing over the exact timing of that e17 release could be better spent actually working on that e17 TODO and the EFL release. How about we work on it, then see how much e17 TODO is left after the EFL 1.1 release. That will be a better time to argue you case, when it wont distract people from the work that needs to be done. Perhaps by then it will be moot, and the TODO is completed. No, you're ignoring all my arguments. I am saying that the release schedule should be based on deadlines and not on the TODO. Try to squeeze the TODO inside the deadline, sure, but the deadline still needs to be respected. Also, from experience, people contribute and work harder if they have a set amount of time to fix something rather than whenever it's done. Set the deadline, and I'm pretty sure the TODO will be finished by then, magically, all by itself. Don't set a deadline, then next year, items from that TODO will still not be completed and the list would have grown and this same discussion would be happening all over again... -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: E17 Release
Hi guys, I've started this discussion with Gustavo and Cedric back in Prague, and haven't had time to check my mails until now (doing it from the airport). I will summarize the stuff I've told them and i'm sorry if I'm repeating some of the things that were already said in this thread. I will then answer specific stuff I've read. E17 *needs* a release, there is no doubt about it, and it needs to happen sooner rather than later. I believe the only reason it was never released is because there is no such thing as a complete/perfect software, The way E17 is right now is not much better than 4 years ago. You think people will complain I waited years for this???, no, I think they will complain they could have released this 4 years ago!. As such, since no software is ever complete, it means that a release will never happen if you have to follow the whole idea of feature-complete (or even 'after this TODO list is done). You actually need to set dates, and then *make your features fit in your timeline*. As for it's not ready, no, it IS ready, it's been ready for the past 4 years (although a bit more buggy back then, but it still kind of is), and if you look at the 'disaster' of gnome 3 and kde 4, you'll know that they can completely fuck it up, but it won't matter because 3 months later, they'll have a new release that fixes all the important things (the actually important ones, not the ones that the devs think might be important) and they doubled their user base and everybody forgot about the annoyances they originally had! You release now, in the release notes, you make it clear what exactly is missing and promise to get it fixed by next release (with a hardcoded deadline for that release) and people will not complain.. at least, most of them won't, for those who will, ignore them, because no matter what, people will complain, God created the earth and life in all things, and yet people complain that He doesn't exist... see my point ? You need to stop being scared of offending the very few ingrates out there, and actually do the right thing for the majority of grateful users who are depending on you. As for the release cycle, I suggested someone gets assigned the specific role of release manager, his task would be to take care of doing releases (and code in between of course), and if a release is not done on time, it is his responsability/fault/whatever. The task of the release manager is to make sure that the goals for the next release are reached on time (means yelling at others if necessary) or to drop features for the next release. He will take care of maintaining the release schedule wiki page too. The release schedule will need to have set goals and dates. Look at the gstreamer release schedule wiki page for example, they give you the exact dates for the feature freeze and for the release of the next 3 versions. This is what is needed here, people must know that they can expect a fix soon, and not in another 10 years. And frequent releases definitely gives a lot of exposure to the project, which is needed. Now about the TODO and release as-in (Gustavo) versus finish these features first (Carsten) philosophies. I looked at the TODO with cedric a couple of days ago, and quite honestly, it was ALL low priority. There is nothing in there that absolutely has to be done before any kind of release so they can all be dropped! But I don't necessarily agree with a release it now as-is either.. I agree with cedric's view of releasing an alpha (what I call a release-candidate) in a couple of weeks when efl 1.1 get released. Get your features in the core from now until then (in 2 weeks, right?) and then the release candidate can be released, at which point a feature freeze of 4 weeks must be set, no more. 4 weeks later, the actual release HAS to happen. Between the RC1 and the final, no new features are to be added, but bugfixes can (and should!) get committed. So what I'm saying is, you want dual screen support (oh God, please, I need it!!! :D) then do it from now until the 15th of December (does that date sound nice?) you want a better taskbar? then get it in right now. You need the keyboard layout thingy, then get started! Then when the RC1 gets tagged, that's it, no more features, and start bugfixing whatever you can find. I think this should please both parties, since Carsten himself said that these missing features should only take weeks to implement, right ? So now's your chance to prove it and get it done in the next 2 weeks, because if you can't, then trust me, 2 years from now, we'll be having this same discussion in which you'll say it will only take a few more weeks to implement these other features that are absolutely necessary for the release. Do a break; or continue; or even a goto; or whatever you need to do, but you need to stop this infinite loop you've been in for the past 10 years (and yes, I know that what was written in the past 10 years is huge, but no releases kind of means it was for
Re: [E-devel] RFC: E17 Release
Thanks Gustavo, you said many of the same things that I just said (email was written async) and you made me realize one point... the WM world is constantly changing, when we are ready for release, some new thing will come out and then we need to adapt again... E17 was the most beautiful WM out there, and then compiz was released and it added cool new effects, then gnome 3 was released, and with all that, E17 is starting to get outdated.. if you don't release, you'll never be able to catch up (they caught up to you, but they stole the users who wanted those features but couldn't see a release to get them from). I won't make this any longer :) On Sat, Oct 29, 2011 at 6:01 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sat, Oct 29, 2011 at 12:55 AM, Michael Jennings m...@kainx.org wrote: On Saturday, 29 October 2011, at 11:23:37 (+0900), Carsten Haitzler wrote: i'll post here as a summary. what k-s wants is to just release e17-as is after fixing some efm bugs. who agrees with that? everything stays as-is. the reason xrandr is on the todo is that there are many complaints and questions about how to get multi screen to work and we have no solution. the reason taskbar is there is because engage is compositing based realistically and we have to work without, and we again have had enough users complain and ask for a way to switch tasks. the reason efm is on the list is its mostly working and usable as a simple filemanager - that was its point. it needs some bugs fixed. the reason keymap config is there is for all those europeans (and a few others) with odd keymaps and people have no clue how to configure this on a command-line or in config files. the other todo items could get dropped, though theme does need to be polished. this wasnt unilaterally decided by me. i believe in making a good attempt at a quality release. gustavo just believes in dumping out whatever we have. all the bitching about gnome and others will happen to us if we don't provide these basics that gnome etc. already DO. to many people we are useless. these are not new fangled ideas or standards - this is old hat that we haven't covered. so how do u expect to make those people happy and try or stay with e when we are not functional in some key aspects? Absolutely correct. The way you guys put thing looks like revolutionary stuff is coming before the release. The missing features won't hurt as much others you guys never cited. If the person is willing to use E17 you can be sure that features (even basic) doesn't play a role in his life as he can work out his stuff. If person wants features, they will very likely move between the 3 big ones (GNOME, KDE or Unity). There are tons of other features these people will miss, from indexing files to broader connection management (connman is not as used as networkmanager) to integration with web2.0 services such as sending pictures to picasa or flickr. IMO we're getting people that would be willing to move to awesome or fluxbox. That is, zero features, just speed and control. Like a sportive car. We can compete there. After 10 years of development, releasing nothing is far, far preferable to releasing something half-assed. I can hear the comments now. I've waited this long for crap? 10 years, and this is the best they can do? Never again! This WILL happen. Because of exactly this argument. We don't release, developers go away and we have less man power. Other desktops don't stop, they release and get more developers, they can implement more. Features won't stop showing. In 2007 when I joined to project I was wondering why it was not released. By the time we still had basics like language and efm to do. We did not release and since then we also started to miss Composite Manager (done, while lang was not), Indexer Integration (partially done with Tracker in Everything)... very soon we'll have to implement the new FDO standards for applications menu and systray. Even the canonical arguments fancy and light are not applying these days. We're boring compared to competition. There are really light WM out there. That said, the more we wait, the worse it gets. We'll have to suffer, let's do it for once and for all. If people are honestly that bent out of shape wanting a release, they should be hammering away on the TODO list. Getting shit done is how a release will happen, not rehashing the same tired old argument every few months diverting time from more productive pursuits. I did try this approach earlier. It did not work. I've worked for years in the TODO list, yet the list is never enough for people blocking the release. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202
Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)
I agree with vincent, and I think that there shouldn't be a define it before including eina.h implicit rule.. while it's not so bad, and it would work, it's not the right way to do it. these functions shouldn't be inlined I think, they should be a define, and for the posix functions, they are way too big to be inline, they would dramatically increase the generated code, especially if you lock/unlock everywhere. As for performance, give us hard numbers! I don't think it would affect performance for such function calls. So in my opinion, make them defines, and have the posix versions as actual functions that the defines call (so for non posix with smaller functions, you don't need an actual call). On Wed, Oct 26, 2011 at 8:29 AM, Cedric BAIL cedric.b...@free.fr wrote: On Wed, Oct 26, 2011 at 1:48 PM, Vincent Torri vto...@univ-evry.fr wrote: On Wed, 26 Oct 2011, Cedric BAIL wrote: On Wed, Oct 26, 2011 at 11:13 AM, Vincent Torri vto...@univ-evry.fr wrote: On Wed, 26 Oct 2011, Cedric BAIL wrote: On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri vto...@univ-evry.fr wrote: Eina includes eina_inline_lock_posix.h on something else than Windows, hence pthread.h. _GNU_SOURCE is not defined. Suppose now that a user of Eina does this: #include Eina.h #include pthread.h The user will not have the possibility to features available with _GNU_SOURCE (like CPU_SET for example. I have that problem with Enesim), except by defining it just before including Eina.h. Which is not the best solution, I think. The problem, here, is that lock stuff is only inlined functions. The problem will be solved if they are in a source file. Maybe at the beginning, having these functions inlined was interesting because they were short. I'm not sure that keeping them inlined is really useful, now. As from a performance point of view, it really matter to have them inlined or not. Function call does cost. I know that, but i would like to have numbers, here, to verify it's worth having them inlined. Note that I'm talking about the posix part, not the 'void' or windows part. If your argument is : no numbers are needed, it's faster, then why not defining all the functions inlined ? I don't have access at the moment on machine where that does matter. But to put stuff into perspective, Eina_Magic check could cost around 10% of your time and it's just a function call with an if inside, much simpler that taking a lock. So I don't have number, but it's just way better to avoid the 10s instructions that are needed to do a function call. And why not inlining everything, that was a sarcasm... that why we use static inline instead of a macro, gcc can choose to inline the function or not depending on all the cost implied by the function call. And we don't put all function inlined, because that would just increase the binary size and invalidate cache to much. So it is only a solution for very small function called very often. Look at the function eina_lock_take() in the posix file : 67 lines (with the defines). Do you call that a small function ? And I perfectly remember you telling to use **static** inline to force gcc to inline the function. Now you're saying that gcc will sometimes inline it, sometimes not ? You're contradicting yourself. No I am not, the static is here to prevent a clash between symbol. That's all it is saying and it will never force a function to be inlined. It just make it possible to the compiler to do so if it makes sense. I told to put static, because inline doesn't tell anything about the symbol visibility and that would be an issue. -- Cedric BAIL -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] about removing trailing whitespaces
@Mike: I ran indent and it didn't seem to screw up things, I told it I want
3 spaces indent and 2 spaces inside { } or something, I tried it on a few
elm_*.c files and it changed some stuff but not the indentation spacing as
far as I remember.
@Carsten: spaces in blank lines are the same as spaces at the end of a line,
it's just that the line ends at position 0. I see absolutely no difference
in that and emacs doesn't either. And I don't see your point about it being
'childish'.
p.s: seems Carsten replied off-list, so I'm resending this to the list.
On Sat, Oct 22, 2011 at 3:33 PM, Mike Blumenkrantz m...@zentific.comwrote:
On Sat, 22 Oct 2011 11:57:15 -0400
Youness Alaoui kakar...@kakaroto.homelinux.net wrote:
I never said GNU is the reference for high quality, and we're not here to
talk about whether or not we like GNU, the FSF or Stallman.
Your point is that it would be easier to debug of your own app, my point
is
that why do hell would you need to debug that? Set your arguments to what
style you prefer and move on, no debugging necessary.
On Sat, Oct 22, 2011 at 5:48 AM, David Seikel onef...@gmail.com wrote:
On Sat, 22 Oct 2011 01:38:35 -0400 Youness Alaoui
kakar...@kakaroto.homelinux.net wrote:
Also I believe using a tested and used GNU app is better than using a
custom made one that might have bugs,
Since when is GNU the be all and end all of high quality coding? I'd
trust something written by an EFL coder over something out of GNU or
FSF any day. It would certainly be a lot easier to debug one of our
own apps.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
I don't think anyone has a problem using indent if it works. The problem
is,
IIRC, that it doesn't support EFL's indenting style. We indent an extra
space
for the width of a brace, and no indenter that I've come across can do that
natively. This is why I hacked up ecrustify.
--
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] about removing trailing whitespaces
I never said GNU is the reference for high quality, and we're not here to talk about whether or not we like GNU, the FSF or Stallman. Your point is that it would be easier to debug of your own app, my point is that why do hell would you need to debug that? Set your arguments to what style you prefer and move on, no debugging necessary. On Sat, Oct 22, 2011 at 5:48 AM, David Seikel onef...@gmail.com wrote: On Sat, 22 Oct 2011 01:38:35 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Also I believe using a tested and used GNU app is better than using a custom made one that might have bugs, Since when is GNU the be all and end all of high quality coding? I'd trust something written by an EFL coder over something out of GNU or FSF any day. It would certainly be a lot easier to debug one of our own apps. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] about removing trailing whitespaces
Ha! I was about to start a thread about this specific issue!
I don't know if you noticed but I added a 'efl-indent' script in FORMATTING
which uses GNU's indent. That works very good, and is used by GStreamer to
do their code formatting.
GStreamer uses git and when you try to commit something that doesn't match
the formatting code, it will not let you commit, and will show you how it
should have been.
Here is an example : http://pastie.org/2686190
I discussed this with SeoZ on #edevelop a couple of weeks ago. The script
might need some tweaking (the man page of indent is quite extensive) to fit
the exact coding style of the efl (I think it's close now) but I noticed a
lot of things aren't standardized, like struct { with the accolades on
the same line in some files and with it on separate lines in other files, or
the number of spaces between a variable type and its name in a declaration
(some align it, some don't), etc... all that stuff has to be defined and
respected across the board.
We can do a pre-commit hook in svn that would work just like its git
counterpart in GStreamer. But we'd need to reindent all the files for it to
work, it could be done in a single commit but might cause conflicts to devs,
or do it one file at a time, whenever it gets modified by someone, he'd
format it at the same time.
What do you think ?
KaKaRoTo
On Fri, Oct 21, 2011 at 12:29 AM, Vincent Torri vto...@univ-evry.fr wrote:
On Fri, 21 Oct 2011, Daniel Juyung Seo wrote:
I raise this issue again.
We need pre/post-commit hook for formatting, whitespaces, and whatever.
unfortunately, these hook will imply a lot of conflicts
Vincent
webkit already does this job.
Daniel Juyung Seo (SeoZ)
On Tue, Jun 21, 2011 at 10:00 PM, David Seikel onef...@gmail.com wrote:
On Tue, 21 Jun 2011 13:43:13 +0200 Thomas Gstädtner
tho...@gstaedtner.net wrote:
That is true, but the Don't do that, nasty programmer. SPANK SPANK
SPANK mail tells you that the hook triggered and also it hurts the
programmer who did produce the trailing whitespaces. People learn best
when it hurts :P
Automated emails might just go to spam, don't hurt that much. Unless
you intend to not accept the commit and make them do it over. That
will hurt enough.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] about removing trailing whitespaces
Yeah, I've seen ecrustify but I think when testing it, it didn't give good
results and from what I could perceive, other devs don't seem to trust it to
work reliably which is why I put efl-indent in there.
Also I believe using a tested and used GNU app is better than using a custom
made one that might have bugs, and being able to easily configure the output
using arguments to indent makes it better than looking through ecrustify to
figure out what causes it to format a line the wrong way.
As for the format, I configured efl-indent to match what the wiki says
(other than one bug I'm not sure how to change, need to read the man page),
but the current issues is with the fact that each file seem to use a
different coding style (or different styles within the same file) and I'm
not sure what to do with these as they are undocumented in the wiki.
p.s: for trailing spaces (which is this mail's original subject), I use a
sed line in efl-indent to take care of that, at least that could safely be
put into a svn hook while we figure out the coding style issue.
On Fri, Oct 21, 2011 at 10:14 PM, Carsten Haitzler ras...@rasterman.comwrote:
On Fri, 21 Oct 2011 14:44:31 -0400 Youness Alaoui
kakar...@kakaroto.homelinux.net said:
Ha! I was about to start a thread about this specific issue!
I don't know if you noticed but I added a 'efl-indent' script in
FORMATTING
which uses GNU's indent. That works very good, and is used by GStreamer
to
do their code formatting.
GStreamer uses git and when you try to commit something that doesn't
match
the formatting code, it will not let you commit, and will show you how it
should have been.
Here is an example : http://pastie.org/2686190
I discussed this with SeoZ on #edevelop a couple of weeks ago. The script
might need some tweaking (the man page of indent is quite extensive) to
fit
the exact coding style of the efl (I think it's close now) but I noticed
a
lot of things aren't standardized, like struct { with the accolades on
the same line in some files and with it on separate lines in other files,
or
the number of spaces between a variable type and its name in a
declaration
(some align it, some don't), etc... all that stuff has to be defined and
respected across the board.
We can do a pre-commit hook in svn that would work just like its git
counterpart in GStreamer. But we'd need to reindent all the files for it
to
work, it could be done in a single commit but might cause conflicts to
devs,
or do it one file at a time, whenever it gets modified by someone, he'd
format it at the same time.
What do you think ?
umm that's why formatefl.sh is there. it actually gets very close to our
current
style. it has 1 annoying bug at the moment though. it actually compiles and
installs a custom re-formatter that's a fork of uncrustify that does a lot
more
than gnu indent does. the problem right now is in getting it to
consistently
100% of the time format the right way. right now the bug it has in sticking
spaces before prototype functionames is annoying and going to lead to
commit
hooks probably locking out commits permanently.
KaKaRoTo
On Fri, Oct 21, 2011 at 12:29 AM, Vincent Torri vto...@univ-evry.fr
wrote:
On Fri, 21 Oct 2011, Daniel Juyung Seo wrote:
I raise this issue again.
We need pre/post-commit hook for formatting, whitespaces, and
whatever.
unfortunately, these hook will imply a lot of conflicts
Vincent
webkit already does this job.
Daniel Juyung Seo (SeoZ)
On Tue, Jun 21, 2011 at 10:00 PM, David Seikel onef...@gmail.com
wrote:
On Tue, 21 Jun 2011 13:43:13 +0200 Thomas Gstädtner
tho...@gstaedtner.net wrote:
That is true, but the Don't do that, nasty programmer. SPANK SPANK
SPANK mail tells you that the hook triggered and also it hurts the
programmer who did produce the trailing whitespaces. People learn
best
when it hurts :P
Automated emails might just go to spam, don't hurt that much. Unless
you intend to not accept the commit and make them do it over. That
will hurt enough.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
The demand for IT networking professionals continues to grow, and the
demand
Re: [E-devel] Evas/Elm resolution management
On Wed, Oct 5, 2011 at 7:59 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Oct 5, 2011 at 6:41 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: On Tue, Oct 4, 2011 at 9:52 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Mon, Oct 3, 2011 at 11:06 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Hey Gustavo! Thanks for answering my email! It's appreciated. However it didn't answer my questions, because basically, no, I'm not going to implement a window manager for the PS3 :) Don't forget that all applications/games will be full screen windows, and that 0.1% of people (a lot less I'm sure) actually have a mouse/keyboard hooked to their ps3, so having multiple windows is not a solution. I'm ok with single window apps, and while I do want to have interoperability with existing EFL apps without (or few) modifications, I mostly want something for new app development and a clear API on how to change resolution and how to handle the situation I explained.. most importantly, I'm not going to implement a WM, compositor, wayland or anything fancy like that :) I am not focusing on multi window apps, in my previous email, when I said I used elementary_test, I failed to mention I only ran it with --test-win-only to make sure only one window is created, so this is not the issue here. You're overlooking the problem. :-) 1 - The game content itself will run on the main Ecore_Evas that uses PS3 directly, not the inner windows. Less overhead... And likely it will use the GL bindings, as most games will use GL directly and not Evas. Then, to configure the screen they would use this API to set their best resolution. Well, for new apps written for the ps3, I don't see a problem, you'd make sure you do everything right, use a single window, set the fullscreen flag, etc.. note, there is a check in elm_win.c that forces all FB windows in fullscreen, maybe you can add that to your as well. Yes, that's what i did originally, but this caused the elm_win_resize to not be called (see first email about that issue), that's why I was forced to remove that fullscreen flag. 2 - Most apps will need to have some kind of multiple windows, like popups and so to extend/configure the game. These will likely bring the need for this manager. Not really.. I don't expect to just run or port apps from the PC which use multiple windows.. on a TV it's just not doable.. don't forget that pretty much everyone will be controlling these with a ps3 controller and I don't see them switching from one window to another with that, it just doesn't feel right. If you look at eskiss, you'll see that's the kind of stuff I expect.. as for popup windows, or even contextual popup menus, (or menus), those shouldn't appear in a console app (but contextual popups still do work since they don't create a new window). I understand what you mean, but we're not talking about the same thing. Games will have to support specific bits for PS3, for instance they will have to know the mode they can achieve some FPS... In an ideal world it's not required, because API would abstract it... but in an ideal world the game would run well enough in all resolutions and this is not required as well :-) Yes, ps3 apps will have ps3 specific code, what my issue with screen res and fullscreen was, was that I didn't want to write a guide that says if you want to change resolution, you need to unset the fullscreen flag, resize the window, then set the fullscreen flag back. anyways if you're creating some kind of portal (eg: homebrew market), or using a browser (ie: ewebkit port) then you'll need multiple windows, or will have a huge work. Not really, a portal can work quite well with a single window, as for a browser, it's windows, yes, but you'd have a different way of accessing them.. the thing of having windows with decorations and using a mouse to move and 'focus' from one window to another is very desktop specific and not very joystick/joypad compatible. 3 - The manager should be simple. It's already possible right now, there is no hard code to do. You just manage windows as Evas_Object (Image) at the parent canvas, so window move = evas_object_move(window_backing_store, x, y). Resize, hide... are similar. Ecore provides such integration with ecore_evas_object_image_new(). What we need is to provide such engine for Elementary, instead of using your PS3 engine. I know it would be pretty simple in theory, but then you start doing it, then you need to add window decorations, then you test and a few use cases don't work, and you end up writing a lot of code instead of the simple couple of lines that you initially planned.. I also honestly don't see a point in doing that, at all, since multi-windowed application are absolutely not my target here. So
Re: [E-devel] Evas/Elm resolution management
Yeah, there's no X on the PS3, so I use ecore_psl1ght for the PS3. I mentionned framebuffer/PS3 because that's what I could think of as 'fullscreen only engines'. But this would also go for the X engine, like I said, an example is the classical game where you could setup the resolution you want it to run in (640x480 or 800x600, etc..) to control the quality/speed and it would auto-change the screen resolution. On Tue, Oct 4, 2011 at 6:59 AM, David Seikel onef...@gmail.com wrote: On Tue, 04 Oct 2011 03:30:26 -0400 Christopher Michael cpmicha...@comcast.net wrote: On 10/03/2011 10:06 PM, Youness Alaoui wrote: Hey Gustavo! Thanks for answering my email! It's appreciated. However it didn't answer my questions, because basically, no, I'm not going to implement a window manager for the PS3 :) Don't forget that all applications/games will be full screen windows, and that 0.1% of people (a lot less I'm sure) actually have a mouse/keyboard hooked to their ps3, so having multiple windows is not a solution. I'm ok with single window apps, and while I do want to have interoperability with existing EFL apps without (or few) modifications, I mostly want something for new app development and a clear API on how to change resolution and how to handle the situation I explained.. most importantly, I'm not going to implement a WM, compositor, wayland or anything fancy like that :) I am not focusing on multi window apps, in my previous email, when I said I used elementary_test, I failed to mention I only ran it with --test-win-only to make sure only one window is created, so this is not the issue here. I like the screen_geometry_set and screen_modes_list, but I think they should go into evas or ecore-evas rather than elm, because they might be useful to people not using elm. Agree with this...tho perhaps ecore_x is a better place ?? Then it would be available to ecore_evas or other apps outside via Ecore_X ? E17 has a resolution config dialog, how does it get/set the screen's resolution? I suppose by using xrandr or something like that? maybe we can abstract that into evas directly, this way it would work on non-X backends like framebuffer/ps3. ecore_x_randr_screen_primary_output_current_size_get ecore_x_randr_screen_primary_output_orientation_get ecore_x_randr_screen_primary_output_refresh_rates_get So on and so forth Hence why I think (with the above) that ecore_x would be a better place... Does Ecore_X work outside of X though? Youness mentions framebuffer/PS3. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas/Elm resolution management
On Tue, Oct 4, 2011 at 9:52 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Oct 3, 2011 at 11:06 PM, Youness Alaoui
kakar...@kakaroto.homelinux.net wrote:
Hey Gustavo!
Thanks for answering my email! It's appreciated.
However it didn't answer my questions, because basically, no, I'm not
going
to implement a window manager for the PS3 :) Don't forget that all
applications/games will be full screen windows, and that 0.1% of people
(a
lot less I'm sure) actually have a mouse/keyboard hooked to their ps3, so
having multiple windows is not a solution. I'm ok with single window
apps,
and while I do want to have interoperability with existing EFL apps
without
(or few) modifications, I mostly want something for new app development
and
a clear API on how to change resolution and how to handle the situation I
explained.. most importantly, I'm not going to implement a WM,
compositor,
wayland or anything fancy like that :)
I am not focusing on multi window apps, in my previous email, when I said
I
used elementary_test, I failed to mention I only ran it with
--test-win-only
to make sure only one window is created, so this is not the issue here.
You're overlooking the problem. :-)
1 - The game content itself will run on the main Ecore_Evas that uses
PS3 directly, not the inner windows. Less overhead... And likely it
will use the GL bindings, as most games will use GL directly and not
Evas. Then, to configure the screen they would use this API to set
their best resolution.
Well, for new apps written for the ps3, I don't see a problem, you'd make
sure you do everything right, use a single window, set the fullscreen flag,
etc..
2 - Most apps will need to have some kind of multiple windows, like
popups and so to extend/configure the game. These will likely bring
the need for this manager.
Not really.. I don't expect to just run or port apps from the PC which use
multiple windows.. on a TV it's just not doable..
don't forget that pretty much everyone will be controlling these with a ps3
controller and I don't see them switching from one window to another with
that, it just doesn't feel right.
If you look at eskiss, you'll see that's the kind of stuff I expect.. as for
popup windows, or even contextual popup menus, (or menus), those shouldn't
appear in a console app (but contextual popups still do work since they
don't create a new window).
3 - The manager should be simple. It's already possible right now,
there is no hard code to do. You just manage windows as Evas_Object
(Image) at the parent canvas, so window move =
evas_object_move(window_backing_store, x, y). Resize, hide... are
similar. Ecore provides such integration with
ecore_evas_object_image_new(). What we need is to provide such engine
for Elementary, instead of using your PS3 engine.
I know it would be pretty simple in theory, but then you start doing it,
then you need to add window decorations, then you test and a few use cases
don't work, and you end up writing a lot of code instead of the simple
couple of lines that you initially planned..
I also honestly don't see a point in doing that, at all, since
multi-windowed application are absolutely not my target here. So let's just
say it's outside the scope of the project :)
I like the screen_geometry_set and screen_modes_list, but I think they
should go into evas or ecore-evas rather than elm, because they might be
useful to people not using elm.
Sure, likely the elm one is a wrapper over ecore_evas functions. When
using my proposed engine, it would apply it to the underlying
Ecore_Evas, for instance.
ok sure :)
E17 has a resolution config dialog, how does it get/set the screen's
resolution? I suppose by using xrandr or something like that? maybe we
can
abstract that into evas directly, this way it would work on non-X
backends
like framebuffer/ps3.
it's Xrandr. But it's complex and every system is different. Unless we
make a complex system that covers them all, they would still be
per-engine. X11 would need modelines, etc.
ok, I don't know much about it, I'd just expect something where you can list
modes and set modes.. where a mode would basically be width and height,
maybe refresh rate too.
If you say there are more stuff that can (and should) be user-configurable,
then the mode_set could take one of the returned values from modes_list, and
that could be a sort of opaque structure
which can be cast into a common Mode object, and it would hold all the extra
parameters needed.
If modeline, etc.. are just settings needed by xrandr or whatever, but it's
not something that should be user-configurable, then you could just make the
logic of fetching the right values from inside the mode_set code.
For my first proposition, since I'm not sure I explained it right, here's an
example (in pseudocode):
-- Ecore_Evas.h --
struct EMode { int width; int height };
EAPI Eina_List *ecore_evas_modes_list
Re: [E-devel] Evas/Elm resolution management
Hey Gustavo!
Thanks for answering my email! It's appreciated.
However it didn't answer my questions, because basically, no, I'm not going
to implement a window manager for the PS3 :) Don't forget that all
applications/games will be full screen windows, and that 0.1% of people (a
lot less I'm sure) actually have a mouse/keyboard hooked to their ps3, so
having multiple windows is not a solution. I'm ok with single window apps,
and while I do want to have interoperability with existing EFL apps without
(or few) modifications, I mostly want something for new app development and
a clear API on how to change resolution and how to handle the situation I
explained.. most importantly, I'm not going to implement a WM, compositor,
wayland or anything fancy like that :)
I am not focusing on multi window apps, in my previous email, when I said I
used elementary_test, I failed to mention I only ran it with --test-win-only
to make sure only one window is created, so this is not the issue here.
I like the screen_geometry_set and screen_modes_list, but I think they
should go into evas or ecore-evas rather than elm, because they might be
useful to people not using elm.
E17 has a resolution config dialog, how does it get/set the screen's
resolution? I suppose by using xrandr or something like that? maybe we can
abstract that into evas directly, this way it would work on non-X backends
like framebuffer/ps3.
What I have done for now is use the fullscreen flag to decide whether or not
to call the resized callback with the full screen size (scale or resize
window). If we add the modes_list and screen_geometry_set functions then it
would fix a few of the issues I had.
Thank you,
Youness.
On Sat, Oct 1, 2011 at 10:51 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
Hi kakaroto, I'm at an event and I assume I couldn't read it all, but ad
I'm
postponing the reply and nobody else did, here comes my main concern and
idea:
The mapping is not the best one. Instead of window to screen, it would be
better to have something else that maps to screen and inside it a window.
Think wayland, but we all will complain about porting it.
That said, to simplify stuff I propose: create a simple hardware screen
manager. It would list and set resolution, defaults to highest. Windows are
painted inside it, even composited and fullscreen case handled. Windows
decorations and positioning can be handled or not.
Main concerns: damn will we create another x11? Why not port it? Why not
wayland? IMHO it is not worth the effort, because we're focusing single
process apps with multi windows.
Implementation proposal: create 2 ecore-evas, one setups the actual
hardware
(done) and another that talks to it and maps ecore-evas to inner windows in
main ecore-evas. Composition is for free, etc. Would be useful for
framebuffer and sdl as well. Elm could just use this second one only.
Optimizations can come later on how to use hardware acceleration and maybe
avoid double buffeting for fullscreen windows.
Window decorations and handling: well need it in elm if we go to wayland
and
want to run in desktops.
Todo:
- ecore_evas_engine_modes_list(engine) - [{width, height, depth,
options string}, ...]
- elm: engine using ecore_evas_object_image_add(). It would create and
manage Ecore_Evas used to hold it, sets to highest or given in $ELM_ENGINE
or config
Extra:
- elm_screen_geometry_{get,set}() - bool (may fail)
- elm_screen_modes_list()
- window decorations and management provided automatically by elm if in
sub window mode
Comments?
On Wednesday, September 28, 2011, Youness Alaoui
kakar...@kakaroto.homelinux.net wrote:
Hi all,
As you know, I'm doing the PS3 port of the EFL and I'm finding myself in
a
bit of a tricky situation, let me explain :
The PS3 is a console that outputs to a TV... TVs can do different
resolutions, 480, 720p or 1080p (as well as a few others). The SDK allows
us
to know what the TV screen supports, and we can choose to switch to
whatever
resolution we want that the TV supports.
What I initially did in the evas engine was that I would take whatever
size
the application requested (evas_output_size_set) and set my buffer to it,
then find the closest matching resolution (the smallest difference in
area
between that resolution and the resolutions supported by the TV), and set
the TV to that res, then scale the output when I draw on screen. So
basically, you'd resize your evas to 200x200 and it would be seen
internally
as 200x200 but the engine would scale it to 720x480 for the screen.
The issue came when I ported elementary. Most (all?) elementary tests
(from
elementary_test app) would create the evas with resolution 1x1 then they
would resize the window to whatever they want, but I never received that
size change request and my buffer would stay at 1x1 and scale that up.
The
reason is that the ecore_evas_resize has a nice little
Re: [E-devel] E SVN: kakaroto IN trunk/ecore: . src/lib/ecore_con
Sorry, I missed that.. it's fixed in the latest svn revision. Thanks On Sun, Oct 2, 2011 at 1:46 PM, Mike Blumenkrantz m...@zentific.com wrote: On Thu, 29 Sep 2011 14:04:54 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: Ecore-con: Test for IPV6 availability Author: kakaroto Date: 2011-09-29 14:04:54 -0700 (Thu, 29 Sep 2011) New Revision: 63680 Trac: http://trac.enlightenment.org/e/changeset/63680 Modified: trunk/ecore/configure.ac trunk/ecore/src/lib/ecore_con/ecore_con.c trunk/ecore/src/lib/ecore_con/ecore_con_ares.c This commit breaks compile with c-ares. Please fix it. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- 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-d2dcopy2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas/Elm resolution management
Hi all, As you know, I'm doing the PS3 port of the EFL and I'm finding myself in a bit of a tricky situation, let me explain : The PS3 is a console that outputs to a TV... TVs can do different resolutions, 480, 720p or 1080p (as well as a few others). The SDK allows us to know what the TV screen supports, and we can choose to switch to whatever resolution we want that the TV supports. What I initially did in the evas engine was that I would take whatever size the application requested (evas_output_size_set) and set my buffer to it, then find the closest matching resolution (the smallest difference in area between that resolution and the resolutions supported by the TV), and set the TV to that res, then scale the output when I draw on screen. So basically, you'd resize your evas to 200x200 and it would be seen internally as 200x200 but the engine would scale it to 720x480 for the screen. The issue came when I ported elementary. Most (all?) elementary tests (from elementary_test app) would create the evas with resolution 1x1 then they would resize the window to whatever they want, but I never received that size change request and my buffer would stay at 1x1 and scale that up. The reason is that the ecore_evas_resize has a nice little check : if (ee-prop.fullscreen) return; so the resize would never work. I 'fixed' it by removing the fullscreen flag for the ps3 engine. Other issue I got was that when I scale, I lose the aspect ratio which might look great. so I'm thinking of adding a way to tell the engine if we want to keep the aspect ratio (then it would center the scaled image on screen) or stretch it completely. Is there a way to set this up natively with the API without having an engine specific option ? Raster said that fullscreen engines need to tell the screen resolution to the app, so what I did was to also add a call to the resize callback after we get resized, more precisely, you set your window to 200x200, you get a resize callback of your 200x200 then it will fetch the real current resolution (720x480) then send another resize callback with the full resolution. Question here, should I do it like that or should I only sent a single resize callback? Most importantly, what happens when the client didn't register his callback yet? for example, eskiss would do the ecore_evas_new with its 1280x768 resolution request, *then* do the callback_resize_set (but it's too late since the resize callback was 'called' during the new), and since it never calls the ecore_evas_resize afterwards, it never knows that the evas it's working on has been resized. What should be the fix for that? should the ecore_evas_callback_resize_set call the callback with the current resolution the first time it's called? Or should we workaround it by always creating 1x1 windows and then call the ecore_evas_resize after we set a callback (in which case it might cause the tv screen to switch resolutions twice for no reason)? Finally, my current biggest design issue, is how to decide whether or not to tell the application that it has been resized to fit the screen. In other words, what if someone wants the window to be 200x200 and get scaled and doesn't actually want to be rendering on 720x480? What if the window has a min/max size set to it? In the case of eskiss, I get a smooth 60fps on 1280x768, but when it tries to draw on any other resolution, its performance drops to 2 or 3 fps (I still have no idea what causes this performance loss), so for eskiss for example, I wouldn't want to have the resize callback called and evas_output_size_set called to resize evas to the screen resolution, I'd want it to stay at 1280x768 and have the engine scale that to whatever the screen wants (and even if we fixed that performance issue, if the TV only supports 480p SD resolutions, eskiss just won't work because the levels and menus, etc.. were not designed for anything less than 1280x768.. and they will not look good on 1920x1080 either). One thought I had was the fullscreen flag.. if the fullscreen flag is set, then I'd call the resize callback and resize evas to fit the screen resolution, if it's not set, then I would just scale. This brings up the issue of the ecore_evas_resize not working in fullscreen mode.. what if I want to change the screen resolution? I'd have to unset the fullscreen flag, then resize, then set it back again (imagine a game where you can choose the fullscreen resolution in the game's video options). That seems like an ugly hack. Maybe I should use the maximized flag instead in that case.. in which case, does any of these flags affect how evas/ecore_evas/elementary work? or is that only engine specific stuff ? Obviously the fullscreen flag affects ecore_evas (since it skips the resize command), will there be any other similar side effects if I make the window have the maximized flag or not? I feel like it would make sense to have the engine set the maximized and fullscreen flags, because that's how it really is, and
Re: [E-devel] E SVN: cedric trunk/web/www/p/news/en
No, the work was not done for linux, it's for the native PS3 operating system. So even if it's an old firmware, you still need to jailbreak it, and if it's a newer firmware, you need to jailbreak it and you don't need to put linux on it. On Fri, Sep 16, 2011 at 10:34 AM, Sven Luther s...@z-innov.com wrote: On Fri, Sep 16, 2011 at 11:45:58AM +0200, Cedric BAIL wrote: On Fri, Sep 16, 2011 at 11:32 AM, Daniel Juyung Seo seojuyu...@gmail.com wrote: yay! happy announcement! i can't wait until i really play e on ps3.(someone has to buy me one.) Hehe, that's an idea ! But don't forget that you need a jail breaked ps3. Or one of the early ones, which provided the otheros functionality ? Friendly, Sven Luther -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore/evas key events
Bump? Is there no one who knows why this was designed this way ? David and I both seem to agree that this isn't the right way to go. On Sun, Sep 11, 2011 at 7:46 AM, David Seikel onef...@gmail.com wrote: On Sun, 11 Sep 2011 04:25:57 -0400 Youness Alaoui kakar...@kakaroto.homelinux.net wrote: While I'm working on adding keyboard support to ecore/ecore-evas for the ps3 engine, I noticed that there is no enum for the various keys, they are strings instead. I do not understand *why* this is done this way... first of all, doing strcmp is less efficient than a int comparison, secondly, it produces uglier code, and most importantly, it's prone to errors.. what if I compare with up instead of Up ? and I don't see any list of what the strings should be.. is it Enter or Return.. The ps3 SDK also can give me either the raw code or the utf-8 of the key code, do I need to put a huge list associating each key code with the keyname ecore expects or can I just use the utf-8 character? Why do I need to change ( into parenleft and why do I need to check if it's 2 or at symbol when the ps3 SDK itself transforms it correctly for me depending on the chosen layout and LED states? Are you forcing every ecore_* module to have a copy of some list to associate keys with the expected keyname ? and every library user to have a big if/else to check the keys entered? Anyone (raster?) knows of any good reason for this design? Yes, I thought that was ugly as well. In my framebuffer project, I also noticed that I'm being passed a strdup of those fixed strings. Which forces me to do lots of strcmps with MORE fixed strings in a big if/else tree. Eww Lucky this project of mine only needs a small subset of the keyboard supported. If I remember rightly it's only the QWERTY layout as well. shudder -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/ecore/src/lib/ecore_sdl
Exactly, I only removed them because the symbols were never defined.
ecore-sdl was always using the ecore-input events, so it never declared
those.
On Mon, Sep 12, 2011 at 2:43 AM, Carsten Haitzler ras...@rasterman.comwrote:
On Mon, 12 Sep 2011 07:41:18 +0200 (CEST) Vincent Torri
vto...@univ-evry.fr
said:
On Sun, 11 Sep 2011, Enlightenment SVN wrote:
Log:
Ecore-sdl: remove unused events and fix semicolon typo and docs
this is an API break
actually ecore_sdl was already broken - it had the extern ints defined but
never backed them with real symbols - so anyone using those event id's
would
have had their code fail to link as it'd have never found symbols. so it's
not
an api break. it was already broken :(
Vincent
Author: kakaroto
Date: 2011-09-11 20:43:46 -0700 (Sun, 11 Sep 2011)
New Revision: 63338
Trac: http://trac.enlightenment.org/e/changeset/63338
Modified:
trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h
trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c
Modified: trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h
===
--- trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h 2011-09-12 03:43:37
UTC (rev 63337) +++ trunk/ecore/src/lib/ecore_sdl/Ecore_Sdl.h
2011-09-12 03:43:46 UTC (rev 63338) @@ -36,14 +36,8 @@
extern C {
#endif
-EAPI extern int ECORE_SDL_EVENT_KEY_DOWN; /** SDL Key Down event */
-EAPI extern int ECORE_SDL_EVENT_KEY_UP; /** SDL Key Up event */
-EAPI extern int ECORE_SDL_EVENT_MOUSE_BUTTON_DOWN; /** SDL Mouse Down
event */ -EAPI extern int ECORE_SDL_EVENT_MOUSE_BUTTON_UP; /** SDL
Mouse
Up event */ -EAPI extern int ECORE_SDL_EVENT_MOUSE_MOVE; /** SDL Mouse
Move event */ -EAPI extern int ECORE_SDL_EVENT_MOUSE_WHEEL; /** SDL
Mouse
Wheel event */ -EAPI extern int ECORE_SDL_EVENT_GOT_FOCUS; /** SDL
Mouse
Wheel event */ -EAPI extern int ECORE_SDL_EVENT_LOST_FOCUS; /** SDL
Mouse
Wheel event */ +EAPI extern int ECORE_SDL_EVENT_GOT_FOCUS;
+EAPI extern int ECORE_SDL_EVENT_LOST_FOCUS;
EAPI extern int ECORE_SDL_EVENT_RESIZE;
EAPI extern int ECORE_SDL_EVENT_EXPOSE;
Modified: trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c
===
--- trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c 2011-09-12 03:43:37
UTC (rev 63337) +++ trunk/ecore/src/lib/ecore_sdl/ecore_sdl.c
2011-09-12 03:43:46 UTC (rev 63338) @@ -50,9 +50,9 @@
}
/**
- * @defgroup Ecore_Sdl_Library_Group Framebuffer Library Functions
+ * @defgroup Ecore_Sdl_Library_Group SDL Library Functions
*
- * Functions used to set up and shut down the Ecore_Framebuffer
functions.
+ * Functions used to set up and shut down the Ecore_Sdl functions.
*/
/**
@@ -96,8 +96,8 @@
EAPI int
ecore_sdl_shutdown(void)
{
- if (--_ecore_sdl_init_count != 0);
- return _ecore_sdl_init_count;
+ if (--_ecore_sdl_init_count != 0)
+ return _ecore_sdl_init_count;
ecore_event_shutdown();
eina_log_domain_unregister(_ecore_sdl_log_dom);
--
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market
businesses
from deploying virtual desktops? How do next-generation virtual
desktops
provide companies an easier-to-deploy, easier-to-manage and more
affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual
desktops
provide companies an easier-to-deploy, easier-to-manage and more
affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
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
--
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop
[E-devel] ecore/evas key events
Hi, While I'm working on adding keyboard support to ecore/ecore-evas for the ps3 engine, I noticed that there is no enum for the various keys, they are strings instead. I do not understand *why* this is done this way... first of all, doing strcmp is less efficient than a int comparison, secondly, it produces uglier code, and most importantly, it's prone to errors.. what if I compare with up instead of Up ? and I don't see any list of what the strings should be.. is it Enter or Return.. The ps3 SDK also can give me either the raw code or the utf-8 of the key code, do I need to put a huge list associating each key code with the keyname ecore expects or can I just use the utf-8 character? Why do I need to change ( into parenleft and why do I need to check if it's 2 or at symbol when the ps3 SDK itself transforms it correctly for me depending on the chosen layout and LED states? Are you forcing every ecore_* module to have a copy of some list to associate keys with the expected keyname ? and every library user to have a big if/else to check the keys entered? Anyone (raster?) knows of any good reason for this design? Thank you, KaKaRoTo -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/ecore
Ok, it's done, I've just pushed r63305 which makes it use sdl-config if it
can't find sdl using pkg-config.
On Thu, Sep 8, 2011 at 4:07 AM, cpmicha...@comcast.net wrote:
- Original Message -
From: Cedric BAIL cedric.b...@free.fr
To: Enlightenment developer list
enlightenment-devel@lists.sourceforge.net
Sent: Wednesday, September 7, 2011 6:53:59 PM
Subject: Re: [E-devel] E SVN: kakaroto trunk/ecore
On Wed, Sep 7, 2011 at 11:18 PM, Youness Alaoui
kakar...@kakaroto.homelinux.net wrote:
You're right, I thought it was native code, not a script, so I didn't
think
it could run on host machine. But I have sdl 1.2 locally, and it does
come
with a pkgconfig file. If there are older versions that don't, then let
me
know, I can revert it.
Last time I give it a look, some distribution did the nice work of
adding the .pc and the latest SDL 1.2 is comming also with a .pc, it's
just previous that don't. And as the code doesn't require much to
support almost all SDL 1.2 version, I mould prefer a fallback to the
sdl-config code rather than a revert to previous method. So just if
.pc isn't found we fallback on sdl-config. That would be great.
+1
dh
On Wed, Sep 7, 2011 at 3:55 AM, Cedric BAIL cedric.b...@free.fr wrote:
On Wed, Sep 7, 2011 at 8:53 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Ecore: Use pkg-config to check for SDL, not sdl-config (which fails
for
cross-compilations)
sdl-config is a shell script that just does some echo things. It work
just fine with cross-compilation as long as you specify it at
configure time. The issue is that older, read sdl 1.2, version don't
come with a pkg-config file. So it would be better if both method
where available.
Author: kakaroto
Date: 2011-09-06 23:53:42 -0700 (Tue, 06 Sep 2011)
New Revision: 63249
Trac: http://trac.enlightenment.org/e/changeset/63249
Modified:
trunk/ecore/configure.ac
Modified: trunk/ecore/configure.ac
===
--- trunk/ecore/configure.ac 2011-09-07 06:53:35 UTC (rev 63248)
+++ trunk/ecore/configure.ac 2011-09-07 06:53:42 UTC (rev 63249)
@@ -523,26 +523,8 @@
# SDL library (ecore_sdl)
have_sdl=no
-SDL_CONFIG=sdl-config
-AC_ARG_WITH([sdl-config],
- [AC_HELP_STRING([--with-sdl-config=PATH], [use sdl-config
specified])],
- [
- SDL_CONFIG=$withval
- AC_MSG_NOTICE([using ${SDL_CONFIG} for sdl-config])
- ])
+PKG_CHECK_MODULES([SDL], [sdl = 1.2.0], [have_sdl=yes],
[have_sdl=no])
-AC_PATH_PROG([SDL_CONFIG], [sdl-config], [], [$PATH])
-
-if test -n $SDL_CONFIG ; then
- SDL_CFLAGS=`$SDL_CONFIG --cflags`
- SDL_LIBS=`$SDL_CONFIG --libs`
- AC_SUBST(SDL_CFLAGS)
- AC_SUBST(SDL_LIBS)
- have_sdl=yes
-else
- PKG_CHECK_MODULES([SDL], [sdl = 1.2.0], [have_sdl=yes],
[have_sdl=no])
-fi
-
if test x${have_sdl} = xyes ; then
PKG_CHECK_EXISTS([sdl = 1.3.0],
[AC_DEFINE(BUILD_ECORE_EVAS_SDL_130, 1, [Support for SVN SDL])])
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level
of
agility. Learn what those decisions are and how to modernize your
storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Cedric BAIL
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level
of
agility. Learn what those decisions are and how to modernize your
storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Cedric BAIL
Re: [E-devel] E SVN: kakaroto trunk/PROTO/escape
Oups, thank you, fixed.
On Wed, Sep 7, 2011 at 3:27 AM, Vincent Torri vto...@univ-evry.fr wrote:
On Wed, 7 Sep 2011, Enlightenment SVN wrote:
Log:
Escape: oups, another copy/paste fail. Fix escape.pc
Author: kakaroto
Date: 2011-09-07 00:24:51 -0700 (Wed, 07 Sep 2011)
New Revision: 63262
Trac: http://trac.enlightenment.org/e/changeset/63262
Modified:
trunk/PROTO/escape/escape.pc.in
Modified: trunk/PROTO/escape/escape.pc.in
===
--- trunk/PROTO/escape/escape.pc.in 2011-09-07 07:18:14 UTC (rev
63261)
+++ trunk/PROTO/escape/escape.pc.in 2011-09-07 07:24:51 UTC (rev
63262)
@@ -3,8 +3,8 @@
libdir=@libdir@
includedir=@includedir@
-Name: evil
-Description: Library that ports on Windows some specific Unix functions.
+Name: escape
+Description: Library that ports on the PS3 some specific Unix functions.
Version: @VERSION@
Libs: -L${libdir} -lescape -lm -lnet
Libs.private:
-lm -lnet should be in Libs.private
Vincent
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto IN trunk/GAMES/eskiss: . src/bin
On Thu, Sep 8, 2011 at 6:42 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Sep 8, 2011 at 12:57 AM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: Ok, so ecore_evas_visible_set and ecore_evas_visible_get? it's about cursors. So ecore_evas_cursor_visible... lol, oups, of course, I meant ecore_evas_cursor_visible_set/get :) As for the return value, I was thinking of using it for apps that would require a cursor but it can't be shown (like for example on phones that wouldn't support having a cursor at all), then the app would need to know and draw one itself. Doing the trick in ecore-evas directly is a good idea, but if there's an engine that doesn't support changing the cursor's bitmap for example (think about framebuffer for example, no cursor support I suppose?), so returning FALSE to the set would be a good way to say that we can't do any tricks, and then visible_get would tell it if the engine does show a cursor (no cursor, can't fake one, do it yourself, has a cursor, can't change it to transparent, change your UI accordingly). You probably have more insight on this than me though, so let me know what you think. Ecore_Evas should do this. AFAIR we do that in fb engine... or we could do. Just create an Evas_Object* with desired cursor and enjoy. Ok, if ecore_evas already has support for it (for fb) where it just draws a cursor object on top of the screen, then it should make it easy, and in which case, I guess we might not need a return value. I can only see the use case of an engine that has a cursor on screen with no way of changing the cursor's bitmap and no way to disable it, but it's such a rare case (if it even exists) that I suppose most people would just ignore that return value anyways. Raster, what do you think? And what do others think too? Gustavo convinced me enough so I'm good either way. Do you think it's worth adding a boolean return value or it's not worth it ? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/ecore
You're right, I thought it was native code, not a script, so I didn't think
it could run on host machine. But I have sdl 1.2 locally, and it does come
with a pkgconfig file. If there are older versions that don't, then let me
know, I can revert it.
On Wed, Sep 7, 2011 at 3:55 AM, Cedric BAIL cedric.b...@free.fr wrote:
On Wed, Sep 7, 2011 at 8:53 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Ecore: Use pkg-config to check for SDL, not sdl-config (which fails for
cross-compilations)
sdl-config is a shell script that just does some echo things. It work
just fine with cross-compilation as long as you specify it at
configure time. The issue is that older, read sdl 1.2, version don't
come with a pkg-config file. So it would be better if both method
where available.
Author: kakaroto
Date: 2011-09-06 23:53:42 -0700 (Tue, 06 Sep 2011)
New Revision: 63249
Trac: http://trac.enlightenment.org/e/changeset/63249
Modified:
trunk/ecore/configure.ac
Modified: trunk/ecore/configure.ac
===
--- trunk/ecore/configure.ac2011-09-07 06:53:35 UTC (rev 63248)
+++ trunk/ecore/configure.ac2011-09-07 06:53:42 UTC (rev 63249)
@@ -523,26 +523,8 @@
# SDL library (ecore_sdl)
have_sdl=no
-SDL_CONFIG=sdl-config
-AC_ARG_WITH([sdl-config],
- [AC_HELP_STRING([--with-sdl-config=PATH], [use sdl-config
specified])],
- [
-SDL_CONFIG=$withval
-AC_MSG_NOTICE([using ${SDL_CONFIG} for sdl-config])
- ])
+PKG_CHECK_MODULES([SDL], [sdl = 1.2.0], [have_sdl=yes],
[have_sdl=no])
-AC_PATH_PROG([SDL_CONFIG], [sdl-config], [], [$PATH])
-
-if test -n $SDL_CONFIG ; then
- SDL_CFLAGS=`$SDL_CONFIG --cflags`
- SDL_LIBS=`$SDL_CONFIG --libs`
- AC_SUBST(SDL_CFLAGS)
- AC_SUBST(SDL_LIBS)
- have_sdl=yes
-else
- PKG_CHECK_MODULES([SDL], [sdl = 1.2.0], [have_sdl=yes],
[have_sdl=no])
-fi
-
if test x${have_sdl} = xyes ; then
PKG_CHECK_EXISTS([sdl = 1.3.0],
[AC_DEFINE(BUILD_ECORE_EVAS_SDL_130, 1, [Support for SVN SDL])])
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Cedric BAIL
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto IN trunk/GAMES/eskiss: . src/bin
That's a good idea. the PS3's GPU also has a special command to hide/show a
cursor on screen, and I was planning on doing an API for it in
ecore_psl1ght, but it would be better to integrate it directly into
ecore_evas. I think an API like the one in ecore_x would be good, but return
a boolean instead of void, this way you can report errors (for engines that
don't support it, or for the ps3 where it wouldn't work if you don't supply
it with a cursor bitmap first).
So, what do you think about this API :
EAPI Eina_Bool ecore_evas_cursor_show(Ecore_Evas *ee, Eina_Bool show);
If agreed on, should I just go ahead and add it to Ecore-evas?
KaKaRoTo
On Wed, Sep 7, 2011 at 11:09 AM, Gustavo Barbieri
barbi...@profusion.mobiwrote:
To disable cursor we can just use standard ecore_evas and set a
transparent rectangle. But really, it is so common we could add it in
ecore_evas itself
--Gustavo
Sent from my iPhone
On 07/09/2011, at 03:59, Enlightenment SVN no-re...@enlightenment.org
wrote:
Log:
Eskiss: Disable forced dependency on ecore-x
Author: kakaroto
Date: 2011-09-06 23:58:54 -0700 (Tue, 06 Sep 2011)
New Revision: 63257
Trac: http://trac.enlightenment.org/e/changeset/63257
Modified:
trunk/GAMES/eskiss/configure.ac trunk/GAMES/eskiss/src/bin/main.c
Modified: trunk/GAMES/eskiss/configure.ac
===
--- trunk/GAMES/eskiss/configure.ac2011-09-07 06:58:48 UTC (rev
63256)
+++ trunk/GAMES/eskiss/configure.ac2011-09-07 06:58:54 UTC (rev
63257)
@@ -54,8 +54,14 @@
# Eina library
-PKG_CHECK_MODULES(ESKISS, [edje ecore-evas ecore-x ecore-file ecore evas
eet eina])
+PKG_CHECK_MODULES(ESKISS, [edje ecore-evas ecore-file ecore evas eet
eina])
+PKG_CHECK_MODULES(ECORE_X, [ecore-x], [have_ecore_x=yes],
[have_ecore_x=no])
+AM_CONDITIONAL(HAVE_ECORE_X, test x$have_ecore_x = xyes)
+if test x$have_ecore_x = xyes; then
+ AC_DEFINE(HAVE_ECORE_X, 1, [Ecore-x available])
+fi
+
### Checks for header files
AC_CHECK_HEADER([chipmunk/chipmunk.h],
Modified: trunk/GAMES/eskiss/src/bin/main.c
===
--- trunk/GAMES/eskiss/src/bin/main.c2011-09-07 06:58:48 UTC (rev
63256)
+++ trunk/GAMES/eskiss/src/bin/main.c2011-09-07 06:58:54 UTC (rev
63257)
@@ -24,7 +24,10 @@
#include level.h
#include level_editor.h
#include level_chooser.h
+
+#ifdef HAVE_ECORE_X
#include Ecore_X.h
+#endif
int _drawin_log_domain = -1;
@@ -311,11 +314,13 @@
if (is_fullscreen)
ecore_evas_fullscreen_set(application-ee, EINA_TRUE);
+#ifdef HAVE_ECORE_X
if (!has_cursor
!strcmp(ecore_evas_engine_name_get(application-ee), software_x11))
{
Ecore_X_Window ewin =
ecore_evas_software_x11_window_get(application-ee);
ecore_x_window_cursor_show(ewin, 0);
}
+#endif
ecore_evas_show(application-ee);
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto IN trunk/GAMES/eskiss: . src/bin
Ok, so ecore_evas_visible_set and ecore_evas_visible_get? As for the return value, I was thinking of using it for apps that would require a cursor but it can't be shown (like for example on phones that wouldn't support having a cursor at all), then the app would need to know and draw one itself. Doing the trick in ecore-evas directly is a good idea, but if there's an engine that doesn't support changing the cursor's bitmap for example (think about framebuffer for example, no cursor support I suppose?), so returning FALSE to the set would be a good way to say that we can't do any tricks, and then visible_get would tell it if the engine does show a cursor (no cursor, can't fake one, do it yourself, has a cursor, can't change it to transparent, change your UI accordingly). You probably have more insight on this than me though, so let me know what you think. KaKaRoTo On Wed, Sep 7, 2011 at 9:42 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Sep 7, 2011 at 10:08 PM, Youness Alaoui kakar...@kakaroto.homelinux.net wrote: That's a good idea. the PS3's GPU also has a special command to hide/show a cursor on screen, and I was planning on doing an API for it in ecore_psl1ght, but it would be better to integrate it directly into ecore_evas. I think an API like the one in ecore_x would be good, but return a boolean instead of void, this way you can report errors (for engines that don't support it, or for the ps3 where it wouldn't work if you don't supply it with a cursor bitmap first). So, what do you think about this API : EAPI Eina_Bool ecore_evas_cursor_show(Ecore_Evas *ee, Eina_Bool show); If agreed on, should I just go ahead and add it to Ecore-evas? visible_set() would be more EFL-like. With visible_get() to pair. I wonder if the return will be of any use... if the user must do something else, then just do it in Ecore_Evas. For example, if you don't support turning off the cursor, do some trick, like transparent bitmap. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
