[E-devel] [PATCH] e ilist fix

2007-05-11 Thread Laurent Ghigonis
Hi

Here is a patch to fix some wrong behavior of E_Ilist and
E_Widget_Ilist.

Each E_Wiget_Ilist has an E_Widget_Callback list, wich contains
callbacks for each item of the list. It must have the same order /
same number of items than the real items list. And that was not the
case before :
now we update the E_Widget_Callback list on ilist_clear,
ilist_remove_num and when creating a header item, add an empty
E_Widget_Callback to the list.

I also removed a function : ilist_remove_label. It needed a rewrite,
and i didn't see the use of that function, and its not used in e.
Of course that's my opinion and if someone needs it, i'll write it.

laurent? e_confirm_dialog.patch
? ilist.patch
Index: e_ilist.c
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_ilist.c,v
retrieving revision 1.32
diff -u -r1.32 e_ilist.c
--- e_ilist.c	9 May 2007 12:54:57 -	1.32
+++ e_ilist.c	9 May 2007 21:21:57 -
@@ -332,35 +332,6 @@
E_FREE(si);
 }
 
-EAPI void 
-e_ilist_remove_label(Evas_Object *obj, const char *label) 
-{
-   Evas_List *l;
-   
-   API_ENTRY return;
-   if (!sd-items) return;
-   if (!label) return;
-   for (l = sd-items; l; l = l-next) 
- {
-	E_Ilist_Item *si;
-	char *t;
-	
-	si = l-data;
-	if (!si) continue;
-	t = strdup(edje_object_part_text_get(si-o_base, e.text.label));
-	if (!strcmp(t, label)) 
-	  {
-	 if (si-o_icon) evas_object_del(si-o_icon);
-	 evas_object_del(si-o_base);
-	 sd-items = evas_list_remove(sd-items, si);
-	 E_FREE(si);
-	 free(t);
-	 break;
-	  }
-	free(t);
- }
-}
-
 EAPI const char *
 e_ilist_nth_label_get(Evas_Object *obj, int n) 
 {
Index: e_ilist.h
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_ilist.h,v
retrieving revision 1.16
diff -u -r1.16 e_ilist.h
--- e_ilist.h	8 Jan 2007 19:23:21 -	1.16
+++ e_ilist.h	9 May 2007 21:21:57 -
@@ -39,7 +39,6 @@
 EAPI Evas_Object *e_ilist_selected_icon_get (Evas_Object *obj);
 EAPI void e_ilist_selected_geometry_get (Evas_Object *obj, Evas_Coord *x, Evas_Coord *y, Evas_Coord *w, Evas_Coord *h);
 EAPI void e_ilist_remove_num(Evas_Object *obj, int n);
-EAPI void e_ilist_remove_label  (Evas_Object *obj, const char *label);
 EAPI const char  *e_ilist_nth_label_get (Evas_Object *obj, int n);
 EAPI void e_ilist_nth_label_set (Evas_Object *obj, int n, const char *label);
 EAPI Evas_Object *e_ilist_nth_icon_get  (Evas_Object *obj, int n);
Index: e_widget_ilist.c
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_widget_ilist.c,v
retrieving revision 1.33
diff -u -r1.33 e_widget_ilist.c
--- e_widget_ilist.c	9 May 2007 19:07:58 -	1.33
+++ e_widget_ilist.c	9 May 2007 21:21:57 -
@@ -103,8 +103,12 @@
 e_widget_ilist_header_append(Evas_Object *obj, Evas_Object *icon, const char *label)
 {
E_Widget_Data *wd;
+   E_Widget_Callback *wcb;

wd = e_widget_data_get(obj);
+   wcb = E_NEW(E_Widget_Callback, 1);
+   if (!wcb) return;
+   wd-callbacks = evas_list_append(wd-callbacks, wcb);
e_ilist_append(wd-o_ilist, icon, label, 1, NULL, NULL, NULL, NULL);
if (icon) evas_object_show(icon);
 }
@@ -145,8 +149,18 @@
 e_widget_ilist_clear(Evas_Object *obj) 
 {
E_Widget_Data *wd;
+
wd = e_widget_data_get(obj);
e_ilist_clear(wd-o_ilist);
+   while (wd-callbacks)
+ {
+	E_Widget_Callback *wcb;
+	
+	wcb = wd-callbacks-data;
+	if (wcb-value) free(wcb-value);
+	free(wcb);
+	wd-callbacks = evas_list_remove_list(wd-callbacks, wd-callbacks);
+ }
 }
 
 EAPI int
@@ -281,18 +295,15 @@
 e_widget_ilist_remove_num(Evas_Object *obj, int n)
 {
E_Widget_Data *wd;
+   E_Widget_Callback *wcb;

wd = e_widget_data_get(obj);
e_ilist_remove_num(wd-o_ilist, n);
-}
-
-EAPI void
-e_widget_ilist_remove_label(Evas_Object *obj, const char *label)
-{
-   E_Widget_Data *wd;
-   
-   wd = e_widget_data_get(obj);
-   e_ilist_remove_label(wd-o_ilist, label);
+   wcb = evas_list_nth(wd-callbacks, n);
+   if (!wcb) return;
+   if (wcb-value) free(wcb-value);
+   free(wcb);
+   wd-callbacks = evas_list_remove(wd-callbacks, wcb);
 }
 
 EAPI void 
Index: e_widget_ilist.h
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_widget_ilist.h,v
retrieving revision 1.18
diff -u -r1.18 e_widget_ilist.h
--- e_widget_ilist.h	9 May 2007 19:07:58 -	1.18
+++ e_widget_ilist.h	9 May 2007 21:21:57 -
@@ -28,7 +28,6 @@
 EAPI Evas_Object *e_widget_ilist_selected_icon_get(Evas_Object *obj);
 EAPI void e_widget_ilist_unselect(Evas_Object *obj);
 EAPI void e_widget_ilist_remove_num(Evas_Object *obj, int n);
-EAPI void e_widget_ilist_remove_label(Evas_Object *obj, const char *label);
 EAPI void e_widget_ilist_multi_select_set(Evas_Object *obj, int multi);
 EAPI int  

Re: [E-devel] RFC gradient clip

2007-05-11 Thread The Rasterman
On Tue, 8 May 2007 14:42:37 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:

 I want to know how difficult would be to implement support for clip
 using gradient objects.
 
 Motivation to do so is to have clip border as fade out instead of hard
 cut. We need it for our software, Canola, but talking to Freevo guys
 show the same problem.
 
 I've already talked to raster about this issue and he suggested
 creating an overlay image with a copy of the background with alpha
 channel changed, but then comes the question raised by Tackaberry
 (freevo dev) if the background changes a lot, it couldn't be just one
 image, but the rendered background so far. How does it behave to
 retrieve rendered scene in different backends, like GL?
 
 We are willing to implement it if you give us some hints :-)

