Re: [E-devel] Community Building - release
Toma wrote: On 30/07/2008, Jose Gonzalez [EMAIL PROTECTED] wrote: Vincent wrote: Quoting Nathan Ingersoll [EMAIL PROTECTED]: 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. Some ideas I and others have: 1) We must release the core libs (evas, ecore, embryo, edje, efreet and e_dbus, that is what is needed by e17). So we must discuss to what must be done for each of them before a release. Here what I think. You can add other things I have forgotten. * embryo: is in a very good shape. raster wanted to release it later because he wants to look at lua for scripting. I think that it is a very bad idea, and should be delayed for the next version. What may lack is documentation. * evas: also in a very good shape, but several things wanted to be done: api changes in polygons, gradient and data types (see below). Documentation must be improved too. Although polygons can be done in a rather short amount of time, gradient stuff can take a long time and maybe can be done (with other things like vgfx) in the next evas major release. Note that Nathan and me agreed on the fact that, today, we should have an evas 3.*, and not 0.9... * ecore: Cedric wants to reorganize some stuff in ecore_evas. Also data types. See next point * evas and ecore: data types. The problem is that it will break abi if we change the data types. See below for a solution * edje: except the problem of data types, I don't see any major flaw. * efreet and e_dbus: I don't know much about them. They are used with e17 without problem. Cedric told me that he wanted to speed up efreet. There is the problem of data types, though. The problem with data types is that it will break ABI and API. So we must decide if we release with or without the change in data types. A solution is to release with number version 0.10 (current version number is 0.9.9) without data type changes and warns that there will be big changes for 1.0. 2) A release manager must be named. What he should do: * decide which library may be released because of a certain amount of important bugs have been fixed. Of course, this should be discussed in the ML for example. * sent mails to warn about pre-releases (in that period, only bug fixes and doc changes are allowed. Maybe other things i can't think of.) and releases * of course, provide the tar balls for pre-releases and releases * maybe add news on some sites like osnews, /., freshmeat or phoronix Even if there are 0.10 releases before a 1.0, the fact that we announce such release is a good thing. As an example, Kim is doing e16 releases periodically. Each time one is done, a user announce that on osnews. And i often read in those news that people are happy to see that e16 is still maintained. Comments, ideas ? Vincent It's good to see such attempts and I hope they continue. I'd also like to applaud Carsten for taking the high-road, and I hope that E can become a more inclusive project able to honestly embrace differences, attract developers, and work with others. As to the above mentioned steps.. I disagree with some of the arguments, but they are also not unreasonable - so long as everyone realizes that the state of many things in E is still rather basic and are willing to 'break' apis on major releases when they bring good improvements.. E is still small enough that it can be fluid if it wants to. But, one very important thing to consider here is: What exactly is it that E wants to achieve? What are the basic 'large' goals? Thats a funny one, because a lot of people say Oh, E17 isnt as good as Gnome... or KDE when its not completely a desktop environmant like those 2. It has a lot of the mechanics of a full DE and being so modular, could fill the things needed to become a full DE from that point. (And then you ask, whats the difference between what E17 is now and a full DE?!? I dont know. Ask wikipedia or something.) If it was competeing souly against WMs like fluxbox and friends, then thats already done and kicking ass. If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply becuase there isnt a
Re: [E-devel] Community Building - release
I wrote: ... As to the above mentioned steps.. I disagree with some of the arguments, but they are also not unreasonable - so long as everyone realizes that the state of many things in E is still rather basic and are willing to 'break' apis on major releases when they bring good improvements.. E is still small enough that it can be fluid if it wants to. But, one very important thing to consider here is: What exactly is it that E wants to achieve? What are the basic 'large' goals? Thats a funny one, because a lot of people say Oh, E17 isnt as good as Gnome... or KDE when its not completely a desktop environmant like those 2. It has a lot of the mechanics of a full DE and being so modular, could fill the things needed to become a full DE from that point. (And then you ask, whats the difference between what E17 is now and a full DE?!? I dont know. Ask wikipedia or something.) If it was competeing souly against WMs like fluxbox and friends, then thats already done and kicking ass. If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply becuase there isnt a 1.0 release. Toma I'm not sure I follow some of this. There are many different things that E could do or become, it's not just a question of what the wm/desktop-shell could do/be, or even what a desktop environment of some sort could do/be. There are questions of development 'platforms', what they might be geared to develop, what they might emphasize, and such... and there are questions of what kinds of apps or further libs or frameworks people might want to build beyond that, to create some sort of coherent 'environment(s)' and such. If you're going to ask people, then it depends who these people are and what kind of audience they are: end-users of apps? end-users of desktop environments/shells/whatnot? theme designers (of what)? developers of apps? rich app developers? etc. Forgot to mention a few other relevant ones: developers of web apis/services? developers of gfx/canvas libs? developers of gui toolkits? ... My questions were directed at the audience consisting of all E developers. :) If all that's really wanted is a wm/shell kind of thing, then you've got it. It's pretty good - could be better, etc. - but it's there. If some want 'development platforms' then what kinds? And which apis/models are best suited to build whatever with? Which can be attractive to certain areas more than others, etc. If some want to also build environments/whatnot on top of those platforms, then what apps/libs do you need for short, mid, long term growth? What are relevant models out there in open, partly-open, not-so-open worlds, that could be used for comparison? Click for FHA loan, $0 lender fees, low rates approvals nationwide http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mItjHT46zg0b4UPUAGi6dZfbcr8x5PmjR6BgYgXGZVlZkta/ - 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 - release
On 31/07/2008, Jose Gonzalez [EMAIL PROTECTED] wrote: I wrote: ... As to the above mentioned steps.. I disagree with some of the arguments, but they are also not unreasonable - so long as everyone realizes that the state of many things in E is still rather basic and are willing to 'break' apis on major releases when they bring good improvements.. E is still small enough that it can be fluid if it wants to. But, one very important thing to consider here is: What exactly is it that E wants to achieve? What are the basic 'large' goals? Thats a funny one, because a lot of people say Oh, E17 isnt as good as Gnome... or KDE when its not completely a desktop environmant like those 2. It has a lot of the mechanics of a full DE and being so modular, could fill the things needed to become a full DE from that point. (And then you ask, whats the difference between what E17 is now and a full DE?!? I dont know. Ask wikipedia or something.) If it was competeing souly against WMs like fluxbox and friends, then thats already done and kicking ass. If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply becuase there isnt a 1.0 release. Toma I'm not sure I follow some of this. There are many different things that E could do or become, it's not just a question of what the wm/desktop-shell could do/be, or even what a desktop environment of some sort could do/be. There are questions of development 'platforms', what they might be geared to develop, what they might emphasize, and such... and there are questions of what kinds of apps or further libs or frameworks people might want to build beyond that, to create some sort of coherent 'environment(s)' and such. If you're going to ask people, then it depends who these people are and what kind of audience they are: end-users of apps? end-users of desktop environments/shells/whatnot? theme designers (of what)? developers of apps? rich app developers? etc. Forgot to mention a few other relevant ones: developers of web apis/services? developers of gfx/canvas libs? developers of gui toolkits? ... My questions were directed at the audience consisting of all E developers. :) Yes... I mean ask the general random normal desktop users that wander into #e on freenode and ask those kind of questions. After all, theyre the ones that want to use E17. I think developers tend to think like developers and dont tend to see the importance of mundane little things that the average Joe likes/wants. Thats why companies employ market researchers to see whats needed and wanted. Im not saying E needs anyone dedicated to market research, but its something to keep in mind. Personally, I made a couple black themes then people said You should try making a light theme, so I made Edjy and Cerium. Thats an exmaple of listening to the 'market'. Having said that, I see alot of enthusiasm on random tech forums for EFL and you could see the reaction on the aMSN forums when you compared EFL directly to EFL. People scrambled to get EFL installed and were really impressed by how it looked. The biggest problem everyone had (including myself) was building the libraries needed, and I dare say would have been a lot easier if there was a packages release of EFL-Python and all its deps. So maybe a more steady snapshot schedule and perhaps a couple days of *Bug Extermination* before those snapshots so developers and users a like can access it all a little easier? Toma If all that's really wanted is a wm/shell kind of thing, then you've got it. It's pretty good - could be better, etc. - but it's there. If some want 'development platforms' then what kinds? And which apis/models are best suited to build whatever with? Which can be attractive to certain areas more than others, etc. If some want to also build environments/whatnot on top of those platforms, then what apps/libs do you need for short, mid, long term growth? What are relevant models out there in open, partly-open, not-so-open worlds, that could be used for comparison? Click for FHA loan, $0 lender fees, low rates approvals nationwide http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mItjHT46zg0b4UPUAGi6dZfbcr8x5PmjR6BgYgXGZVlZkta/ - 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
Re: [E-devel] Community Building - release
Toma wrote: On 31/07/2008, Jose Gonzalez [EMAIL PROTECTED] wrote: I wrote: ... As to the above mentioned steps.. I disagree with some of the arguments, but they are also not unreasonable - so long as everyone realizes that the state of many things in E is still rather basic and are willing to 'break' apis on major releases when they bring good improvements.. E is still small enough that it can be fluid if it wants to. But, one very important thing to consider here is: What exactly is it that E wants to achieve? What are the basic 'large' goals? Thats a funny one, because a lot of people say Oh, E17 isnt as good as Gnome... or KDE when its not completely a desktop environmant like those 2. It has a lot of the mechanics of a full DE and being so modular, could fill the things needed to become a full DE from that point. (And then you ask, whats the difference between what E17 is now and a full DE?!? I dont know. Ask wikipedia or something.) If it was competeing souly against WMs like fluxbox and friends, then thats already done and kicking ass. If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply becuase there isnt a 1.0 release. Toma I'm not sure I follow some of this. There are many different things that E could do or become, it's not just a question of what the wm/desktop-shell could do/be, or even what a desktop environment of some sort could do/be. There are questions of development 'platforms', what they might be geared to develop, what they might emphasize, and such... and there are questions of what kinds of apps or further libs or frameworks people might want to build beyond that, to create some sort of coherent 'environment(s)' and such. If you're going to ask people, then it depends who these people are and what kind of audience they are: end-users of apps? end-users of desktop environments/shells/whatnot? theme designers (of what)? developers of apps? rich app developers? etc. Forgot to mention a few other relevant ones: developers of web apis/services? developers of gfx/canvas libs? developers of gui toolkits? ... My questions were directed at the audience consisting of all E developers. :) Yes... I mean ask the general random normal desktop users that wander into #e on freenode and ask those kind of questions. After all, theyre the ones that want to use E17. I think developers tend to think like developers and dont tend to see the importance of mundane little things that the average Joe likes/wants. Thats why companies employ market researchers to see whats needed and wanted. Im not saying E needs anyone dedicated to market research, but its something to keep in mind. Personally, I made a couple black themes then people said You should try making a light theme, so I made Edjy and Cerium. Thats an exmaple of listening to the 'market'. Ok, sure. But in the case of developers that are building things like a gfx lib or a gui toolkit, then their market might be other developers, not directly end-users-of-some-app. Having said that, I see alot of enthusiasm on random tech forums for EFL and you could see the reaction on the aMSN forums when you compared EFL directly to EFL. People scrambled to get EFL installed Errr.. I'm not sure I follow you here, but I guess this is a good thing? and were really impressed by how it looked. The biggest problem everyone had (including myself) was building the libraries needed, and I dare say would have been a lot easier if there was a packages release of EFL-Python and all its deps. So maybe a more steady snapshot schedule and perhaps a couple days of *Bug Extermination* before those snapshots so developers and users a like can access it all a little easier? Toma Maybe what you're trying to get at here is the issue of releasing the libs that Vincent and Nathan pointed to, or some of them, and e17 as well. I personally don't think evas, ecore, edje are ready for 'release' in the sense of them being so stable that further near-future changes wouldn't break anything. Not near really. However, that doesn't mean they couldn't be released as they are, and leave such changes for a future version of those libs. But then I'm not the maintainer(s) of those libs, and they may disagree with me. Click here to compare top medical billing products, get demos, and quotes. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oiDnLrNIJc6ZgQsiMlLjmRfs5Jv0LVqHgkFX1bBsUVYSgtx/ - This SF.Net email is sponsored by the
Re: [E-devel] Community Building - release
I wrote: Toma wrote: On 31/07/2008, Jose Gonzalez [EMAIL PROTECTED] wrote: I wrote: ... As to the above mentioned steps.. I disagree with some of the arguments, but they are also not unreasonable - so long as everyone realizes that the state of many things in E is still rather basic and are willing to 'break' apis on major releases when they bring good improvements.. E is still small enough that it can be fluid if it wants to. But, one very important thing to consider here is: What exactly is it that E wants to achieve? What are the basic 'large' goals? Thats a funny one, because a lot of people say Oh, E17 isnt as good as Gnome... or KDE when its not completely a desktop environmant like those 2. It has a lot of the mechanics of a full DE and being so modular, could fill the things needed to become a full DE from that point. (And then you ask, whats the difference between what E17 is now and a full DE?!? I dont know. Ask wikipedia or something.) If it was competeing souly against WMs like fluxbox and friends, then thats already done and kicking ass. If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply becuase there isnt a 1.0 release. Toma I'm not sure I follow some of this. There are many different things that E could do or become, it's not just a question of what the wm/desktop-shell could do/be, or even what a desktop environment of some sort could do/be. There are questions of development 'platforms', what they might be geared to develop, what they might emphasize, and such... and there are questions of what kinds of apps or further libs or frameworks people might want to build beyond that, to create some sort of coherent 'environment(s)' and such. If you're going to ask people, then it depends who these people are and what kind of audience they are: end-users of apps? end-users of desktop environments/shells/whatnot? theme designers (of what)? developers of apps? rich app developers? etc. Forgot to mention a few other relevant ones: developers of web apis/services? developers of gfx/canvas libs? developers of gui toolkits? ... My questions were directed at the audience consisting of all E developers. :) Yes... I mean ask the general random normal desktop users that wander into #e on freenode and ask those kind of questions. After all, theyre the ones that want to use E17. I think developers tend to think like developers and dont tend to see the importance of mundane little things that the average Joe likes/wants. Thats why companies employ market researchers to see whats needed and wanted. Im not saying E needs anyone dedicated to market research, but its something to keep in mind. Personally, I made a couple black themes then people said You should try making a light theme, so I made Edjy and Cerium. Thats an exmaple of listening to the 'market'. Ok, sure. But in the case of developers that are building things like a gfx lib or a gui toolkit, then their market might be other developers, not directly end-users-of-some-app. Having said that, I see alot of enthusiasm on random tech forums for EFL and you could see the reaction on the aMSN forums when you compared EFL directly to EFL. People scrambled to get EFL installed Errr.. I'm not sure I follow you here, but I guess this is a good thing? and were really impressed by how it looked. The biggest problem everyone had (including myself) was building the libraries needed, and I dare say would have been a lot easier if there was a packages release of EFL-Python and all its deps. So maybe a more steady snapshot schedule and perhaps a couple days of *Bug Extermination* before those snapshots so developers and users a like can access it all a little easier? Toma Maybe what you're trying to get at here is the issue of releasing the libs that Vincent and Nathan pointed to, or some of them, and e17 as well. I personally don't think evas, ecore, edje are ready for 'release' in the sense of them being so stable that further near-future changes wouldn't break anything. Not near really. However, that doesn't mean they couldn't be released as they are, and leave such changes for a future version of those libs. But then I'm not the maintainer(s) of those libs, and they may disagree with me. By a future version of those libs of course I meant a 'major' version increase. In any case, if you want to know why I don't think eg. evas is near ready for a release: it's not just gradients or vgfx stuff,
Re: [E-devel] Community Building - release
By a future version of those libs of course I meant a 'major' version increase. In any case, if you want to know why I don't think eg. evas is near ready for a release: it's not just gradients or vgfx stuff, it's possibly smart classes and native surfaces that may need breaking changes, it's the soft16 engines which are really not ready for use (need to be replaced), it's the fact that having evas data structures does nothing good for E (I believe they need to be moved out of evas and have evas depend on that lib - eina or edata or whatever), and a few other things. There is also the option of releasing things as a pre-alpha test version, and see what the reaction is, and work from there. that's a bit what i propose when i said to release as 0.10. We keep the major release to 0 and are free to break anything for the major 1 version In addition, packagers will be happier with a 0.10 release rather than with a snapshot, which means that we can spread the efl technologies in a better way than what is currently done. 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] Proposed evas gfx api changes and additions - part I.
On Thu, Jul 17, 2008 at 10:36 AM, Jose Gonzalez [EMAIL PROTECTED] wrote:
As the subject states, let me make a (relatively) short summary of some
proposed changes and additions to the evas gfx api -- and I'll deal with only
gradients and a possible vgfx-objs api, leaving transforms (mostly) and
filters
for later.
First, changes to the current gradient api. This would replace the
current
api with the following one:
(1) For creating gradients:
**
Evas_Object *evas_object_gradient_[type]_add(e);
where the types are: linear and radial (and possibly later also angular,
rectangular, triangular, sinusoidal, ...)
(2) For setting gradient geometries (of a given type):
*
void evas_object_gradient_[type]_fill_set(obj, [geometry desc]);
Where the [geom desc] is:
(a) for linear grads,
void evas_object_gradient_linear_fill_set(obj, Evas_Coord x0, Evas_Coord y0,
Evas_Coord x1, Evas_Coord y1);
(b) for radial grads,
void evas_object_gradient_radial_fill_set(obj, Evas_Coord cx0, Evas_Coord
cy0,
float rx, float ry);
And we'd leave any other types for later as desired.
(3) For setting the gradient geometry's spread (or repeat, or extend) mode:
void evas_object_gradient_fill_spread_set(obj, int tile_mode);
(4) For modifying the gradient geometry via a transform:
***
void evas_object_gradient_fill_transform_set(obj, Evas_Transform *t);
where an 'Evas_Transform' is defined as:
struct Evas_Transform
{
float mxx, mxy, mxz;
float myx, myy, myz;
float mzx, mzy, mzz;
};
ie. a 3x3 tmatrix which can be used to define a projective transformation
or an affine one by ignoring the mzx,mzy,mzz components. Only affine ones
supported for grad geometries (though the obj itself may support proj
ones).
(5) For clearing/defining the gradient obj's spectrum:
***
void evas_object_gradient_clear(obj);
ie. remove any stops or data or whatnot from the gradient.
void evas_object_gradient_color_np_stop_insert(obj, r, g, b, a, float pos);
ie. insert a NON_PREMUL color at the given pos (clamped to be in [0,1])
And *possibly* also similar premul such, as exist currently:
void evas_object_gradient_color_stop_insert(obj, r, g, b, a, float pos);
void evas_object_gradient_alpha_stop_insert(obj, a, float pos);
void evas_object_gradient_color_data_set(obj, *data, len, has_alpha);
void evas_object_gradient_alpha_data_set(obj, *data, len);
That's it for basic gradient support (one could add more types, and one
could add some funcs to query/modify stops if desired).
The reasons for proposing these changes?
To allow for direct support of gradients with various possible engine
backends
(eg. xrender, cairo, OpenVG, ... others).
To have an api which is 'fitted' to what most all vgfx specs/lib-apis support
with gradients.
To more easily enable and represent various uses of gradients (including vgfx
related ones like texturing of geometric figures with them).
This then leads to a proposed api for vgfx-objects in evas -- and
recall, by
vgfx-objects, we mean objs that can be filled and/or stroked (eg. lines,
rects,
polys, paths, ... maybe text) with a color or a texture (aka a paint or a
pattern).
Some time ago i had another idea that i've been implementing, some of
you already know enesim and ekeko, some other dont, let me explain why
i think adding this to evas is not good imho.
One of the main reasons of not releasing software is that it evolves
too fast or it doesnt stabilize enough to make a stamp on a specific
version and release it; but that is a direct consequence on what your
lib wants to achieve. So im partisan of doing small things with solid
API, of course not too small that it will make the lib itself dumb,
but keep the objectives clear.
Adding all of this to evas itself not only will make evas more bloated
but more unmaintainable and of course the release time will be
delayed, i'd like to share another idea that might help us achieve the
same goals jose is trying to do, but keeping the api itself of evas
clear enough.
We are always on the objects/engines problem, how to support more
objects features and how to add more engines and the truth is that the
model we have right now doesnt scale too god, we are duplicating code
here and there for engines and we are limited with current objects for
fast drawing operations and smart objects for outsiders drawers whcih
might not be as fast as an insider object.
The idea is to flip the concept, totally. Not make the fast objects as
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
On Thu, Jul 31, 2008 at 12:04 PM, Jorge Luis Zapata Muga
[EMAIL PROTECTED] wrote:
On Thu, Jul 17, 2008 at 10:36 AM, Jose Gonzalez [EMAIL PROTECTED] wrote:
As the subject states, let me make a (relatively) short summary of some
proposed changes and additions to the evas gfx api -- and I'll deal with only
gradients and a possible vgfx-objs api, leaving transforms (mostly) and
filters
for later.
First, changes to the current gradient api. This would replace the
current
api with the following one:
(1) For creating gradients:
**
Evas_Object *evas_object_gradient_[type]_add(e);
where the types are: linear and radial (and possibly later also angular,
rectangular, triangular, sinusoidal, ...)
(2) For setting gradient geometries (of a given type):
*
void evas_object_gradient_[type]_fill_set(obj, [geometry desc]);
Where the [geom desc] is:
(a) for linear grads,
void evas_object_gradient_linear_fill_set(obj, Evas_Coord x0, Evas_Coord y0,
Evas_Coord x1, Evas_Coord
y1);
(b) for radial grads,
void evas_object_gradient_radial_fill_set(obj, Evas_Coord cx0, Evas_Coord
cy0,
float rx, float ry);
And we'd leave any other types for later as desired.
(3) For setting the gradient geometry's spread (or repeat, or extend)
mode:
void evas_object_gradient_fill_spread_set(obj, int tile_mode);
(4) For modifying the gradient geometry via a transform:
***
void evas_object_gradient_fill_transform_set(obj, Evas_Transform *t);
where an 'Evas_Transform' is defined as:
struct Evas_Transform
{
float mxx, mxy, mxz;
float myx, myy, myz;
float mzx, mzy, mzz;
};
ie. a 3x3 tmatrix which can be used to define a projective
transformation
or an affine one by ignoring the mzx,mzy,mzz components. Only affine
ones
supported for grad geometries (though the obj itself may support proj
ones).
(5) For clearing/defining the gradient obj's spectrum:
***
void evas_object_gradient_clear(obj);
ie. remove any stops or data or whatnot from the gradient.
void evas_object_gradient_color_np_stop_insert(obj, r, g, b, a, float pos);
ie. insert a NON_PREMUL color at the given pos (clamped to be in [0,1])
And *possibly* also similar premul such, as exist currently:
void evas_object_gradient_color_stop_insert(obj, r, g, b, a, float pos);
void evas_object_gradient_alpha_stop_insert(obj, a, float pos);
void evas_object_gradient_color_data_set(obj, *data, len, has_alpha);
void evas_object_gradient_alpha_data_set(obj, *data, len);
That's it for basic gradient support (one could add more types, and one
could add some funcs to query/modify stops if desired).
The reasons for proposing these changes?
To allow for direct support of gradients with various possible engine
backends
(eg. xrender, cairo, OpenVG, ... others).
To have an api which is 'fitted' to what most all vgfx specs/lib-apis
support
with gradients.
To more easily enable and represent various uses of gradients (including
vgfx
related ones like texturing of geometric figures with them).
This then leads to a proposed api for vgfx-objects in evas -- and
recall, by
vgfx-objects, we mean objs that can be filled and/or stroked (eg. lines,
rects,
polys, paths, ... maybe text) with a color or a texture (aka a paint or a
pattern).
Some time ago i had another idea that i've been implementing, some of
you already know enesim and ekeko, some other dont, let me explain why
i think adding this to evas is not good imho.
One of the main reasons of not releasing software is that it evolves
too fast or it doesnt stabilize enough to make a stamp on a specific
version and release it; but that is a direct consequence on what your
lib wants to achieve. So im partisan of doing small things with solid
API, of course not too small that it will make the lib itself dumb,
but keep the objectives clear.
Adding all of this to evas itself not only will make evas more bloated
but more unmaintainable and of course the release time will be
delayed, i'd like to share another idea that might help us achieve the
same goals jose is trying to do, but keeping the api itself of evas
clear enough.
We are always on the objects/engines problem, how to support more
objects features and how to add more engines and the truth is that the
model we have right now doesnt scale too god, we are duplicating code
here and there for engines and we are limited with current objects for
fast drawing operations and smart objects for outsiders drawers whcih
Re: [E-devel] Proposed evas gfx api changes and additions - part I.
Jorge wrote: Some time ago i had another idea that i've been implementing, some of you already know enesim and ekeko, some other dont, let me explain why i think adding this to evas is not good imho. One of the main reasons of not releasing software is that it evolves too fast or it doesnt stabilize enough to make a stamp on a specific version and release it; but that is a direct consequence on what your lib wants to achieve. So im partisan of doing small things with solid API, of course not too small that it will make the lib itself dumb, but keep the objectives clear. Adding all of this to evas itself not only will make evas more bloated but more unmaintainable and of course the release time will be delayed, i'd like to share another idea that might help us achieve the same goals jose is trying to do, but keeping the api itself of evas clear enough. We are always on the objects/engines problem, how to support more objects features and how to add more engines and the truth is that the model we have right now doesnt scale too god, we are duplicating code here and there for engines and we are limited with current objects for fast drawing operations and smart objects for outsiders drawers whcih might not be as fast as an insider object. The idea is to flip the concept, totally. Not make the fast objects as inside objects and the engines as modules, but do both as modules with a different approach, mainly object+engine approach. The idea can be that an object (being a module or a library) register with evas for an specific object name and engine name (of course both the module and evas should share those names) like: evas_object_register(const char *name, const char *engine, Evas_Obj_Func); where the functions struct is something we already have but specific for that engine type. For this to happen, evas should export the needed functions and abstract the common code into exportable functions too. Use cases: - An engine doesnt support an object you are requesting natively? Evas should always fallback to software engine in that case, the drawing should be done on a user writable buffer and use the software engine there. So every engine should be reduced to a minimal set of functions: redraw() // redraws part of the engine output buffer blt_buffer() // blit a buffer into engine output buffer get_buffer() // get a buffer that the user can draw to get_native_buffer() // get a native surface so the object-engine can draw directly there - You want to build a private engine? You should set this engine's minimal functions, if you also want to provide accelerated objects for your engine, register a new object with your engine's name and fill the needed functions If we can settle down the above, which i think won't be that difficult to stabilize than the object's api, we would have gain a lot on flexibility. And then the object's api can be stabilized. Why i started enesim? because of the above cases, allow the user to do fancy graphics objects using enesim's primitives and direct rendering approach and also for easy benchmarking of the software engine. Do you think is a good idea? Yes, I think it is a good idea (though there are also other possibilities for realizing such a generic concept). However, there are two things to consider here: One is that you still eventually need some sort of api(s) for 'objs' that you may want to support to start with in some 'canvas' model -- and that includes a semantics that would be consistent, and basic/standard kinds of gfx concepts that are well-known and widely used. The other thing is the time and distance from such a more flexible approach to what's there now -- how to make both-ends-meet, or forget one and continue with the other. These are difficult questions to pin down and decide on. Let's consider the first part above only, and let me ask you this: What are the successful/modern gfx *apis* out there used for building guis, what are their models, what are their primitives, how do they deal with extensibility or custom rendering. Take a look at say Flash, Silverlight, and Qt..., and let me know what you see there. There are others as well, but if you look at just these and give a synopsis of what's there, we can compare with evas and/or some possible other thing and continue with greater insight and foresight. :) Click for free info on online degrees and make up to $150K/ year. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nlXFvWpEiH1JgkNuaQWtD3XAbh0bvIMLSauNEiAzQFFY4P3/ - 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
Re: [E-devel] Community Building - release
that's a bit what i propose when i said to release as 0.10. We keep the major release to 0 and are free to break anything for the major 1 version In addition, packagers will be happier with a 0.10 release rather than with a snapshot, which means that we can spread the efl technologies in a better way than what is currently done. Vincent I agree with you. I follow E mailing list and irc discussions for 3 or 4 years now. I begin to code with EFL for 3 years. I use core EFL evas, ecore, eet and edje not intensively as some of you do, but what I have seen in this 4 years, it's that they have been only few API breaks. My first little EFL program runs and compiles today. If I'm not mistaken the biggest changes that have been done is evas_list (evas_list_goto_first/evas_list_first_goto) and ine evas_smart or things like that. I'm speaking about API not the core. In an other hand, my first EFL application run faster than 3 years ago, very very faster. Evry day day evas_test and now expedite run faster on the same PC. I can run EFL on N810, it's very fast too. I can experiment on Windows Mobile and Windows Vista. It's awesome ! When I read RFC on mailing list, I see only new api, and no api break. Maybe I'm mistaken, but if we wait longer before a release (EFL libs not E) community envolved in this project will decrease. I think that a pre reslease like Vincent say, is a good choice for the future of this project. EFL are very good, it's realy a pleasure to work and play with this libs, but unfortunately this not the technical stuff that people are watching but rather the stability, the number of users, and the time they could win using this libs. I think, with my external point of view, that EFL are (for a long time now) closed to be release. Maybe we should follow this TODO list, if we have a goal and a dead line, we should work faster and better. If a release (or pre release 0.10) is done, we will have more developpers that could looks at this libs for their future developments. Community will have more motivation to write doc, examples and program that use EFL. It should be better for evryone. But maybe it's not your goal ? I don't blame anyone, It's just the thoughts of a guy that follow mailing list discussions for some time now. Regards, Nico - 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 - release
Toma escreveu: Thats a funny one, because a lot of people say Oh, E17 isnt as good as Gnome... or KDE when its not completely a desktop environmant like those 2. It has a lot of the mechanics of a full DE and being so modular, could fill the things needed to become a full DE from that point. (And then you ask, whats the difference between what E17 is now and a full DE?!? I dont know. Ask wikipedia or something.) If it was competeing souly against WMs like fluxbox and friends, then thats already done and kicking ass. If anything, it might be an idea to ask people, what 'needs' to be done? As a end-user, I think the foundations need to be solid. What happens if I drag icons around to and from things, does it does something useful? One of my major concerns when moving between DE's is that I always want some way to build quick access to the common apps of my everyday use and some break apart when doing that. It doesn't need to be icons on desktop, not event show icons at all, as long as the function to do so is there and works. Another one is a fast filemanager that works in what it tries to do. Even minimalist ones like the one included in xfce would suffice, as long as it works. It seems even kde is looking for less features-more simplicity... I didn't tried e17 for a long time, so I cant' say what's the problem today (if there is one), I may be willing to again at home, at work is just hard to get the time to do so. My $ 0.02 Solerman - 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-07-31 07:10:58 -0700
Build log for Enlightenment DR 0.17 on 2008-07-31 07:10:58 -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] Porting E to an ARM based embedded system.
Hi, On Wed, Jul 23, 2008 at 05:27:35PM -0300, imx31cpu . wrote: I am new to the enlightment world and I will soon (tomorrow) start trying to port it to an embedded system (Freescale i.MX31 PDK - http://www.freescale.com/imx31pdk). Since I am not an experient developer on the linux environment I will probably have a hard time doing that so I would like to know if any of you have already tryed to do this porting or if you have any suggestion that might help me to have enlightment running on this system. Note that the i.MX31 has a PowerVR MBX graphics core which is not documented publically. What's proposed as OpenGL ES support is a proprietary blob of source code which can be get under NDA from Freescale. Note also that the Freescale ltib BSPs may differ from Linux mainline. We are working on better mainline compatiblity for i.MX31 at Pengutronix while moving the Linux port for the phyCORE-i.MX31 forward, so expect more mainline patches soon (we are still working on i.MX27 issues and they have to be finished before moving on to i.MX31). rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 - 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 - release
On Thu, 31 July 2008 Toma [EMAIL PROTECTED] wrote: If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply becuase there isnt a 1.0 release. Related to what people might wish, it would be good as well to have some feature-list on the website, list which would be split in 3 parts: - implemented/complete features - features being worked on - wish/todo list Where possible this information should be categorized for the different parts of Enlightenment (E itself and its modules - some modules probably separately, the various libraries, applications around E like efm, epdf, ...) This would make it easier to know what E can do, if one's own needs are fulfilled and what's missing. Also it gets a better incentive to try and fill some of the gaps or even just try out Enlightement. Bruno - 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 - release
On 31-Jul-08, at 3:48 PM, Bruno wrote: On Thu, 31 July 2008 Toma [EMAIL PROTECTED] wrote: If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply becuase there isnt a 1.0 release. Related to what people might wish, it would be good as well to have some feature-list on the website, list which would be split in 3 parts: - implemented/complete features - features being worked on - wish/todo list Where possible this information should be categorized for the different parts of Enlightenment (E itself and its modules - some modules probably separately, the various libraries, applications around E like efm, epdf, ...) This would make it easier to know what E can do, if one's own needs are fulfilled and what's missing. Also it gets a better incentive to try and fill some of the gaps or even just try out Enlightement. http://bugs.enlightenment.org/ http://trac.enlightenment.org/e 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 - release
On Thu, 31 July 2008 dan sinclair [EMAIL PROTECTED] wrote: On 31-Jul-08, at 3:48 PM, Bruno wrote: On Thu, 31 July 2008 Toma [EMAIL PROTECTED] wrote: If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply becuase there isnt a 1.0 release. Related to what people might wish, it would be good as well to have some feature-list on the website, list which would be split in 3 parts: - implemented/complete features - features being worked on - wish/todo list Where possible this information should be categorized for the different parts of Enlightenment (E itself and its modules - some modules probably separately, the various libraries, applications around E like efm, epdf, ...) This would make it easier to know what E can do, if one's own needs are fulfilled and what's missing. Also it gets a better incentive to try and fill some of the gaps or even just try out Enlightement. http://bugs.enlightenment.org/ http://trac.enlightenment.org/e Unfortunately these list only wishlist/todo parts. It would also be good to at least get them more visible in the context of E17 on www.enlightenment.org Bruno - 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 - release
On 31-Jul-08, at 4:14 PM, Bruno wrote: On Thu, 31 July 2008 dan sinclair [EMAIL PROTECTED] wrote: On 31-Jul-08, at 3:48 PM, Bruno wrote: On Thu, 31 July 2008 Toma [EMAIL PROTECTED] wrote: If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, E17 is good, but its just not finished/has bits missing. Some lusers go as far to say Err E17 is buggy and not stable! Waa simply becuase there isnt a 1.0 release. Related to what people might wish, it would be good as well to have some feature-list on the website, list which would be split in 3 parts: - implemented/complete features - features being worked on - wish/todo list Where possible this information should be categorized for the different parts of Enlightenment (E itself and its modules - some modules probably separately, the various libraries, applications around E like efm, epdf, ...) This would make it easier to know what E can do, if one's own needs are fulfilled and what's missing. Also it gets a better incentive to try and fill some of the gaps or even just try out Enlightement. http://bugs.enlightenment.org/ http://trac.enlightenment.org/e Unfortunately these list only wishlist/todo parts. It would also be good to at least get them more visible in the context of E17 on www.enlightenment.org Depends on if the projects are using it. You can see features we're working for Ewl and the discussions we've had about how to implement them. You can also search for resolved and closed bugs to see what's implemented and complete. 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 - release
On Thu, Jul 31, 2008 at 3:24 PM, dan sinclair [EMAIL PROTECTED] wrote: Depends on if the projects are using it. You can see features we're working for Ewl and the discussions we've had about how to implement them. You can also search for resolved and closed bugs to see what's implemented and complete. dan We also set the release target, so you can tell what features/fixes are required for that release to come out. - 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] Porting E to an ARM based embedded system.
On Thu, 31 Jul 2008 21:23:53 +0200 Robert Schwebel [EMAIL PROTECTED] babbled: Hi, On Wed, Jul 23, 2008 at 05:27:35PM -0300, imx31cpu . wrote: I am new to the enlightment world and I will soon (tomorrow) start trying to port it to an embedded system (Freescale i.MX31 PDK - http://www.freescale.com/imx31pdk). Since I am not an experient developer on the linux environment I will probably have a hard time doing that so I would like to know if any of you have already tryed to do this porting or if you have any suggestion that might help me to have enlightment running on this system. Note that the i.MX31 has a PowerVR MBX graphics core which is not documented publically. What's proposed as OpenGL ES support is a proprietary blob of source code which can be get under NDA from Freescale. yeah. i have yet to see any powervr gfx chip have drivers anything other than closed for GL (and with some nda etc. attached). Note also that the Freescale ltib BSPs may differ from Linux mainline. We are working on better mainline compatiblity for i.MX31 at Pengutronix while moving the Linux port for the phyCORE-i.MX31 forward, so expect more mainline patches soon (we are still working on i.MX27 issues and they have to be finished before moving on to i.MX31). rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 - 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
Someone needs to blog all the interesting changes to cvs then submit that to places like reddit, digg and slashdot. That way people see all this interesting stuff going on and want to join in. Toma On 7/29/08, Nathan Ingersoll [EMAIL PROTECTED] wrote: Since the most recent license flamewar was triggered by the motivation of community building, I think now would be an appropriate time to brainstorm some additional ideas for helping to build the community around E. 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. Nathan - 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
That would be useful. This is a great task for someone that doesn't feel they are a developer, but can understand the CVS logs that come through. On Thu, Jul 31, 2008 at 7:44 PM, Toma [EMAIL PROTECTED] wrote: Someone needs to blog all the interesting changes to cvs then submit that to places like reddit, digg and slashdot. That way people see all this interesting stuff going on and want to join in. Toma On 7/29/08, Nathan Ingersoll [EMAIL PROTECTED] wrote: Since the most recent license flamewar was triggered by the motivation of community building, I think now would be an appropriate time to brainstorm some additional ideas for helping to build the community around E. 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. Nathan - 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
|Sorry for my bad english, fix me| I think that the e community need: 1. A website well structured. Today it is unusable!!! It should be simple! The first page has to show the power of e (with fresh screenshots, news). New graphic and new layout (the design is good but it isn't fit the usability rules). Where are e planet and exchange? 2. E planet!?! Developers and power users should few lines on e status of developement. This involves. 3. Release something and then enhance. 4. Documentation P.S. I've translated some website pages in italian... Should e italian community have an its own website, a planet like french community or may i continue to translate e pages??? 2008/8/1 Nathan Ingersoll [EMAIL PROTECTED] That would be useful. This is a great task for someone that doesn't feel they are a developer, but can understand the CVS logs that come through. On Thu, Jul 31, 2008 at 7:44 PM, Toma [EMAIL PROTECTED] wrote: Someone needs to blog all the interesting changes to cvs then submit that to places like reddit, digg and slashdot. That way people see all this interesting stuff going on and want to join in. Toma On 7/29/08, Nathan Ingersoll [EMAIL PROTECTED] wrote: Since the most recent license flamewar was triggered by the motivation of community building, I think now would be an appropriate time to brainstorm some additional ideas for helping to build the community around E. 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. Nathan - 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 - 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 Thu, Jul 31, 2008 at 11:00 PM, Downknew Wise [EMAIL PROTECTED] wrote: |Sorry for my bad english, fix me| I think that the e community need: 1. A website well structured. Today it is unusable!!! It should be simple! The first page has to show the power of e (with fresh screenshots, news). New graphic and new layout (the design is good but it isn't fit the usability rules). Where are e planet and exchange? 2. E planet!?! Developers and power users should few lines on e status of developement. This involves. FYI, there is a planet at planet.enlightenment.org 3. Release something and then enhance. 4. Documentation P.S. I've translated some website pages in italian... Should e italian community have an its own website, a planet like french community or may i continue to translate e pages??? 2008/8/1 Nathan Ingersoll [EMAIL PROTECTED] That would be useful. This is a great task for someone that doesn't feel they are a developer, but can understand the CVS logs that come through. On Thu, Jul 31, 2008 at 7:44 PM, Toma [EMAIL PROTECTED] wrote: Someone needs to blog all the interesting changes to cvs then submit that to places like reddit, digg and slashdot. That way people see all this interesting stuff going on and want to join in. Toma On 7/29/08, Nathan Ingersoll [EMAIL PROTECTED] wrote: Since the most recent license flamewar was triggered by the motivation of community building, I think now would be an appropriate time to brainstorm some additional ideas for helping to build the community around E. 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. Nathan - 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 - 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 01/08/2008, Downknew Wise [EMAIL PROTECTED] wrote: |Sorry for my bad english, fix me| I think that the e community need: 1. A website well structured. Today it is unusable!!! It should be simple! The first page has to show the power of e (with fresh screenshots, news). New graphic and new layout (the design is good but it isn't fit the usability rules). Where are e planet and exchange? The main website is a little devoid of useful links and current news. Something could be done about that. Maybe even putting a bit of planet.e.org content onto the 'News' section? 2. E planet!?! Developers and power users should few lines on e status of developement. This involves. 3. Release something and then enhance. 4. Documentation Personally, ive steered away from writing too much documentation due to point 3. Once things are released, then the documentation can stay relevant and useful. Some of the old docs that dj2 wrote are a little outdated and need of a refreshment. What kind of documentation are we talking about here? P.S. I've translated some website pages in italian... Should e italian community have an its own website, a planet like french community or may i continue to translate e pages??? LoCo's (local communities) are a great way to get people involved. You just need to find more E users to effectively have a LoCo... I only know 1 other Aussie (PythonNinja) in the E world so we'd have a pretty lonely LoCo. Toma 2008/8/1 Nathan Ingersoll [EMAIL PROTECTED] That would be useful. This is a great task for someone that doesn't feel they are a developer, but can understand the CVS logs that come through. On Thu, Jul 31, 2008 at 7:44 PM, Toma [EMAIL PROTECTED] wrote: Someone needs to blog all the interesting changes to cvs then submit that to places like reddit, digg and slashdot. That way people see all this interesting stuff going on and want to join in. Toma On 7/29/08, Nathan Ingersoll [EMAIL PROTECTED] wrote: Since the most recent license flamewar was triggered by the motivation of community building, I think now would be an appropriate time to brainstorm some additional ideas for helping to build the community around E. 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. Nathan - 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 - 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
