Re: [E-devel] Community Building
dan sinclair wrote: On 2-Aug-08, at 1:40 AM, Nick Hughart wrote: Vincent Torri wrote: On Sat, 2 Aug 2008, dan sinclair wrote: I'd say you're so eager to release something you're not thinking about the impression it gives. Changing things in a pre-1.0 is fine and expected. Releasing a 1.0 and then breaking it or making major changes a few months down the road is a very bad impression. I don't think that if we release a 1.0 soon, the next the next major release wiil be out in a few month. It will follow the same release process (some years) The problem is, the two issues that have come up that are being considered as blockers are things that may affect how many people want to use the EFL. So waiting 3-4 years after a disappointing release may just push people away. We should at least try to address the shortcomings now or people will either have to wait years for the new release or get a release so soon that they have to readjust everything. Either way, I'm sure they won't be happy. It all comes down to when you're doing the 2.0 release. If you do a 2.0 release in a few months it looks like we just rushed a 1.0 out the door to say we had a 1.0. Major releases should last a few _years_. If we're seriously considering ripping out Embryo in a few _months_ that's a pretty good sign it isn't ready to be released yet. If we know we're going to rip out Embryo and we push out Edje with Embryo scripting just to remove it in the next release it isn't going to make people happy. They'll have to port all their themes to the new scripting language. We're better to wait until we have a foundation we want to work from to get there. You're releasing something before it should be released just to give the impression of a 1.0 for something that isn't 1.0. That leaves a worse taste as a developer then holding off the release until we're pretty sure what we've got will be it for the long haul. Explain why you think that current efl can't be considered as 1.0, please I never said the EFL in general wasn't ready for a 1.0. I'm specifically talking about Embryo as we don't know it's future. Ecore could probably be released once ecore_data is removed and we could do a point release the splits it into separate packages. Evas, I don't follow the Evas discussions so I have no idea. Edje needs the Embryo question asked. Efreet could probably go as the API is stable and we fixup any caching issues in a point release. e_dbus, no idea don't use it. Eet is already 1.0. What this all comes down to, and what the major blocker for most of this is, is Eina. Pretty much everything in CVS will end up depending on it. Let's push to get that as a 1.0 first. It seems that you have the same opinion than raster has about enlightenment, that is enlightenment will be 1.0 when there will be no more improvements he will be able to think about. No, I don't think that. I just think picking an arbitrary library is silly. We should think about what needs to get released and what has a stable API. What the problem with doing releases ? It helps packagers and users, people that use commercially the efl are satisfied because they know they have a solid base set of libs they can work with. There is nothing wrong with doing releases. I just don't see the point of releasing for the sake of releasing when we already know we're going to break the API. If you want to push something out the door, what about Efreet, or getting Eina done then doing Ecore. We don't have to start with an Embryo release. We don't have to push Embryo until we're ready to push Edje. Pushing Edje has to wait until we push Evas (which also has to wait for Eina). Heh, I would like to release all the efl as 1.0 (maybe after the eina move). Then, in a few years push the 2.0 release (for e18 ?). There are *lots* of stuff to do for a 2.0 release for evas and edje (i don't really know for ecore). About evas, you see the discussion between mainly Jose, Jorge and raster. About edje Gustavo told me that raster has huge plans about it. So why not writing edje 2 with these plans and with another scripting language than embryo when thee plans will be known a little bit more ? I've made a similiar argument for EDJE, push it as is with embryo and don't expect the flash/silverlight/etc crowd to jump on board right away and make user interfaces. Use EDJE for what it can do now and then in the future we can do a 2.0 release that adds the extra stuff. But by that time, people may have throughly invested in embryo and it may cost them quite a bit to change all that. About efreet, I agree too that it should be out after the eina move. I'd like to see the icon caching improved personally since right now it might as well not even be there, doesn't produce any significant speedups. Isn't this just disabled at the moment? Sebastian would know for
Re: [E-devel] Community Building
On Sat, Aug 2, 2008 at 2:40 AM, Nick Hughart [EMAIL PROTECTED] wrote: Vincent Torri wrote: On Sat, 2 Aug 2008, dan sinclair wrote: I'd say you're so eager to release something you're not thinking about the impression it gives. Changing things in a pre-1.0 is fine and expected. Releasing a 1.0 and then breaking it or making major changes a few months down the road is a very bad impression. I don't think that if we release a 1.0 soon, the next the next major release wiil be out in a few month. It will follow the same release process (some years) The problem is, the two issues that have come up that are being considered as blockers are things that may affect how many people want to use the EFL. So waiting 3-4 years after a disappointing release may just push people away. We should at least try to address the shortcomings now or people will either have to wait years for the new release or get a release so soon that they have to readjust everything. Either way, I'm sure they won't be happy. That's just PLAIN WRONG. This leads to infinite, because there is no such perfect code ore release, leading to what we have now: never release. We must put a deadline and honor it. It's very similar to what Gnome and Kernel guys are doing, and its working. It's what Mark is trying to push and I really like it. Things like Edje and Evas have great potential and will never calm down, people will always come with ideas, suggestions, rewrites and all we know, much like Linux Kernel. If we don't specify a time-based release we'll never release, because the todo/features list is always growing. You're releasing something before it should be released just to give the impression of a 1.0 for something that isn't 1.0. That leaves a worse taste as a developer then holding off the release until we're pretty sure what we've got will be it for the long haul. Explain why you think that current efl can't be considered as 1.0, please It seems that you have the same opinion than raster has about enlightenment, that is enlightenment will be 1.0 when there will be no more improvements he will be able to think about. What the problem with doing releases ? It helps packagers and users, people that use commercially the efl are satisfied because they know they have a solid base set of libs they can work with. If you want to push something out the door, what about Efreet, or getting Eina done then doing Ecore. We don't have to start with an Embryo release. We don't have to push Embryo until we're ready to push Edje. Pushing Edje has to wait until we push Evas (which also has to wait for Eina). Heh, I would like to release all the efl as 1.0 (maybe after the eina move). Then, in a few years push the 2.0 release (for e18 ?). There are *lots* of stuff to do for a 2.0 release for evas and edje (i don't really know for ecore). About evas, you see the discussion between mainly Jose, Jorge and raster. About edje Gustavo told me that raster has huge plans about it. So why not writing edje 2 with these plans and with another scripting language than embryo when thee plans will be known a little bit more ? I've made a similiar argument for EDJE, push it as is with embryo and don't expect the flash/silverlight/etc crowd to jump on board right away and make user interfaces. Use EDJE for what it can do now and then in the future we can do a 2.0 release that adds the extra stuff. But by that time, people may have throughly invested in embryo and it may cost them quite a bit to change all that. As I said, it already happened, don't hide under the we did not official 1.0 yet. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sat, Aug 2, 2008 at 2:53 AM, dan sinclair [EMAIL PROTECTED] wrote: On 2-Aug-08, at 1:40 AM, Nick Hughart wrote: Vincent Torri wrote: On Sat, 2 Aug 2008, dan sinclair wrote: I'd say you're so eager to release something you're not thinking about the impression it gives. Changing things in a pre-1.0 is fine and expected. Releasing a 1.0 and then breaking it or making major changes a few months down the road is a very bad impression. I don't think that if we release a 1.0 soon, the next the next major release wiil be out in a few month. It will follow the same release process (some years) The problem is, the two issues that have come up that are being considered as blockers are things that may affect how many people want to use the EFL. So waiting 3-4 years after a disappointing release may just push people away. We should at least try to address the shortcomings now or people will either have to wait years for the new release or get a release so soon that they have to readjust everything. Either way, I'm sure they won't be happy. It all comes down to when you're doing the 2.0 release. If you do a 2.0 release in a few months it looks like we just rushed a 1.0 out the door to say we had a 1.0. Major releases should last a few _years_. If we're seriously considering ripping out Embryo in a few _months_ that's a pretty good sign it isn't ready to be released yet. If we know we're going to rip out Embryo and we push out Edje with Embryo scripting just to remove it in the next release it isn't going to make people happy. They'll have to port all their themes to the new scripting language. We're better to wait until we have a foundation we want to work from to get there. As I said to mekius, this will lead to never releasing, as we have now. If we have basically 3 top components: ecore, evas and edje and 2 of them (evas and edje) are full of potential and ideas, we'll never release anything because they'll never be ready and all the other packages that serve as base for them will not be released because they might not be needed when we change something. Again, this is much like kernel development. It will never stabilize to that point, we'll always have ideas and people will like to hack on it. That's one more reason to release, so people can hack ON it while others hack USING it. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] [website] cms?
On Sat, 2 Aug 2008 00:18:23 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: i agree here. i like our fairly flat (and lax) access structure. if we trust you to go writing bits of e.org's website - we trust you to write code - if that is your skill, or to just know to keep your hands off what you aren't good at. people make mistakes and if someone who was given access in order to do www goes and starts screwing with code so it breaks - a few reprimands on the mailing lists should cure that really fast, and if it doesn't - access to cvs can be removed (and will be) as if we can't trust them - why keep access to www? i like our own and flat trust structure. it's simple. it works as we are not a massive organisation. it allows or fluid movement and help wherever it is needed quickly. it shows we have faith in our fellow humans :) On Fri, Aug 1, 2008 at 5:27 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: so eventually went back to an old original method. www lives in cvs - u want to work on it, u get cvs access. committing means it auto-updates. if u need to test the php locally setting up a local apache and mod-php, allow symlinks outside of the www doc dir to point to your homedir's cvs checkout of the www site, worsk just fine. it's simple and works. the php is also very simple. the main www site is meant to be simple and relatively static - the wiki, and other sites (trac, bugzilla etc.) are where the dynamic stuff happens... There is another advantage to keeping the site in CVS: you avoid segmenting the community into artificial sub-communities, or trying to place technical barriers around social structures. There is a flat hierarchy of trust, either you've earned it enough to get access or you haven't. There is no temptation to give people access to the website since it's only the website, and anyone with CVS access should know how interact within the project. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ 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)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sat, 2 Aug 2008 00:12:00 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Fri, Aug 1, 2008 at 7:46 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: oh of course. details! :) we can dot the i's and cross the t's soon enough. :) Unfortunately, this really needs to be done sooner than later. Without a license listed, we now need to get the permission of everyone that has contributed to it in order to re-license it. At least in the US (and I believe all of North America), no license means all rights reserved. as such isn't eina copying code from ecore/evas in order just to be implemented.. in which case... it is bsd (ie same license s ecore evas)? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: embryo release in 2 weeks
On Sat, 02 Aug 2008 00:03:33 -0500 Nick Hughart [EMAIL PROTECTED] babbled: Jose Gonzalez wrote: Gustavo wrote: Since Edje is target at designers (ie: colors are not premul, etc), I think we should go with JS since most designers know it somehow, even if they don't really know, they think they do and they will not be afraid of trying it... Also, many systems use it as scripting language, comes to mind Photoshop, Qt-based applications and it's the official language of KDE for exactly that reason. I remember INdT designers hacking some Photoshop scripts just because they knew bits of JS from web development. Lua is good, yes, but I think that going with a more widespread language is the way to go. Indeed. Javascript has enourmous widespread use on the web, very well knonwn to designers, very close to flash's actionscript, and runtimes for it are becoming faster. It should be a verious consideration. Just wanted to note that ActionScript is actually based on ECMAScript afaik which is what JS is based on and thus why they are so similar. in all honesty - javascript is not going to make anything a lot better... as the only thing we will get is language constructs - the massive pool of knowledge on js is its use WITH www objects and with the api and event facilities a browser provides. this will not be the same. this bit will be different, thus all we get is syntax and core language constructs (i.e. C without even libc). so aqs such the usefulness of such a syntax is not so much - as frankly - lua, java, javascript, c, c++ all inherit vastly similar core syntax and constructs. if we were doing lisp or haskel or prolog... i'd say we are making life hard for designers. even python diverges much more than lua/c/c+ +/perl/js etc. etc. - so we're in ballpark already. remember they likely also have to learn all of edje/edc and the internal edje api we expose anyway... so lanugage i think is a moot point here beyond overall core syntax style - and if it's familiar and easy. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
Carsten wrote: On Sat, 2 Aug 2008 00:12:00 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Fri, Aug 1, 2008 at 7:46 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: oh of course. details! :) we can dot the i's and cross the t's soon enough. :) Unfortunately, this really needs to be done sooner than later. Without a license listed, we now need to get the permission of everyone that has contributed to it in order to re-license it. At least in the US (and I believe all of North America), no license means all rights reserved. as such isn't eina copying code from ecore/evas in order just to be implemented.. in which case... it is bsd (ie same license s ecore evas)? Ummm That sounds kind of viral to me - if you copy any code from anything with this license then you must also license the result the same. Wasn't that one of the points claimed here as being 'evil' somehow? No freedom of choice, etc. :) Click here to find a massage therapy school near you. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l9desx4jY6iUkop8By4K2OCgszplF2kd32IsyEMCxzM0ZLu/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: embryo release in 2 weeks
On Sat, Aug 2, 2008 at 3:52 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 02 Aug 2008 00:03:33 -0500 Nick Hughart [EMAIL PROTECTED] babbled: Jose Gonzalez wrote: Gustavo wrote: Since Edje is target at designers (ie: colors are not premul, etc), I think we should go with JS since most designers know it somehow, even if they don't really know, they think they do and they will not be afraid of trying it... Also, many systems use it as scripting language, comes to mind Photoshop, Qt-based applications and it's the official language of KDE for exactly that reason. I remember INdT designers hacking some Photoshop scripts just because they knew bits of JS from web development. Lua is good, yes, but I think that going with a more widespread language is the way to go. Indeed. Javascript has enourmous widespread use on the web, very well knonwn to designers, very close to flash's actionscript, and runtimes for it are becoming faster. It should be a verious consideration. Just wanted to note that ActionScript is actually based on ECMAScript afaik which is what JS is based on and thus why they are so similar. in all honesty - javascript is not going to make anything a lot better... as the only thing we will get is language constructs - the massive pool of knowledge on js is its use WITH www objects and with the api and event facilities a browser provides. this will not be the same. this bit will be different, thus all we get is syntax and core language constructs (i.e. C without even libc). so aqs such the usefulness of such a syntax is not so much - as frankly - lua, java, javascript, c, c++ all inherit vastly similar core syntax and constructs. if we were doing lisp or haskel or prolog... i'd say we are making life hard for designers. even python diverges much more than lua/c/c+ +/perl/js etc. etc. - so we're in ballpark already. remember they likely also have to learn all of edje/edc and the internal edje api we expose anyway... so lanugage i think is a moot point here beyond overall core syntax style - and if it's familiar and easy. :) As I mentioned in other mails, I strongly disagree. Users, specially non-hackers (ie: designers, the target audience) are usually very reluctant to learn a new programming language. It's more psycological than technical, as you said the actual work will be almost the same for them, however their willingness to do so will be heavily impacted by such. As you said, like in the C without libC, if you present hackers that know C with a machine with C w/o libC or another language, they'll go with C because they think they know it more and thus will be easier. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Eina ideas and requests
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sat, 02 Aug 2008 03:07:27 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: Carsten wrote: On Sat, 2 Aug 2008 00:12:00 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Fri, Aug 1, 2008 at 7:46 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: oh of course. details! :) we can dot the i's and cross the t's soon enough. :) Unfortunately, this really needs to be done sooner than later. Without a license listed, we now need to get the permission of everyone that has contributed to it in order to re-license it. At least in the US (and I believe all of North America), no license means all rights reserved. as such isn't eina copying code from ecore/evas in order just to be implemented.. in which case... it is bsd (ie same license s ecore evas)? Ummm That sounds kind of viral to me - if you copy any code from anything with this license then you must also license the result the same. Wasn't that one of the points claimed here as being 'evil' somehow? No freedom of choice, etc. :) that is the case with EVERY license... EXCEPT public domain. (and licenses that are compatible subsets). viral is always referred to as LINKING - if the license crosses linking boundaries or not (ie link to libBLAH.so - vs copy .c files from libBLAH into your project). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Weird crash...
Did you use FM in any way before the crash? If so, can you describe your actions? Even if they were taken like hours before the crash. On Fri, Aug 1, 2008 at 4:32 PM, Toma [EMAIL PROTECTED] wrote: I was just about to watch a movie when bam, E17 crashed and took itself out. Now thats ok, Im kind of cool with that, but it started using more CPU than normal. So I busted open a xterm and ran 'ps aux' to find this... toma 13572 81.8 0.4 10492 2556 ?Rs 20:26 1:13 /usr/local/bin/enlightenment_fm_op rm /home/toma/.e/e/themes toma 13587 0.0 0.6 11052 3296 ?Ss 20:27 0:00 /usr/local/bin/enlightenment_fm toma 13590 0.0 0.1 2644 1004 pts/1R+ 20:28 0:00 ps aux Note the top command saying e_fm_op is removing all my themes. ALL. Of my freaking themes. Stuff I dont have backed up and thought I'd never need to back up. It even removed a couple folders in there that were not even themes. Why would E do this? Toma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- King regards, Fedor Gusev. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
Am Sat, 2 Aug 2008 08:17:43 +1000 schrieb Carsten Haitzler (The Rasterman): On Tue, 29 Jul 2008 00:40:04 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: One idea I discussed with Vincent today is that our lack of releases has caused many users to lose interest and stop taking notice of the project. I realize that there is a lot of talk surrounding changes to core infrastructure (data lib, graphics, scripting language, etc), but has there been any thought recently put into how our release process should be structured? There used to be a TODO list for e17, and that has been moved to Trac, but has anyone took a hard look at what is necessary for cutting a stable release? Even if we don't release e17 1.0, we may be able to move the core libs towards releases like eet. yeah. i agree we need releases. it's probably our biggest issue. right now in lib-space i'd want to clean up 2 major thnigs that are currently underway: 1. eina - move fully to using it. remove all data stuff from ecore/evas - provide compatibility macros so code at least compiles - then 1 macro at a time, remove/fix then. 2. edje - i have been mulling dropping embryo in favor of lua. let's discuss? (reasons - better full-scripting support with more full language support. lua seems to be one of the best fits of the bill). I vote to use LUA for scripting too. I've embedded it into several commercial products in the past. It was each time a really good choose. It's easy to understand, small and I think most important has a really big community. regards Andreas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Weird crash...
2008/8/2 Fedor Gusev [EMAIL PROTECTED]: Did you use FM in any way before the crash? If so, can you describe your actions? Even if they were taken like hours before the crash. Well, the initial crash happened when opening a movie in smplayer. Generally it flashes a black screen before starting the video. Thats using 'xv' video output. Next it crashed just before the video actually loaded. This sent E into the 'white box of death' seg fault screen. After restarting the theme went back to default straight away. Finding this odd, I opened the theme selector (which of course has an instance of efm in it)... it took forever to load so I ran 'ps aux' to see if something else was chewing up all my CPU. I then had the results you see below. I did not click anything in theme selector. The odd thing is that wasnt actually 'removing' as the e_fm_op might suggest, unless it first copied the files to the random character directory then proceeded to delete the files. So thats how it went down. If any more details are needed, let me know. Toma On Fri, Aug 1, 2008 at 4:32 PM, Toma [EMAIL PROTECTED] wrote: I was just about to watch a movie when bam, E17 crashed and took itself out. Now thats ok, Im kind of cool with that, but it started using more CPU than normal. So I busted open a xterm and ran 'ps aux' to find this... toma 13572 81.8 0.4 10492 2556 ?Rs 20:26 1:13 /usr/local/bin/enlightenment_fm_op rm /home/toma/.e/e/themes toma 13587 0.0 0.6 11052 3296 ?Ss 20:27 0:00 /usr/local/bin/enlightenment_fm toma 13590 0.0 0.1 2644 1004 pts/1R+ 20:28 0:00 ps aux Note the top command saying e_fm_op is removing all my themes. ALL. Of my freaking themes. Stuff I dont have backed up and thought I'd never need to back up. It even removed a couple folders in there that were not even themes. Why would E do this? Toma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- King regards, Fedor Gusev. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-08-02 07:11:45 -0700
Build log for Enlightenment DR 0.17 on 2008-08-02 07:11:45 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, skel, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eina ideas and requests
On Sat, Aug 2, 2008 at 9:27 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
I agree with you, making eina thread safe is one of the goals we have.
An making the data types thread safe is a must.
As a side note, there are already comments on such a thing for
eina_error, I'd like to make the error subsystem thread safe, and add
a callback to actually do something when an error wants to be printed
instead of sending the data to stdout, a callback so a an application
might want to write the errors into a file (logging), etc.
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
Yes, this is good too, im not sure if cedric might want it, as he is
some kind of performance addict :) and adding another pointer
reference might slow it down, but i prefer this normalization on the
API, is a trade-off i prefer.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
Im not sure if i understood this correctly, but i think what you are
proposing is similar to what Ecore_List do, you keep track of the last
accessed node on one side and the last added/deleted node in the
other, even so IMHO the ecore_list API is not clear enough on what
functions update one or the other, and yes, this is possible, i did an
ecore_list wrapper using evas_list (i gave the reference for it on
another ml thread), and i think is good to have to speed up node
retrieve.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
Nick Hughart wrote: dan sinclair wrote: On 2-Aug-08, at 1:40 AM, Nick Hughart wrote: Vincent Torri wrote: On Sat, 2 Aug 2008, dan sinclair wrote: I'd say you're so eager to release something you're not thinking about the impression it gives. Changing things in a pre-1.0 is fine and expected. Releasing a 1.0 and then breaking it or making major changes a few months down the road is a very bad impression. I don't think that if we release a 1.0 soon, the next the next major release wiil be out in a few month. It will follow the same release process (some years) The problem is, the two issues that have come up that are being considered as blockers are things that may affect how many people want to use the EFL. So waiting 3-4 years after a disappointing release may just push people away. We should at least try to address the shortcomings now or people will either have to wait years for the new release or get a release so soon that they have to readjust everything. Either way, I'm sure they won't be happy. It all comes down to when you're doing the 2.0 release. If you do a 2.0 release in a few months it looks like we just rushed a 1.0 out the door to say we had a 1.0. Major releases should last a few _years_. If we're seriously considering ripping out Embryo in a few _months_ that's a pretty good sign it isn't ready to be released yet. If we know we're going to rip out Embryo and we push out Edje with Embryo scripting just to remove it in the next release it isn't going to make people happy. They'll have to port all their themes to the new scripting language. We're better to wait until we have a foundation we want to work from to get there. You're releasing something before it should be released just to give the impression of a 1.0 for something that isn't 1.0. That leaves a worse taste as a developer then holding off the release until we're pretty sure what we've got will be it for the long haul. Explain why you think that current efl can't be considered as 1.0, please I never said the EFL in general wasn't ready for a 1.0. I'm specifically talking about Embryo as we don't know it's future. Ecore could probably be released once ecore_data is removed and we could do a point release the splits it into separate packages. Evas, I don't follow the Evas discussions so I have no idea. Edje needs the Embryo question asked. Efreet could probably go as the API is stable and we fixup any caching issues in a point release. e_dbus, no idea don't use it. Eet is already 1.0. What this all comes down to, and what the major blocker for most of this is, is Eina. Pretty much everything in CVS will end up depending on it. Let's push to get that as a 1.0 first. It seems that you have the same opinion than raster has about enlightenment, that is enlightenment will be 1.0 when there will be no more improvements he will be able to think about. No, I don't think that. I just think picking an arbitrary library is silly. We should think about what needs to get released and what has a stable API. What the problem with doing releases ? It helps packagers and users, people that use commercially the efl are satisfied because they know they have a solid base set of libs they can work with. There is nothing wrong with doing releases. I just don't see the point of releasing for the sake of releasing when we already know we're going to break the API. If you want to push something out the door, what about Efreet, or getting Eina done then doing Ecore. We don't have to start with an Embryo release. We don't have to push Embryo until we're ready to push Edje. Pushing Edje has to wait until we push Evas (which also has to wait for Eina). Heh, I would like to release all the efl as 1.0 (maybe after the eina move). Then, in a few years push the 2.0 release (for e18 ?). There are *lots* of stuff to do for a 2.0 release for evas and edje (i don't really know for ecore). About evas, you see the discussion between mainly Jose, Jorge and raster. About edje Gustavo told me that raster has huge plans about it. So why not writing edje 2 with these plans and with another scripting language than embryo when thee plans will be known a little bit more ? I've made a similiar argument for EDJE, push it as is with embryo and don't expect the flash/silverlight/etc crowd to jump on board right away and make user interfaces. Use EDJE for what it can do now and then in the future we can do a 2.0 release that adds the extra stuff. But by that time, people may have throughly invested in embryo and it may cost them quite a bit to change all that. About efreet, I agree too that it should be out after the eina move. I'd like to see the icon caching improved personally since right now it might as well not even be there, doesn't produce any significant speedups. Isn't this just disabled at the moment? Sebastian would
Re: [E-devel] Eina ideas and requests
On Sat, Aug 2, 2008 at 11:34 AM, Jorge Luis Zapata Muga
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 9:27 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
I agree with you, making eina thread safe is one of the goals we have.
An making the data types thread safe is a must.
As a side note, there are already comments on such a thing for
eina_error, I'd like to make the error subsystem thread safe, and add
a callback to actually do something when an error wants to be printed
instead of sending the data to stdout, a callback so a an application
might want to write the errors into a file (logging), etc.
great!
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
Yes, this is good too, im not sure if cedric might want it, as he is
some kind of performance addict :) and adding another pointer
reference might slow it down, but i prefer this normalization on the
API, is a trade-off i prefer.
I don't want everyone to always use it, it can be kept as a helper and
people who wish to have an abstract data model (usually void *) and
access it as a list can provide the iterator. I use it in my mvc
lists, something like: model_set(void *model, eina_iterator_t
*(*accessor_constructor)(void *model)) and whenever I want to iterate
the whole list, I delete the old, create a new and start the loop.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
Im not sure if i understood this correctly, but i think what you are
proposing is similar to what Ecore_List do, you keep track of the last
accessed node on one side and the last added/deleted node in the
other, even so IMHO the ecore_list API is not clear enough on what
functions update one or the other, and yes, this is possible, i did an
ecore_list wrapper using evas_list (i gave the reference for it on
another ml thread), and i think is good to have to speed up node
retrieve.
It's a bit different as it's an external structure, you can create as
much iterators or accessors as you want and use them in different
ways. What you CAN'T is modify the iterated/accessed object while it's
in use.
Similar to eina_iterator:
typedef struct eina_accessor {
int (*get)(eina_acessor_t *accessor, int index, void **data);
void (*free)(eina_accessor_t *accessor);
} eina_acessor_t;
When you want to create an accessor for Evas_List, you extend this
with some members:
struct eina_accessor_evas_list {
eina_accessor_t base;
const Evas_List *head;
struct {
const Evas_List *node;
int index;
} last_used;
}
when you access some index you calculate: am I near to 'index' going
from head (0), tail (evas_list_count()) or last_used index? Than you
calculate the direction and how many items you have to go.
You can build ecore api on top of this if you link to the accessor to
the model and every time model change, you fix the accessor to avoid
invalid references.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
Re: [E-devel] Community Building
On 2-Aug-08, at 2:18 AM, Gustavo Sverzut Barbieri wrote: On Sat, Aug 2, 2008 at 2:53 AM, dan sinclair [EMAIL PROTECTED] wrote: On 2-Aug-08, at 1:40 AM, Nick Hughart wrote: Vincent Torri wrote: On Sat, 2 Aug 2008, dan sinclair wrote: I'd say you're so eager to release something you're not thinking about the impression it gives. Changing things in a pre-1.0 is fine and expected. Releasing a 1.0 and then breaking it or making major changes a few months down the road is a very bad impression. I don't think that if we release a 1.0 soon, the next the next major release wiil be out in a few month. It will follow the same release process (some years) The problem is, the two issues that have come up that are being considered as blockers are things that may affect how many people want to use the EFL. So waiting 3-4 years after a disappointing release may just push people away. We should at least try to address the shortcomings now or people will either have to wait years for the new release or get a release so soon that they have to readjust everything. Either way, I'm sure they won't be happy. It all comes down to when you're doing the 2.0 release. If you do a 2.0 release in a few months it looks like we just rushed a 1.0 out the door to say we had a 1.0. Major releases should last a few _years_. If we're seriously considering ripping out Embryo in a few _months_ that's a pretty good sign it isn't ready to be released yet. If we know we're going to rip out Embryo and we push out Edje with Embryo scripting just to remove it in the next release it isn't going to make people happy. They'll have to port all their themes to the new scripting language. We're better to wait until we have a foundation we want to work from to get there. As I said to mekius, this will lead to never releasing, as we have now. If we have basically 3 top components: ecore, evas and edje and 2 of them (evas and edje) are full of potential and ideas, we'll never release anything because they'll never be ready and all the other packages that serve as base for them will not be released because they might not be needed when we change something. If we already know we're going to rip out a major subsystem it isn't time to release. Sure we can draw a line in the sand but it's better to draw the line where it makes sense. After the lua change. Not an arbitrary date for the sake of a release. dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On 2-Aug-08, at 2:42 AM, Carsten Haitzler (The Rasterman) wrote: On Sat, 2 Aug 2008 00:12:00 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Fri, Aug 1, 2008 at 7:46 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: oh of course. details! :) we can dot the i's and cross the t's soon enough. :) Unfortunately, this really needs to be done sooner than later. Without a license listed, we now need to get the permission of everyone that has contributed to it in order to re-license it. At least in the US (and I believe all of North America), no license means all rights reserved. as such isn't eina copying code from ecore/evas in order just to be implemented.. in which case... it is bsd (ie same license s ecore evas)? I don't think so. The license has a sublicense clause which, I think, means this is sublicensed with a 'all rights reserved' license. But then, I'm not a lawyer. I also don't want to jump on a bandwagon when I can't see where it's going. dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On 2-Aug-08, at 2:12 AM, Gustavo Sverzut Barbieri wrote: As I said, it already happened, don't hide under the we did not official 1.0 yet. No, it hasn't. If a company jumped on _alpha_ level software and started to develop around it they have to expect that changes are coming. Hence the alpha marking. We have never said the EFL is 1.0 up to this point. After we say it's 1.0 then yes, we have. But until then, this is a red herring. dan * red herring : something that is used to divert attention from the basic issue - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
Sebastian Dransfeld wrote: Nick Hughart wrote: dan sinclair wrote: On 2-Aug-08, at 1:40 AM, Nick Hughart wrote: Vincent Torri wrote: On Sat, 2 Aug 2008, dan sinclair wrote: I'd say you're so eager to release something you're not thinking about the impression it gives. Changing things in a pre-1.0 is fine and expected. Releasing a 1.0 and then breaking it or making major changes a few months down the road is a very bad impression. I don't think that if we release a 1.0 soon, the next the next major release wiil be out in a few month. It will follow the same release process (some years) The problem is, the two issues that have come up that are being considered as blockers are things that may affect how many people want to use the EFL. So waiting 3-4 years after a disappointing release may just push people away. We should at least try to address the shortcomings now or people will either have to wait years for the new release or get a release so soon that they have to readjust everything. Either way, I'm sure they won't be happy. It all comes down to when you're doing the 2.0 release. If you do a 2.0 release in a few months it looks like we just rushed a 1.0 out the door to say we had a 1.0. Major releases should last a few _years_. If we're seriously considering ripping out Embryo in a few _months_ that's a pretty good sign it isn't ready to be released yet. If we know we're going to rip out Embryo and we push out Edje with Embryo scripting just to remove it in the next release it isn't going to make people happy. They'll have to port all their themes to the new scripting language. We're better to wait until we have a foundation we want to work from to get there. You're releasing something before it should be released just to give the impression of a 1.0 for something that isn't 1.0. That leaves a worse taste as a developer then holding off the release until we're pretty sure what we've got will be it for the long haul. Explain why you think that current efl can't be considered as 1.0, please I never said the EFL in general wasn't ready for a 1.0. I'm specifically talking about Embryo as we don't know it's future. Ecore could probably be released once ecore_data is removed and we could do a point release the splits it into separate packages. Evas, I don't follow the Evas discussions so I have no idea. Edje needs the Embryo question asked. Efreet could probably go as the API is stable and we fixup any caching issues in a point release. e_dbus, no idea don't use it. Eet is already 1.0. What this all comes down to, and what the major blocker for most of this is, is Eina. Pretty much everything in CVS will end up depending on it. Let's push to get that as a 1.0 first. It seems that you have the same opinion than raster has about enlightenment, that is enlightenment will be 1.0 when there will be no more improvements he will be able to think about. No, I don't think that. I just think picking an arbitrary library is silly. We should think about what needs to get released and what has a stable API. What the problem with doing releases ? It helps packagers and users, people that use commercially the efl are satisfied because they know they have a solid base set of libs they can work with. There is nothing wrong with doing releases. I just don't see the point of releasing for the sake of releasing when we already know we're going to break the API. If you want to push something out the door, what about Efreet, or getting Eina done then doing Ecore. We don't have to start with an Embryo release. We don't have to push Embryo until we're ready to push Edje. Pushing Edje has to wait until we push Evas (which also has to wait for Eina). Heh, I would like to release all the efl as 1.0 (maybe after the eina move). Then, in a few years push the 2.0 release (for e18 ?). There are *lots* of stuff to do for a 2.0 release for evas and edje (i don't really know for ecore). About evas, you see the discussion between mainly Jose, Jorge and raster. About edje Gustavo told me that raster has huge plans about it. So why not writing edje 2 with these plans and with another scripting language than embryo when thee plans will be known a little bit more ? I've made a similiar argument for EDJE, push it as is with embryo and don't expect the flash/silverlight/etc crowd to jump on board right away and make user interfaces. Use EDJE for what it can do now and then in the future we can do a 2.0 release that adds the extra stuff. But by that time, people may have throughly invested in embryo and it may cost them quite a bit to change all that. About efreet, I agree too that it should be out after the
Re: [E-devel] Community Building
Nick Hughart wrote: Sebastian Dransfeld wrote: There is an icon cache with 100 icons. Latest used icons are prepended to the list. If an icon is in the cache, the cache does help. So for a scenario where a user only triggers efreet_icon through f.ex. a small favorite menu in e17, the cache is good. But if the modules menu is accessed it will blow the cache. So the cache should have a method to weigh which icons are most used. For one, why is it limited to 100 icons? Just a random number, as I have not done any tests on how much memory the icon cache uses, and I have no idea how many icons there are in use in a typical e17 session. I can see this overflowing fairly easy in E as it is now and this doesn't even include mime icons. With my tests I haven't seen the cache come into play at all, the time between searching for icons once and searching for that same set again results in nearly identical times. This is when searching for mimetype icons and unless the cache doesn't cover the searching this does I'd have to disagree that it has any useful effect. There aren't that many mimetypes in /usr/lib either so I don't think I'm exceeding the 100 icon limit in this case and actually this case should shine with this caching system. I have only checked with limiting the icon list in one of the efreet tests. Could you send me your test code? Limiting the icon list in ef_icon_theme.c to 100 icons, and duplicating the icon search code: (first drop disk cache: echo 3 /proc/sys/vm/drop_caches) First run : 0.390257 Second run: 0.032595 Sebastian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
Sebastian Dransfeld wrote: Nick Hughart wrote: Sebastian Dransfeld wrote: There is an icon cache with 100 icons. Latest used icons are prepended to the list. If an icon is in the cache, the cache does help. So for a scenario where a user only triggers efreet_icon through f.ex. a small favorite menu in e17, the cache is good. But if the modules menu is accessed it will blow the cache. So the cache should have a method to weigh which icons are most used. For one, why is it limited to 100 icons? Just a random number, as I have not done any tests on how much memory the icon cache uses, and I have no idea how many icons there are in use in a typical e17 session. I can see this overflowing fairly easy in E as it is now and this doesn't even include mime icons. With my tests I haven't seen the cache come into play at all, the time between searching for icons once and searching for that same set again results in nearly identical times. This is when searching for mimetype icons and unless the cache doesn't cover the searching this does I'd have to disagree that it has any useful effect. There aren't that many mimetypes in /usr/lib either so I don't think I'm exceeding the 100 icon limit in this case and actually this case should shine with this caching system. I have only checked with limiting the icon list in one of the efreet tests. Could you send me your test code? Limiting the icon list in ef_icon_theme.c to 100 icons, and duplicating the icon search code: (first drop disk cache: echo 3 /proc/sys/vm/drop_caches) First run : 0.390257 Second run: 0.032595 I put my test code here: http://www.mekius.net/files/misc/efreet_mime_test.c I could be doing something wrong or maybe there is an issue with my mime code, but I seem to recall the caching coming into play with the old cache, but you were working on it around the time I was finishing the efreet_mime_icon stuff iirc. Let me know if you get any different results, the program should be run as follows when compiled: efreet_mime_test directory to read from This will read each file in the dir, get it's mimetype and mimetype icon. /usr/lib is what I usually test with due to it's number of similar mimetypes and sheer size. Sebastian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] [website] cms?
We've tried this about 3 times. Someone comes along and says if we have a CMS non-technical people will write articles. We implement a CMS. No-one writes articles. We drop the CMS. If you want to write news releases put them on blogs. Or write a news blurb for the front page. If longer articles are put into the wiki other people can fix the formatting and the wiki syntax later. dan On 2-Aug-08, at 1:36 PM, Sthithaprajna Garapaty wrote: All good points, and I definitely agree that having a flat access structure is very nice. Perhaps we can keep it even if we use a CMS? Worth looking into. But, here are some arguments FOR a CMS: 1. We except articles to be written not by devs, but by users. I.E. People who are not technical enough to fiddle with CVS, or even HTML. They are good at writing and they can use a word processor. We shouldn't create a barrier of entry for these people. 2. It automatically provides all the things a website needs. Many of which are lacking in the current site. For example: Search, RSS feeds for posts, flexible templates styles, wysiwyg editors previews, taxonomy. Additionally a few CMSes also provide modules for integrating our other systems (wiki, bugs, etc) into the site. 3. Module support. Most big CMSes have support for modules. This means, they have a large library of 3rd party modules already, and its relatively easy to whip up our own. This means we can integrate all our other systems into the main e.org website. We could put the latest wiki articles on the front page, or the highest rated themes from exchange, or the latest CVS commits. Of course, we could write all of these things ourselves and stick 'em into CVS, but having a nice module api definitely helps speed up development. And some of these modules already exist. As far as the wiki being the place for articles, it definitely is the place for how-tos and tutorials, but its no place for news articles, articles on new features (wikis have a very poor sense of time) and articles that just show off EFL E. On Sat, Aug 2, 2008 at 2:47 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 2 Aug 2008 00:18:23 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: i agree here. i like our fairly flat (and lax) access structure. if we trust you to go writing bits of e.org's website - we trust you to write code - if that is your skill, or to just know to keep your hands off what you aren't good at. people make mistakes and if someone who was given access in order to do www goes and starts screwing with code so it breaks - a few reprimands on the mailing lists should cure that really fast, and if it doesn't - access to cvs can be removed (and will be) as if we can't trust them - why keep access to www? i like our own and flat trust structure. it's simple. it works as we are not a massive organisation. it allows or fluid movement and help wherever it is needed quickly. it shows we have faith in our fellow humans :) On Fri, Aug 1, 2008 at 5:27 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: so eventually went back to an old original method. www lives in cvs - u want to work on it, u get cvs access. committing means it auto- updates. if u need to test the php locally setting up a local apache and mod- php, allow symlinks outside of the www doc dir to point to your homedir's cvs checkout of the www site, worsk just fine. it's simple and works. the php is also very simple. the main www site is meant to be simple and relatively static - the wiki, and other sites (trac, bugzilla etc.) are where the dynamic stuff happens... There is another advantage to keeping the site in CVS: you avoid segmenting the community into artificial sub-communities, or trying to place technical barriers around social structures. There is a flat hierarchy of trust, either you've earned it enough to get access or you haven't. There is no temptation to give people access to the website since it's only the website, and anyone with CVS access should know how interact within the project. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ 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)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your
Re: [E-devel] Community Building
If we already know we're going to rip out a major subsystem it isn't time to release. Sure we can draw a line in the sand but it's better to draw the line where it makes sense. After the lua change. Not an arbitrary date for the sake of a release. Again, you are doing the assumption that the next major version will be out shortly. That is not obvious at all. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] [website] cms?
On Sat, Aug 2, 2008 at 8:58 PM, dan sinclair [EMAIL PROTECTED] wrote: We've tried this about 3 times. Someone comes along and says if we have a CMS non-technical people will write articles. We implement a CMS. No-one writes articles. We drop the CMS. If you want to write news releases put them on blogs. Or write a news blurb for the front page. If longer articles are put into the wiki other people can fix the formatting and the wiki syntax later. dan Indeed. A CMS is not a solution for the lack of content. I've started the project's blog now and any articles, reviews, etc are more than welcome. Also, for documentation and HOWTOs the wiki is by far more appropriate. -- Luchezar P. Petkov http://luchko.net - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] [website] cms?
While drunk at the moment (yet again) i think i would contribute to any user controlled content as would a lot of people. (while not drunk of course.) People semi-excited about the project would like to show their support too. And thats the great thing about OSS I believe that the community gets a say no matter what they do FOR the community! Maybe its a dream, but its what i hope for. Toma. On 8/3/08, dan sinclair [EMAIL PROTECTED] wrote: We've tried this about 3 times. Someone comes along and says if we have a CMS non-technical people will write articles. We implement a CMS. No-one writes articles. We drop the CMS. If you want to write news releases put them on blogs. Or write a news blurb for the front page. If longer articles are put into the wiki other people can fix the formatting and the wiki syntax later. dan On 2-Aug-08, at 1:36 PM, Sthithaprajna Garapaty wrote: All good points, and I definitely agree that having a flat access structure is very nice. Perhaps we can keep it even if we use a CMS? Worth looking into. But, here are some arguments FOR a CMS: 1. We except articles to be written not by devs, but by users. I.E. People who are not technical enough to fiddle with CVS, or even HTML. They are good at writing and they can use a word processor. We shouldn't create a barrier of entry for these people. 2. It automatically provides all the things a website needs. Many of which are lacking in the current site. For example: Search, RSS feeds for posts, flexible templates styles, wysiwyg editors previews, taxonomy. Additionally a few CMSes also provide modules for integrating our other systems (wiki, bugs, etc) into the site. 3. Module support. Most big CMSes have support for modules. This means, they have a large library of 3rd party modules already, and its relatively easy to whip up our own. This means we can integrate all our other systems into the main e.org website. We could put the latest wiki articles on the front page, or the highest rated themes from exchange, or the latest CVS commits. Of course, we could write all of these things ourselves and stick 'em into CVS, but having a nice module api definitely helps speed up development. And some of these modules already exist. As far as the wiki being the place for articles, it definitely is the place for how-tos and tutorials, but its no place for news articles, articles on new features (wikis have a very poor sense of time) and articles that just show off EFL E. On Sat, Aug 2, 2008 at 2:47 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 2 Aug 2008 00:18:23 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: i agree here. i like our fairly flat (and lax) access structure. if we trust you to go writing bits of e.org's website - we trust you to write code - if that is your skill, or to just know to keep your hands off what you aren't good at. people make mistakes and if someone who was given access in order to do www goes and starts screwing with code so it breaks - a few reprimands on the mailing lists should cure that really fast, and if it doesn't - access to cvs can be removed (and will be) as if we can't trust them - why keep access to www? i like our own and flat trust structure. it's simple. it works as we are not a massive organisation. it allows or fluid movement and help wherever it is needed quickly. it shows we have faith in our fellow humans :) On Fri, Aug 1, 2008 at 5:27 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: so eventually went back to an old original method. www lives in cvs - u want to work on it, u get cvs access. committing means it auto- updates. if u need to test the php locally setting up a local apache and mod- php, allow symlinks outside of the www doc dir to point to your homedir's cvs checkout of the www site, worsk just fine. it's simple and works. the php is also very simple. the main www site is meant to be simple and relatively static - the wiki, and other sites (trac, bugzilla etc.) are where the dynamic stuff happens... There is another advantage to keeping the site in CVS: you avoid segmenting the community into artificial sub-communities, or trying to place technical barriers around social structures. There is a flat hierarchy of trust, either you've earned it enough to get access or you haven't. There is no temptation to give people access to the website since it's only the website, and anyone with CVS access should know how interact within the project. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___
Re: [E-devel] Community Building
On Sat, 2 Aug 2008 13:03:41 +0200 Andreas Volz [EMAIL PROTECTED] babbled: I vote to use LUA for scripting too. I've embedded it into several commercial products in the past. It was each time a really good choose. It's easy to understand, small and I think most important has a really big community. i respect the idea of looking at javascript for example - but it's quite a sring of reports of using lua - in just the way it'd be used in edje that make me go this looks just like the right thing. the question is ... do we keep embryo? do we keep it and mark it as here for compatiblity, BUT will be removed in a future release, so please port your scripts to lua. thanks and then wait a while, and then remove... or ... can we remove now and just cause the pain? how much is embryo really used? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] [website] cms?
I'm not saying having a CMS will suddenly bring people to write. That's a separate problem. I think it will not BLOCK people from writing. There's a difference. There are various avenues we can pursue to attract writers. Bounties, request for articles on the front page, etc can easily attract writers. Also, we need to have a strict no drinking and writing policy. On Sat, Aug 2, 2008 at 2:26 PM, Toma [EMAIL PROTECTED] wrote: While drunk at the moment (yet again) i think i would contribute to any user controlled content as would a lot of people. (while not drunk of course.) People semi-excited about the project would like to show their support too. And thats the great thing about OSS I believe that the community gets a say no matter what they do FOR the community! Maybe its a dream, but its what i hope for. Toma. On 8/3/08, dan sinclair [EMAIL PROTECTED] wrote: We've tried this about 3 times. Someone comes along and says if we have a CMS non-technical people will write articles. We implement a CMS. No-one writes articles. We drop the CMS. If you want to write news releases put them on blogs. Or write a news blurb for the front page. If longer articles are put into the wiki other people can fix the formatting and the wiki syntax later. dan On 2-Aug-08, at 1:36 PM, Sthithaprajna Garapaty wrote: All good points, and I definitely agree that having a flat access structure is very nice. Perhaps we can keep it even if we use a CMS? Worth looking into. But, here are some arguments FOR a CMS: 1. We except articles to be written not by devs, but by users. I.E. People who are not technical enough to fiddle with CVS, or even HTML. They are good at writing and they can use a word processor. We shouldn't create a barrier of entry for these people. 2. It automatically provides all the things a website needs. Many of which are lacking in the current site. For example: Search, RSS feeds for posts, flexible templates styles, wysiwyg editors previews, taxonomy. Additionally a few CMSes also provide modules for integrating our other systems (wiki, bugs, etc) into the site. 3. Module support. Most big CMSes have support for modules. This means, they have a large library of 3rd party modules already, and its relatively easy to whip up our own. This means we can integrate all our other systems into the main e.org website. We could put the latest wiki articles on the front page, or the highest rated themes from exchange, or the latest CVS commits. Of course, we could write all of these things ourselves and stick 'em into CVS, but having a nice module api definitely helps speed up development. And some of these modules already exist. As far as the wiki being the place for articles, it definitely is the place for how-tos and tutorials, but its no place for news articles, articles on new features (wikis have a very poor sense of time) and articles that just show off EFL E. On Sat, Aug 2, 2008 at 2:47 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 2 Aug 2008 00:18:23 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: i agree here. i like our fairly flat (and lax) access structure. if we trust you to go writing bits of e.org's website - we trust you to write code - if that is your skill, or to just know to keep your hands off what you aren't good at. people make mistakes and if someone who was given access in order to do www goes and starts screwing with code so it breaks - a few reprimands on the mailing lists should cure that really fast, and if it doesn't - access to cvs can be removed (and will be) as if we can't trust them - why keep access to www? i like our own and flat trust structure. it's simple. it works as we are not a massive organisation. it allows or fluid movement and help wherever it is needed quickly. it shows we have faith in our fellow humans :) On Fri, Aug 1, 2008 at 5:27 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: so eventually went back to an old original method. www lives in cvs - u want to work on it, u get cvs access. committing means it auto- updates. if u need to test the php locally setting up a local apache and mod- php, allow symlinks outside of the www doc dir to point to your homedir's cvs checkout of the www site, worsk just fine. it's simple and works. the php is also very simple. the main www site is meant to be simple and relatively static - the wiki, and other sites (trac, bugzilla etc.) are where the dynamic stuff happens... There is another advantage to keeping the site in CVS: you avoid segmenting the community into artificial sub-communities, or trying to place technical barriers around social structures. There is a flat hierarchy of trust, either you've earned it enough to get access or you haven't. There is no temptation to give people access to the website since it's only the website, and anyone with CVS access should know how interact
Re: [E-devel] Community Building
On Sun, 3 Aug 2008, Carsten Haitzler (The Rasterman) wrote: On Sat, 2 Aug 2008 13:03:41 +0200 Andreas Volz [EMAIL PROTECTED] babbled: I vote to use LUA for scripting too. I've embedded it into several commercial products in the past. It was each time a really good choose. It's easy to understand, small and I think most important has a really big community. i respect the idea of looking at javascript for example - but it's quite a sring of reports of using lua - in just the way it'd be used in edje that make me go this looks just like the right thing. the question is ... do we keep embryo? do we keep it and mark it as here for compatiblity, BUT will be removed in a future release, so please port your scripts to lua. thanks and then wait a while, and then remove... or ... can we remove now and just cause the pain? how much is embryo really used? First ask the people who use embryo in their commercial product. Indt, Cedric, raoul, Gustavo. And especially, ask the designer who helps raoul for calaos. I really think that his opinion is a good one. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] [website] cms?
On Sun, 3 Aug 2008 02:26:57 +0800 Toma [EMAIL PROTECTED] babbled: While drunk at the moment (yet again) i think i would contribute to any user controlled content as would a lot of people. (while not drunk of course.) People semi-excited about the project would like to show their support too. And thats the great thing about OSS I believe that the community gets a say no matter what they do FOR the community! Maybe its a dream, but its what i hope for. Toma. and we can happily add cvs access for those wanting to work on the site! :) On 8/3/08, dan sinclair [EMAIL PROTECTED] wrote: We've tried this about 3 times. Someone comes along and says if we have a CMS non-technical people will write articles. We implement a CMS. No-one writes articles. We drop the CMS. If you want to write news releases put them on blogs. Or write a news blurb for the front page. If longer articles are put into the wiki other people can fix the formatting and the wiki syntax later. dan On 2-Aug-08, at 1:36 PM, Sthithaprajna Garapaty wrote: All good points, and I definitely agree that having a flat access structure is very nice. Perhaps we can keep it even if we use a CMS? Worth looking into. But, here are some arguments FOR a CMS: 1. We except articles to be written not by devs, but by users. I.E. People who are not technical enough to fiddle with CVS, or even HTML. They are good at writing and they can use a word processor. We shouldn't create a barrier of entry for these people. 2. It automatically provides all the things a website needs. Many of which are lacking in the current site. For example: Search, RSS feeds for posts, flexible templates styles, wysiwyg editors previews, taxonomy. Additionally a few CMSes also provide modules for integrating our other systems (wiki, bugs, etc) into the site. 3. Module support. Most big CMSes have support for modules. This means, they have a large library of 3rd party modules already, and its relatively easy to whip up our own. This means we can integrate all our other systems into the main e.org website. We could put the latest wiki articles on the front page, or the highest rated themes from exchange, or the latest CVS commits. Of course, we could write all of these things ourselves and stick 'em into CVS, but having a nice module api definitely helps speed up development. And some of these modules already exist. As far as the wiki being the place for articles, it definitely is the place for how-tos and tutorials, but its no place for news articles, articles on new features (wikis have a very poor sense of time) and articles that just show off EFL E. On Sat, Aug 2, 2008 at 2:47 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 2 Aug 2008 00:18:23 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: i agree here. i like our fairly flat (and lax) access structure. if we trust you to go writing bits of e.org's website - we trust you to write code - if that is your skill, or to just know to keep your hands off what you aren't good at. people make mistakes and if someone who was given access in order to do www goes and starts screwing with code so it breaks - a few reprimands on the mailing lists should cure that really fast, and if it doesn't - access to cvs can be removed (and will be) as if we can't trust them - why keep access to www? i like our own and flat trust structure. it's simple. it works as we are not a massive organisation. it allows or fluid movement and help wherever it is needed quickly. it shows we have faith in our fellow humans :) On Fri, Aug 1, 2008 at 5:27 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: so eventually went back to an old original method. www lives in cvs - u want to work on it, u get cvs access. committing means it auto- updates. if u need to test the php locally setting up a local apache and mod- php, allow symlinks outside of the www doc dir to point to your homedir's cvs checkout of the www site, worsk just fine. it's simple and works. the php is also very simple. the main www site is meant to be simple and relatively static - the wiki, and other sites (trac, bugzilla etc.) are where the dynamic stuff happens... There is another advantage to keeping the site in CVS: you avoid segmenting the community into artificial sub-communities, or trying to place technical barriers around social structures. There is a flat hierarchy of trust, either you've earned it enough to get access or you haven't. There is no temptation to give people access to the website since it's only the website, and anyone with CVS access should know how interact within the project. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the
Re: [E-devel] [e-users] [website] cms?
On 2-Aug-08, at 2:55 PM, Sthithaprajna Garapaty wrote: I'm not saying having a CMS will suddenly bring people to write. That's a separate problem. I think it will not BLOCK people from writing. There's a difference. There are various avenues we can pursue to attract writers. Bounties, request for articles on the front page, etc can easily attract writers. Also, we need to have a strict no drinking and writing policy. Nothing we have now blocks people from writing (and this is coming from the guy that wrote a _lot_ of documentation for Ewl and the EFL). Use your blog. Use the wiki. Everything is available. If people wanted to write they'd be doing it already. If we have to pay them, then I'd say they're just in it for the money. Probably not the type of community we want to foster. dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sat, 2 Aug 2008 20:58:05 +0200 (CEST) Vincent Torri [EMAIL PROTECTED] babbled: On Sun, 3 Aug 2008, Carsten Haitzler (The Rasterman) wrote: On Sat, 2 Aug 2008 13:03:41 +0200 Andreas Volz [EMAIL PROTECTED] babbled: I vote to use LUA for scripting too. I've embedded it into several commercial products in the past. It was each time a really good choose. It's easy to understand, small and I think most important has a really big community. i respect the idea of looking at javascript for example - but it's quite a sring of reports of using lua - in just the way it'd be used in edje that make me go this looks just like the right thing. the question is ... do we keep embryo? do we keep it and mark it as here for compatiblity, BUT will be removed in a future release, so please port your scripts to lua. thanks and then wait a while, and then remove... or ... can we remove now and just cause the pain? how much is embryo really used? First ask the people who use embryo in their commercial product. Indt, Cedric, raoul, Gustavo. And especially, ask the designer who helps raoul for calaos. I really think that his opinion is a good one. indeed. i am asking! :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On 2-Aug-08, at 2:58 PM, Vincent Torri wrote: On Sun, 3 Aug 2008, Carsten Haitzler (The Rasterman) wrote: On Sat, 2 Aug 2008 13:03:41 +0200 Andreas Volz [EMAIL PROTECTED] babbled: I vote to use LUA for scripting too. I've embedded it into several commercial products in the past. It was each time a really good choose. It's easy to understand, small and I think most important has a really big community. i respect the idea of looking at javascript for example - but it's quite a sring of reports of using lua - in just the way it'd be used in edje that make me go this looks just like the right thing. the question is ... do we keep embryo? do we keep it and mark it as here for compatiblity, BUT will be removed in a future release, so please port your scripts to lua. thanks and then wait a while, and then remove... or ... can we remove now and just cause the pain? how much is embryo really used? First ask the people who use embryo in their commercial product. Indt, Cedric, raoul, Gustavo. And especially, ask the designer who helps raoul for calaos. I really think that his opinion is a good one. I'd say ask them what they need from a scripting language. Don't let them dictate our code choices to us (I'm not saying ignore they're opinion, it just isn't the last word). If we need to rip out Embryo and we're going to rip out Embryo, do it _before_ release. Putting it in and letting people get used to it to just rip it out later will just foster bad blood. dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
Am Sun, 3 Aug 2008 04:32:01 +1000 schrieb Carsten Haitzler (The Rasterman): On Sat, 2 Aug 2008 13:03:41 +0200 Andreas Volz [EMAIL PROTECTED] babbled: I vote to use LUA for scripting too. I've embedded it into several commercial products in the past. It was each time a really good choose. It's easy to understand, small and I think most important has a really big community. i respect the idea of looking at javascript for example - but it's quite a sring of reports of using lua - in just the way it'd be used in edje that make me go this looks just like the right thing. the question is ... do we keep embryo? do we keep it and mark it as here for compatiblity, BUT will be removed in a future release, so please port your scripts to lua. thanks and then wait a while, and then remove... or ... can we remove now and just cause the pain? how much is embryo really used? If the new scripting language is lUA it should be replaced before releasing edje. My proposal is to create a new branch for LUA integration and then define a fixed time frame for this task. If LUA is integrated in this time frame then we release it with LUA. If we see that it would take 10 times more as we estimated than we release with Embryo and release LUA for Edje 2.0. What do you think about that idea? All people would be happy with this solution. But I've no idea about a realistic time frame. It depends on how many people are contributing. For me I could say that until now I used two different LUA C++ bindings but not the C API. But maybe I could contribute in smaller parts. regards Andreas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sat, 2 Aug 2008, Andreas Volz wrote: If the new scripting language is lUA it should be replaced before releasing edje. My proposal is to create a new branch for LUA integration and then define a fixed time frame for this task. If LUA is integrated in this time frame then we release it with LUA. If we see that it would take 10 times more as we estimated than we release with Embryo and release LUA for Edje 2.0. What do you think about that idea? All people would be happy with this solution. the answer will be : no branch as we use cvs. the solution would be to switch to git on fdo servers (enlightenment and the efl have their place there). It will solve lots of things that would help us a lot for the releases process. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sat, 2 Aug 2008 22:09:27 +0200 (CEST) Vincent Torri [EMAIL PROTECTED]
babbled:
On Sat, 2 Aug 2008, Andreas Volz wrote:
If the new scripting language is lUA it should be replaced before
releasing edje.
My proposal is to create a new branch for LUA integration and then
define a fixed time frame for this task. If LUA is integrated in this
time frame then we release it with LUA. If we see that it would take 10
times more as we estimated than we release with Embryo and release LUA
for Edje 2.0.
What do you think about that idea? All people would be happy with this
solution.
the answer will be : no branch as we use cvs.
the solution would be to switch to git on fdo servers (enlightenment and
the efl have their place there). It will solve lots of things that would
help us a lot for the releases process.
why does everyone think we have to branch? wecan do this in-line in head and
have BOTH lua AND embryo available in the code - in head, while it is switched
over (and then at some point embryo removed). this was lua gets tested and used
- and nothing breaks, and then at some given day embryo is removed and we
change script {} to mean just lua (and during transition we can do what gustavo
said - use lua {} sections to play with it).
i actually was mostly thinking of Script only objects - ie they are entirely
defined by script and not layout. they can USE layout groups loaded from the
same file - just like c code can... or load other script only objects... this
script only thing can be done without branches, without changing scms's...
btw - i don't think git will help us much at all. been using it myself and it's
incredibly annoying, is horrid at merging conflicts (mergetool - when it fails
leaves u with an awful mess!). i am no fan of git. it has bitten me in the arse
already a few times. i much prefer svn but that's not the point. a SCMS
doesnt make this possible or not - we can do this all inline in HEAD with no
breaks or change of SCMS... removal of embryo is a matter of how much is it
really used and needed where it can't trivially be replaced with lua in the few
uses?. or is it used so much - we keep it, and just add lua anyway in addition
and if you want more powerful controls, you use lua, not embryo at the design
stage. :)
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sun, 2008-08-03 at 04:32 +1000, Carsten Haitzler wrote: On Sat, 2 Aug 2008 13:03:41 +0200 Andreas Volz [EMAIL PROTECTED] babbled: I vote to use LUA for scripting too. I've embedded it into several commercial products in the past. It was each time a really good choose. It's easy to understand, small and I think most important has a really big community. i respect the idea of looking at javascript for example - but it's quite a sring of reports of using lua - in just the way it'd be used in edje that make me go this looks just like the right thing. the question is ... do we keep embryo? do we keep it and mark it as here for compatiblity, BUT will be removed in a future release, so please port your scripts to lua. thanks and then wait a while, and then remove... or ... can we remove now and just cause the pain? how much is embryo really used? imho, it both lua and javascript are good choices for this. Though I haven't used lua personally, I only hear good things about it, and the syntax is very C-ish. As far as js is concerned, there's probably a lot more people familiar with it (including me) than lua. And js is not just a dom language. As far as integration is concerned, I know that lua is quite easy to integrate, thought I think that integrating JavascriptCore from webkit will not be too difficult either (judging by reports of integrating it in gtk). But couldn't we support more than one language (and thus also preserve embryo, if there are people that need it)? Something like how IE is able to use both js and vscript in html. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
As crazy as it might seem, id like to hear from mekius and devilhorns about how easy and useful embryo was to them in regards to them in various projects in cvs. As an e17 themer, it hasnt proven much use to me, but i consider myself further to the edje when it comes to embryo and edje talk! Toma On 8/3/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Sun, 2008-08-03 at 04:32 +1000, Carsten Haitzler wrote: On Sat, 2 Aug 2008 13:03:41 +0200 Andreas Volz [EMAIL PROTECTED] babbled: I vote to use LUA for scripting too. I've embedded it into several commercial products in the past. It was each time a really good choose. It's easy to understand, small and I think most important has a really big community. i respect the idea of looking at javascript for example - but it's quite a sring of reports of using lua - in just the way it'd be used in edje that make me go this looks just like the right thing. the question is ... do we keep embryo? do we keep it and mark it as here for compatiblity, BUT will be removed in a future release, so please port your scripts to lua. thanks and then wait a while, and then remove... or ... can we remove now and just cause the pain? how much is embryo really used? imho, it both lua and javascript are good choices for this. Though I haven't used lua personally, I only hear good things about it, and the syntax is very C-ish. As far as js is concerned, there's probably a lot more people familiar with it (including me) than lua. And js is not just a dom language. As far as integration is concerned, I know that lua is quite easy to integrate, thought I think that integrating JavascriptCore from webkit will not be too difficult either (judging by reports of integrating it in gtk). But couldn't we support more than one language (and thus also preserve embryo, if there are people that need it)? Something like how IE is able to use both js and vscript in html. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Sent from Gmail for mobile | mobile.google.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
Viktor Kojouharov wrote: imho, it both lua and javascript are good choices for this. Though I haven't used lua personally, I only hear good things about it, and the syntax is very C-ish. As far as js is concerned, there's probably a lot more people familiar with it (including me) than lua. And js is not just a dom language. As far as integration is concerned, I know that lua is quite easy to integrate, thought I think that integrating JavascriptCore from webkit will not be too difficult either (judging by reports of integrating it in gtk). I feel the same about lua and javascript. But nowadays lua seems to be much more easier to integrate than a javascript engine. Even if the later got recently a lot of improvements on this. But couldn't we support more than one language (and thus also preserve embryo, if there are people that need it)? Something like how IE is able to use both js and vscript in html. I don't think supporting (in the long run) several different scripting languages is a good thing. Compatibility problems will increase, and reading someone else theme's code will become even harder. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
Toma wrote: As crazy as it might seem, id like to hear from mekius and devilhorns about how easy and useful embryo was to them in regards to them in various projects in cvs. As an e17 themer, it hasnt proven much use to me, but i consider myself further to the edje when it comes to embryo and edje talk! Toma I don't use embryo in a commercial product, I'm not mekius nor devilhorns. But I do use embryo quite often when making edj. And unlike you I do feel limited currently with embryo. Dealing with generic parts inside an edc is a real pain. Imagine for example a bunch of squares aligned from a small one to a bigger one. You need to describe every one of them, which means a macro and a lot of numbers at best, whereas a simple function could do it. Sure it could be done in C, but doing so will restrict the theming possibility for other themers. But this can be solved with the script-only object in any language. Handling edje's parts/programs when using embryo calls can't be done dynamically. You need to know which part is to be used, and hardcode it's name. Again, this leads to macro voodoo. And finally the language itself is not that pleasant. Having a few things to ease strings manipulation, and anonymous function to shorten some timer call wouldn't hurt. I do like the idea to change for lua or js or whatever for this. But even so, there's quite a few themes which needs embryo. So in case of a change, I think the transition should be as gustavo and raster describe it. Samuel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sun, 2008-08-03 at 00:38 +0200, lok wrote: Toma wrote: As crazy as it might seem, id like to hear from mekius and devilhorns about how easy and useful embryo was to them in regards to them in various projects in cvs. As an e17 themer, it hasnt proven much use to me, but i consider myself further to the edje when it comes to embryo and edje talk! Toma I don't use embryo in a commercial product, I'm not mekius nor devilhorns. But I do use embryo quite often when making edj. And unlike you I do feel limited currently with embryo. Dealing with generic parts inside an edc is a real pain. Imagine for example a bunch of squares aligned from a small one to a bigger one. You need to describe every one of them, which means a macro and a lot of numbers at best, whereas a simple function could do it. Sure it could be done in C, but doing so will restrict the theming possibility for other themers. But this can be solved with the script-only object in any language. Handling edje's parts/programs when using embryo calls can't be done dynamically. You need to know which part is to be used, and hardcode it's name. Again, this leads to macro voodoo. And finally the language itself is not that pleasant. Having a few things to ease strings manipulation, and anonymous function to shorten some timer call wouldn't hurt. I do like the idea to change for lua or js or whatever for this. But even so, there's quite a few themes which needs embryo. So in case of a change, I think the transition should be as gustavo and raster describe it. Samuel That is a limitation of the exposed API, not embryo's problem specifically (unless the exposure is a problem for embryo in general). Although I've had a lot of trouble implementing some random dynamic animations in a theme, it was all due to the lack of convenient functions. The same problem might also persist with lua/javascript. However, I did find the embryo syntax rather strange and cumbersome. And that comes from someone who has no problem writing in perl. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sat, 2008-08-02 at 23:07 +0200, lok wrote: Viktor Kojouharov wrote: imho, it both lua and javascript are good choices for this. Though I haven't used lua personally, I only hear good things about it, and the syntax is very C-ish. As far as js is concerned, there's probably a lot more people familiar with it (including me) than lua. And js is not just a dom language. As far as integration is concerned, I know that lua is quite easy to integrate, thought I think that integrating JavascriptCore from webkit will not be too difficult either (judging by reports of integrating it in gtk). I feel the same about lua and javascript. But nowadays lua seems to be much more easier to integrate than a javascript engine. Even if the later got recently a lot of improvements on this. But couldn't we support more than one language (and thus also preserve embryo, if there are people that need it)? Something like how IE is able to use both js and vscript in html. I don't think supporting (in the long run) several different scripting languages is a good thing. Compatibility problems will increase, and reading someone else theme's code will become even harder. I disagree. 'Compatibility problems' are non-existent, since they will all interact with edje parts, not with one another. And reading someone's code will always be harder if you don't know the language which is used. That holds true now, if you don't know embryo, and will hold true in the future, regardless of what language(s) we pick. However, it will be easier to write a theme, since the likelihood of knowing a supported language will increase. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
Viktor Kojouharov wrote: On Sat, 2008-08-02 at 23:07 +0200, lok wrote: Viktor Kojouharov wrote: imho, it both lua and javascript are good choices for this. Though I haven't used lua personally, I only hear good things about it, and the syntax is very C-ish. As far as js is concerned, there's probably a lot more people familiar with it (including me) than lua. And js is not just a dom language. As far as integration is concerned, I know that lua is quite easy to integrate, thought I think that integrating JavascriptCore from webkit will not be too difficult either (judging by reports of integrating it in gtk). I feel the same about lua and javascript. But nowadays lua seems to be much more easier to integrate than a javascript engine. Even if the later got recently a lot of improvements on this. But couldn't we support more than one language (and thus also preserve embryo, if there are people that need it)? Something like how IE is able to use both js and vscript in html. I don't think supporting (in the long run) several different scripting languages is a good thing. Compatibility problems will increase, and reading someone else theme's code will become even harder. I disagree. 'Compatibility problems' are non-existent, since they will all interact with edje parts, not with one another. And reading someone's code will always be harder if you don't know the language which is used. That holds true now, if you don't know embryo, and will hold true in the future, regardless of what language(s) we pick. However, it will be easier to write a theme, since the likelihood of knowing a supported language will increase. What I had in mind for the compatibility issues, is if you make it possible to build separately different script engines. And you didn't built all of them. You can have a theme with a dependency problem. If the build can only be done with all script engines, then obviously it will be heavier and need more external deps. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Eina
Hi all, as you all (most) know, eina has hit proto cvs. I think several things have to be explained, references to eina's license, code and so have appeared on different threads and honestly following them all is very complicated and is also hard to actually decide something, so it might be good if at some moment, someone can make a summary of several opinions and just do a poll and decide on it. Anyway, here is my summary: Objective: Eina's original objective was to settle down the long-time discussion about multiple data types, mainly ecore's and evas', it was an attempt that, from what i've seen, several developers have agreed and have a good will on this library; even the ecore's data types supporter (eina's is currently based around evas data types). It has several subsystems in a very similar way to what ecore has, but the main reason to not place ecore on the bottom of the software dependency stack was because not every library built around our data types wants to be loopized with ecore's main loop implementation, but be some kind of agnostic to ecore, so gtk / qt / whatever can use this libraries an fit their own loop manager on top of this low level library. Evas is an example of such a thing (there are others), and no, ecore-evas current double dependency is not the main problem eina wants to solve, not even the original problem it wanted to solve. If you place the efl stack, eina will be at the bottom, ecore on top of it and so other libraries/apps that *need* some kind of main loop handling, it can be summarized as pull approach libraries you pull the state from it, instead of evas (and others libraries) where you push the state (evas_render). License As most of the code on efl-research project (and most of *my* code) it does not have COPYING file, it was left out on purpose, basically to be able to discuss this license issue with e developers. We all have already argued about licensing and there are several respectable and contrary point of views. I, as the original author of this library, even if some of the code was taken from evas or ecore, wanted to license the library as LGPL; but as i have already stated, this new license has several considerations, *please* don't start a license arguments, the other thread is for that, this one is to decide: 1. Relicensing eina as LGPL is possible and *does not* go against Evas or Ecore license, BSD allows that as long as the third (author) clause is respected and so it will be (in case eina's license finally gets set to LGPL) 2. What will be the reaction from developers that want BSD license? from what i've deduced on IRC and ML, several of this developers *won't* contribute to this library if it is not BSD, (please those developers that think that this is point is for them, confirm or deny this). In my opinion the current state of e developers is too small to actually divide it based on the license they prefer; and of course that argument imposes the license the library can be. So, the main question on this point is: if it is LGPL are you going to contribute to it? and, if it is LGPL are you going to *link against this library? ps: i would like to discuss several eina's subsytems, but looks like the license has to be solved first, so let's get it done, so we can focus on the code. Best regards, turran - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sat, Aug 2, 2008 at 5:33 PM, The Rasterman Carsten Haitzler
[EMAIL PROTECTED] wrote:
On Sat, 2 Aug 2008 22:09:27 +0200 (CEST) Vincent Torri [EMAIL PROTECTED]
babbled:
On Sat, 2 Aug 2008, Andreas Volz wrote:
If the new scripting language is lUA it should be replaced before
releasing edje.
My proposal is to create a new branch for LUA integration and then
define a fixed time frame for this task. If LUA is integrated in this
time frame then we release it with LUA. If we see that it would take 10
times more as we estimated than we release with Embryo and release LUA
for Edje 2.0.
What do you think about that idea? All people would be happy with this
solution.
the answer will be : no branch as we use cvs.
the solution would be to switch to git on fdo servers (enlightenment and
the efl have their place there). It will solve lots of things that would
help us a lot for the releases process.
why does everyone think we have to branch? wecan do this in-line in head and
have BOTH lua AND embryo available in the code - in head, while it is switched
over (and then at some point embryo removed).
Why branches? Because if it goes wrong or unfinished we can just
forget about it, maybe delete or just let it rot until someone revives
it.
Doing this in head will just bring problems to everyone, I dislike it.
These major changes should go into branches until they're almost
ready. I did that to tilebuf optimizations, remember? Cedric did that
too, and it worked find, although we still had some problems, they
were almost none compared to the whole development.
Also, as Vincent said, I really think this idea will not happen so
soon, nobody seems to have time to work on it, it's not that important
and it will have to be finished, unlike EFM and other
started-but-not-finished things. That's yet another reason to make me
think it's the wrong thing to do now, or soon.
this was lua gets tested and used
- and nothing breaks, and then at some given day embryo is removed and we
change script {} to mean just lua (and during transition we can do what
gustavo
said - use lua {} sections to play with it).
this is a good reason to get into HEAD, but you can keep it into a
branch until you have it working minimally at least, otherwise it's
just problems to deal with.
i actually was mostly thinking of Script only objects - ie they are entirely
defined by script and not layout. they can USE layout groups loaded from the
same file - just like c code can... or load other script only objects... this
script only thing can be done without branches, without changing scms's...
Yes, and while that's uber-cool, it can be postponed. Let's finish
what it's started and we go after that later.
btw - i don't think git will help us much at all. been using it myself and
it's
incredibly annoying, is horrid at merging conflicts (mergetool - when it fails
leaves u with an awful mess!). i am no fan of git. it has bitten me in the
arse
already a few times. i much prefer svn but that's not the point. a SCMS
doesnt make this possible or not - we can do this all inline in HEAD with no
breaks or change of SCMS...
This can lead to some flamewars, but this is because you just don't
know how to use it properly. No time to learn. SVN is mostly like CVS,
what you're used to, so you're less afraid... Oh! just reminds me of
my idea to use JS instead of Lua! ;-)
BTW, git-merge should just be done by integrators, not developers,
these should just git-rebase, git-merge should, in the common case,
just apply with Fast Forward.
When you have some time, we can talk about it, some consulting-on-git
for raster ;-)
removal of embryo is a matter of how much is it
really used and needed where it can't trivially be replaced with lua in the
few
uses?. or is it used so much - we keep it, and just add lua anyway in
addition
and if you want more powerful controls, you use lua, not embryo at the design
stage. :)
The showstopper I see is not porting code to lua, but getting this
code done. I know you'd like to do it, but will YOU have time to do
(as in completely finish) it? [The emphasis on you is because I doubt
others, who speaks loudly about lua, doing any code to make it happen,
it will, as always, be relying on you]
Maybe I'm being selfish here, but I see many other areas in E17/EFL
that needs your attention, that are less ready and would benefit from
your efforts.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
Re: [E-devel] Eina
On Sat, Aug 2, 2008 at 8:59 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: Hi all, as you all (most) know, eina has hit proto cvs. I think several things have to be explained, references to eina's license, code and so have appeared on different threads and honestly following them all is very complicated and is also hard to actually decide something, so it might be good if at some moment, someone can make a summary of several opinions and just do a poll and decide on it. Anyway, here is my summary: Objective: Eina's original objective was to settle down the long-time discussion about multiple data types, mainly ecore's and evas', it was an attempt that, from what i've seen, several developers have agreed and have a good will on this library; even the ecore's data types supporter (eina's is currently based around evas data types). It has several subsystems in a very similar way to what ecore has, but the main reason to not place ecore on the bottom of the software dependency stack was because not every library built around our data types wants to be loopized with ecore's main loop implementation, but be some kind of agnostic to ecore, so gtk / qt / whatever can use this libraries an fit their own loop manager on top of this low level library. Evas is an example of such a thing (there are others), and no, ecore-evas current double dependency is not the main problem eina wants to solve, not even the original problem it wanted to solve. If you place the efl stack, eina will be at the bottom, ecore on top of it and so other libraries/apps that *need* some kind of main loop handling, it can be summarized as pull approach libraries you pull the state from it, instead of evas (and others libraries) where you push the state (evas_render). License As most of the code on efl-research project (and most of *my* code) it does not have COPYING file, it was left out on purpose, basically to be able to discuss this license issue with e developers. We all have already argued about licensing and there are several respectable and contrary point of views. I, as the original author of this library, even if some of the code was taken from evas or ecore, wanted to license the library as LGPL; but as i have already stated, this new license has several considerations, *please* don't start a license arguments, the other thread is for that, this one is to decide: 1. Relicensing eina as LGPL is possible and *does not* go against Evas or Ecore license, BSD allows that as long as the third (author) clause is respected and so it will be (in case eina's license finally gets set to LGPL) 2. What will be the reaction from developers that want BSD license? from what i've deduced on IRC and ML, several of this developers *won't* contribute to this library if it is not BSD, (please those developers that think that this is point is for them, confirm or deny this). In my opinion the current state of e developers is too small to actually divide it based on the license they prefer; and of course that argument imposes the license the library can be. So, the main question on this point is: if it is LGPL are you going to contribute to it? and, if it is LGPL are you going to *link against this library? I'm fine with LGPL or BSD, but would like to keep it LGPL. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eina
On 2-Aug-08, at 7:59 PM, Jorge Luis Zapata Muga wrote: License As most of the code on efl-research project (and most of *my* code) it does not have COPYING file, it was left out on purpose, basically to Leaving out a COPYING file basically makes the code proprietary. No- one can use it without specifically asking you permission. be able to discuss this license issue with e developers. We all have already argued about licensing and there are several respectable and contrary point of views. I, as the original author of this library, even if some of the code was taken from evas or ecore, wanted to license the library as LGPL; but as i have already stated, this new license has several considerations, *please* don't start a license arguments, the other thread is for that, this one is to decide: 1. Relicensing eina as LGPL is possible and *does not* go against Evas or Ecore license, BSD allows that as long as the third (author) clause is respected and so it will be (in case eina's license finally gets set to LGPL) 2. What will be the reaction from developers that want BSD license? from what i've deduced on IRC and ML, several of this developers *won't* contribute to this library if it is not BSD, (please those developers that think that this is point is for them, confirm or deny this). In my opinion the current state of e developers is too small to actually divide it based on the license they prefer; and of course that argument imposes the license the library can be. So, the main question on this point is: if it is LGPL are you going to contribute to it? and, if it is LGPL are you going to *link against this library? I won't help if it's LGPL. I also won't link to it in my code as I won't fix bugs in it. dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Sun, 03 Aug 2008 02:07:40 +0300 Viktor Kojouharov [EMAIL PROTECTED] babbled: I disagree. 'Compatibility problems' are non-existent, since they will all interact with edje parts, not with one another. And reading someone's code will always be harder if you don't know the language which is used. That holds true now, if you don't know embryo, and will hold true in the future, regardless of what language(s) we pick. However, it will be easier to write a theme, since the likelihood of knowing a supported language will increase. i will say - multiple languages is not an option. it will lead to compat issues. why? each lang requires its OWN bindings, and soon enough one of the langs will fall behind in bindings or work a bit differently due to language specifics... it WILL b a problem. this is why i disagree with multiple langs. embryo at best can stay due to compat issues... but other than that... we move to another major lang engine - embryo stays only as legacy and is unmaintained or non-improved. either that or its removed to save maintenance. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: embryo release in 2 weeks
delurk/ On Aug 2, 2008, at 12:11 AM, Gustavo Sverzut Barbieri wrote: On Sat, Aug 2, 2008 at 3:52 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 02 Aug 2008 00:03:33 -0500 Nick Hughart [EMAIL PROTECTED] babbled: Jose Gonzalez wrote: Gustavo wrote: Since Edje is target at designers (ie: colors are not premul, etc), I think we should go with JS since most designers know it somehow, even if they don't really know, they think they do and they will not be afraid of trying it... Also, many systems use it as scripting language, comes to mind Photoshop, Qt-based applications and it's the official language of KDE for exactly that reason. I remember INdT designers hacking some Photoshop scripts just because they knew bits of JS from web development. Lua is good, yes, but I think that going with a more widespread language is the way to go. Indeed. Javascript has enourmous widespread use on the web, very well knonwn to designers, very close to flash's actionscript, and runtimes for it are becoming faster. It should be a verious consideration. Just wanted to note that ActionScript is actually based on ECMAScript afaik which is what JS is based on and thus why they are so similar. in all honesty - javascript is not going to make anything a lot better... as the only thing we will get is language constructs - the massive pool of knowledge on js is its use WITH www objects and with the api and event facilities a browser provides. this will not be the same. this bit will be different, thus all we get is syntax and core language constructs (i.e. C without even libc). so aqs such the usefulness of such a syntax is not so much - as frankly - lua, java, javascript, c, c++ all inherit vastly similar core syntax and constructs. if we were doing lisp or haskel or prolog... i'd say we are making life hard for designers. even python diverges much more than lua/c/c+ +/perl/js etc. etc. - so we're in ballpark already. remember they likely also have to learn all of edje/edc and the internal edje api we expose anyway... so lanugage i think is a moot point here beyond overall core syntax style - and if it's familiar and easy. :) As I mentioned in other mails, I strongly disagree. Users, specially non-hackers (ie: designers, the target audience) are usually very reluctant to learn a new programming language. It's more psycological than technical, as you said the actual work will be almost the same for them, however their willingness to do so will be heavily impacted by such. This is a very good observation. As you said, like in the C without libC, if you present hackers that know C with a machine with C w/o libC or another language, they'll go with C because they think they know it more and thus will be easier. I know I'm not really involved anymore, but I would really hate to see yet another long-term delay keep e17 from being released. Stick with embryo, and if possible make it stick around for e18 as well, make language choice a possibility. -Blake lurk/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Aug 1, 2008, at 10:53 PM, dan sinclair wrote: On 2-Aug-08, at 1:40 AM, Nick Hughart wrote: Vincent Torri wrote: On Sat, 2 Aug 2008, dan sinclair wrote: I'd say you're so eager to release something you're not thinking about the impression it gives. Changing things in a pre-1.0 is fine and expected. Releasing a 1.0 and then breaking it or making major changes a few months down the road is a very bad impression. I don't think that if we release a 1.0 soon, the next the next major release wiil be out in a few month. It will follow the same release process (some years) The problem is, the two issues that have come up that are being considered as blockers are things that may affect how many people want to use the EFL. So waiting 3-4 years after a disappointing release may just push people away. We should at least try to address the shortcomings now or people will either have to wait years for the new release or get a release so soon that they have to readjust everything. Either way, I'm sure they won't be happy. It all comes down to when you're doing the 2.0 release. If you do a 2.0 release in a few months it looks like we just rushed a 1.0 out the door to say we had a 1.0. Major releases should last a few _years_. If we're seriously considering ripping out Embryo in a few _months_ that's a pretty good sign it isn't ready to be released yet. If we know we're going to rip out Embryo and we push out Edje with Embryo scripting just to remove it in the next release it isn't going to make people happy. They'll have to port all their themes to the new scripting language. We're better to wait until we have a foundation we want to work from to get there. Sorry, please take a reality check here. E17 has been in development for nearly 10 years. The libraries have been fairly stable feature- wise for ages. Bite the bullet! Release it. Don't rip out embryo, add a CLR-like thing or something down the road if another language is absolutely necessary (which I think is really unlikely). The development life-cycle of this project is non-existent, how do you know what's necessary without a broad user base demanding it? It's good enough! The EFL has been since Edje was written and Eet took over for Edb. Developers are horrible at making these decisions. Maybe the folks at one of the commercial companies using E would be willing to donate the time of an actual product manager or something to help here. As mentioned before a release manager is crucial, someone who can make mandates and have them followed. snip -Blake - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On 2-Aug-08, at 9:41 PM, Blake Barnett wrote: On Aug 1, 2008, at 10:53 PM, dan sinclair wrote: It all comes down to when you're doing the 2.0 release. If you do a 2.0 release in a few months it looks like we just rushed a 1.0 out the door to say we had a 1.0. Major releases should last a few _years_. If we're seriously considering ripping out Embryo in a few _months_ that's a pretty good sign it isn't ready to be released yet. If we know we're going to rip out Embryo and we push out Edje with Embryo scripting just to remove it in the next release it isn't going to make people happy. They'll have to port all their themes to the new scripting language. We're better to wait until we have a foundation we want to work from to get there. Sorry, please take a reality check here. E17 has been in development for nearly 10 years. The libraries have been fairly stable feature- wise for ages. Bite the bullet! Release it. Don't rip out embryo, add a CLR-like thing or something down the road if another language is absolutely necessary (which I think is really unlikely). The development life-cycle of this project is non-existent, how do you know what's necessary without a broad user base demanding it? It's good enough! The EFL has been since Edje was written and Eet took over for Edb. Sure, the EFL has been around for a while. That also implies people have been using it for a while and possibly found issues with it. Themers have already stepped up and said they've had issues with Embryo. Developers are horrible at making these decisions. Maybe the folks at one of the commercial companies using E would be willing to donate the time of an actual product manager or something to help here. As mentioned before a release manager is crucial, someone who can make mandates and have them followed. Um, they can certainly try to set release schedules but unless that company starts paying a bunch of EFL developers to do the code and get it integrated they don't really mean anything. dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building
On Aug 2, 2008, at 6:55 PM, dan sinclair wrote: On 2-Aug-08, at 9:41 PM, Blake Barnett wrote: On Aug 1, 2008, at 10:53 PM, dan sinclair wrote: It all comes down to when you're doing the 2.0 release. If you do a 2.0 release in a few months it looks like we just rushed a 1.0 out the door to say we had a 1.0. Major releases should last a few _years_. If we're seriously considering ripping out Embryo in a few _months_ that's a pretty good sign it isn't ready to be released yet. If we know we're going to rip out Embryo and we push out Edje with Embryo scripting just to remove it in the next release it isn't going to make people happy. They'll have to port all their themes to the new scripting language. We're better to wait until we have a foundation we want to work from to get there. Sorry, please take a reality check here. E17 has been in development for nearly 10 years. The libraries have been fairly stable feature- wise for ages. Bite the bullet! Release it. Don't rip out embryo, add a CLR-like thing or something down the road if another language is absolutely necessary (which I think is really unlikely). The development life-cycle of this project is non-existent, how do you know what's necessary without a broad user base demanding it? It's good enough! The EFL has been since Edje was written and Eet took over for Edb. Sure, the EFL has been around for a while. That also implies people have been using it for a while and possibly found issues with it. Themers have already stepped up and said they've had issues with Embryo. Developers are horrible at making these decisions. Maybe the folks at one of the commercial companies using E would be willing to donate the time of an actual product manager or something to help here. As mentioned before a release manager is crucial, someone who can make mandates and have them followed. Um, they can certainly try to set release schedules but unless that company starts paying a bunch of EFL developers to do the code and get it integrated they don't really mean anything. It wouldn't make sense for a company to donate the time of a product manager if they didn't also have developers working on the code. Of course it has to be reasonable for those involved to meet the deadlines. But just _having_ deadlines is a fairly good motivator, even for those just volunteering their time. It works for other projects... -Blake - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