it's not as easy as it sounds. what you want is generic clipping to an mask.
that has been on the will do it one day list for a long time. so RFC-wise -
absolutely. but implementing it so its vaguely efficient will need some work.
any mask needs to be rendered first, THEN used when compositing objects. right
now evas has no clip buffer mode (all objects clipped are clipped WHEN they
are rendered, instead of being rendered to a temporary buffer first, then
clipped when finally composited to the screen). for now its clip when you
draw method is ok for most uses, but we still need it implemented.

to implement this we will need (imho) the tile cache i suggested. something
that lets you generate a surface from sources and cache just regions of it
(tiles) that are needed. this means you don't re-generate it for every object
clipped to it that needs a draw, but will allow us to cap the memory usage of
such regions during a draw.

but before leaping into this - note, this is not so simple as it needs
implementing across multiple engines and graphics api's.

 -- 
 Gustavo Sverzut Barbieri
 --
 Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
   ICQ#: 17249123
  Skype: gsbarbieri
 Mobile: +55 (81) 9927 0010
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 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]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] RFC gradient clip

2007-05-11 Thread The Rasterman
On Tue, 08 May 2007 15:28:16 -0400 Jason Tackaberry [EMAIL PROTECTED] babbled:

 On 2007-05-08 13:42, Gustavo Sverzut Barbieri wrote:
  Motivation to do so is to have clip border as fade out instead of hard
  cut. We need it for our software, Canola, but talking to Freevo guys
  show the same problem.
 
 This is definitely a big deal for us (Freevo).  We've been resorting to
 ugly hacks to get this effect in text (i.e. using Imlib2 to render the
 text to an evas image object and fiddling with the alpha channel after),
 but other hacks are increasingly impractical for use-cases that involve
 fading across multiple objects.
 
 So I'm interested in hearing any advice from those who grok evas's core
 (of which I am not even remotely one).

the advice is i would like this and it would be good but its not trivial to
do right/well and right now i really don't have the time to do it - thus it's
one of those backburner when i get to it things.

 Off topic now, but some other shortcomings that are an issue for us:
 
1. Lack of 3D transformations (on 2D objects).  Gustavo has said he
   has a proposal for adding this, which is very nice to hear.

actually - he wants 2d transforms (rotate, shear, scale, translate). but you
can do enough with 2d.

2. GL engine a second class citizen. I sometimes read on e-devel
   about how this or that isn't working properly in the GL engine. 
   At some point configure was updated to no longer build it by
   default.  I'm afraid one day I'll do a svn update and discover
   raster has removed it because it was half working and nobody cared
   about it.  [I care! :)]

yes - it is 2n'd class - but it won't be removed. did you notice i added
yuv-rgb fragment shader accel to the engine recently? it isn't dead - its just
not a primary devel path.

3. Lack of subpixel precision.  Makes stuff like the Ken Burns Effect
   impossible (or possible, but lame).   However this is probably not
   practical without a big evas rewrite.  I did just have the idea
   that we could get halfpel by creating a canvas size twice the
   display resolution and set the viewport to the display resolution
   -- but that option won't work since viewport feature was removed. 
   Other options require buffer canvas hacks.

it never would have worked even with the viewport before as evas just converted
it to a 1:1 buffer. this is actually quite possible to be done - and in fact
fairly easy - at least for the software engines. BUT its expensive as evas will
need to render 4x or more the data. also co-ordinates are integer and converted
to output co-ord space which is assumed to be 1:1 with canvas space. the engine
api assumes 1:1 so i simply percolated that up to the evas api not as a hard
requirement, but as a soft-requirement. api is still in theory capable of doing
the large canvas-space viewport, but the expense of writing to such a
canvas will be very high. you want half-pel then you will pay 4x the price of
rendering.

 
 Anyway, thought I'd just mention this stuff so they're in the right
 people's minds. :)
 
 Jason.
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 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]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] RFC evas_object_transform()

2007-05-11 Thread The Rasterman
On Tue, 8 May 2007 16:37:35 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:

 As Jason Tackaberry said on the other thread, here comes my proposal
 for 3d transformation for 2d objects. I've discussed this with
 raster at bossa conference.
 
 My proposal was born to solve the missing rotate, that if solved
 would still raise missing shear, etc.. Raster said he don't have a
 _rotate() method yet because he couldn't get it as fast as possible on
 each engine.
 
 Since many operations can be handled by transform matrix and some
 engines (ie: GL), can handle it fast, just expose:
void evas_object_transform(Evas_Object *obj, double matrix[4][4])
 Given one knows how to fill the coefficients he can achieve his
 rotation/shear/... goals and it will be fast as hell on GL. Other
 engines will not run as fast, but it'll be up to the user to handle
 that.
 
 This would enable fancy beryl-like effects inside Evas, wanted by
 Freevo guys. This may also be used by embedded devices given OpenGL/ES
 support.

this is perfectly possible and on the list of things i'd like to see evas get
(eventually) but again like most things. it gets expensive to do AND keep
high-quality AND high-speed. rotation is a subset of transform matrix fun and
probably the most common use of them after scaling. the only other things we
would miss is shearing. a transform makes it very generic - but transform
matricies generally tend to be much more painful to work with than simple
rotate/scale calls. i'd personally like to have both. use the matrix OR just
use the resize/fill/(and later rotate) calls.

 -- 
 Gustavo Sverzut Barbieri
 --
 Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
   ICQ#: 17249123
  Skype: gsbarbieri
 Mobile: +55 (81) 9927 0010
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 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]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Look who's back

2007-05-11 Thread The Rasterman
On Thu, 03 May 2007 13:38:08 +0100 Essien Ita Essien [EMAIL PROTECTED]
babbled:

 Heya ppls,
 
 Just kinda wanted to ping all ma ppls and fellows of the raster harem 
 (yup... we're all beyatchis!). I'd gotten pretty tied up on a lot of 
 fronts and lots of changes have happened in a short while - I got 
 friggin married!!! :)

congrats :)

 Anyways... things are beginning to slow down again, and I'll be able to 
 get back to some keyboard punching and head banging...err... code design 
 and development :P - on entrance and entrance_edit_gui
 
 I noticed that while I was away... we got the brand new spanking server 
 we'd always wanted (yay!) and the new website effort is underway (double 
 yay!). I wanted to find out what's the current status (if there is 
 anyway) of a plan for a bug tracker for enlightenment, or a central 
 bugtracking system which the various different projects can use.

did u check bugs.enlightenment.org? :)

 I'm asking because I wanted to request for all that have sent bugs to 
 the mailing list concerning entrance/entrance_edit_gui to submit them to 
 a central place, for easier management.
 
 If i remember well, there's been some hints and suggestions of bug 
 tracking before, though i can't remember the conclusion(s) of those 
 discoursions. I do think though that now we have a server, we *may* want 
 to look seriously into it. I personally have to particular preference, 
 so anyone will do, just the fact that we're using it is more important 
 (i think).
 
 Anyways... so much bandwidth used up just to say... wassup peeps.
 
 Cheers,
 Essien
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 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]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] RFC evas_object_transform()

2007-05-11 Thread The Rasterman
On Wed, 9 May 2007 00:51:14 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled:

 
  
  [things about transforms and such]
  
 
   Most of this, and clipping (and some other things), are coming
 hopefully within this month or so. But there are things you should
 be aware of.
 
   Generally speaking, it's not too difficult to do any of these
 things - especially if one is willing to forgo some quality and/or
 some speed.. but even then, getting this in evas requires a fairly
 large rewrite of the engine level internals.

indeed - i have a non-trivial queue of mails from you all on this topic! :)

   In evas however we have further things to deal with, especially
 when it comes to image objects and 'transforms'. A 'fast' software
 implementation for rotations is really not an issue.
 
   Image objects in evas have these 'border' attributes which
 actually make them into a compound, structured object.. not just a
 simple image in the sense that most libs deal with. Also, we want
 fairly 'high quality' software down-scaling, which again most libs
 bypass by using eg. bilinear interpolation (which gives a 'decent'
 means for implementing tarnsforms).

you missed the fact that a transformed object now is no longer an aligned
rectangle - so the event engine needs a big change to handle mouse move, in and
out events etc. :) we need to now handle transformed regions for objects - or
do we? do we just expand the event rect to be the bounds of the whole object?
what about clipping. right now clips also clip the event area.

personally, as an intermediate-step i'd like to simply be able to modify the
FILL of an image (or text object) so the FILL can be transformed (we need to be
able to disable tiling for images). this will then allow for us to provide
transformed image data but within a rect - allowing us to worry about events
later but get the benefits of the visual elements now.

   These two aspects together make for something more complex
 than what is found in most other libs that deal with 'images' and
 'transforms'.
   One should realize that in order to satisfy these, setting
 a transform on an image object is going to mean apply the trans
 to the result of the image obj's fill. Only sometimes will we be
 able to compose the transform with the fill scaling and do it all
 in a single pass. It doesn't matter what the 'rendering' engine,
 ie. wether it's software or xrender or gl or whatever.. this will
 always come up with scaling+borders.

aye. borders also complicate things a lot.

   Applying transforms to objects like rects and gradients is
 simpler (I'll refrain from mentioning styled text objs or textblock
 objs), but for compound objects like smart-objs one needs to make
 some decisions.

text and textblock objects likely will need to be pre-rendered to a buffer then
have that buffer transformed. :(

   One can apply the transform to each member obj of the smart
 object.. and things may end up not 'lining-up' as desired. Or one
 can apply the trans to the result of rendering the untransformed
 smart object.. and then there will be its own set of 'issues'.
   [NB: One can't, in general, decompose a transform into a
 simple rotation plus scaling plus a simple shearing -- you can
 at best get something like a scaling plus a generalized rotation
 where you rotate each of the two axis differently.. and this is
 just for non-projective transforms.]

yup. you can convert a scale + rotate INTO a transform matrix, but not the
other way around (easily).

   The notion of a transformable interface is something
 that I think has been too quickly hyped and is going to be rather
 tricky to actually achieve -- if one wants good-looking results
 and an un-ambiguous semantics.. I don't think the SVG 'spec' alone
 will give that.
 
 
jose.
 
 
 
 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 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]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] e ilist fix

2007-05-11 Thread The Rasterman
On Fri, 11 May 2007 19:01:32 +0200 Laurent Ghigonis [EMAIL PROTECTED]
babbled:

 Hi
 
 Here is a patch to fix some wrong behavior of E_Ilist and
 E_Widget_Ilist.
 
 Each E_Wiget_Ilist has an E_Widget_Callback list, wich contains
 callbacks for each item of the list. It must have the same order /
 same number of items than the real items list. And that was not the
 case before :
 now we update the E_Widget_Callback list on ilist_clear,
 ilist_remove_num and when creating a header item, add an empty
 E_Widget_Callback to the list.
 
 I also removed a function : ilist_remove_label. It needed a rewrite,
 and i didn't see the use of that function, and its not used in e.
 Of course that's my opinion and if someone needs it, i'll write it.

indeed there seems to have been some bit-rot there with expanding api's and
things not doing memory management right. patch in cvs.

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] translate enlightenment 17 into catalan language

2007-05-11 Thread The Rasterman
On Fri, 11 May 2007 19:37:46 +0200 Marc Furtià i Puig [EMAIL PROTECTED]
babbled:

 Hello, i'm translating e-17 into catalan language, i puts the ca.po file
 into this e-mail and ca.mo too.
 I'm translating only e for now, but i want translate all into this
 language.
 How can i set my translatinon of e-17 into cvs repos ?
 Thank's for all :)
 See you soon.
 (sorry for my bad english, i don't know english very well :( )

ca.po is not in CVS. :)


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel