Re: [E-devel] [e-users] Exchange - A new place to trade themes and showcase applications and modules.

2008-07-26 Thread Dave Andreoli

- "Andrew G. Stack" <[EMAIL PROTECTED]> ha scritto:

> Hi all,
> 
> The new site looks nice -- I like the fact that it has nice big
> screen
> shots and I'm sure it will be less work for morlenxus. :)  I'm
> traveling right now but as soon as I get back I'll get to work on an
> updated version of steampunk and upload it (I want to theme a few
> more
> modules first).  
> 
> One question I have regarding the themes:  let's say I was a new user
> and wanted to download "a theme" for e17.  Where would I look?  It
> seems the themes section is divided up into all the parts of e17 but
> there is no option for just an e17 theme.  Obviously there is no
> clear
> definition for what a complete e17 theme might be, for example, mine
> is
> missing quite a few parts like entrance, etk & ewl widgets, etc., but
> it seems like an additional tab under themes for e17 themes would be
> nice.  Or maybe a way to rank the themes based on the completeness of
> their included list?  So if I just want to download something to
> replace the default e17 theme I can browse some of the more complete
> themes and pick one.

I agree: for a new user is such confusing. And another request: IMO we miss
an 'homepage' field in apps/modules, for example penguins is in cvs and 
I don't know where to put the link to the penguins page.
Also should be usefull to have the ability to upload more than 1 screenshot.

Just my two cents...
Thanks
Dave

> 
> Cheers,
> Andrew
> (Rooster)
> 
> --- Toma <[EMAIL PROTECTED]> wrote:
> 
> > Ladies and Gentlemen!
> > 
> > We are proud to announce the launch of Exchange:
> > http://www.exchange.enlightenment.org
> > 
> > This is a new website for exchanging themes, efl based applications
> > and modules for these applications. It was built specifically for
> E,
> > and therefore takes advantage of some of the features of edje to
> > automatically detect themes and allow users
> > to find themes for exactly what they want to theme.
> > 
> > Its also a nice place to showcase your applications and will
> > hopefully
> > become a central location for people to look for EFL based apps.
> > 
> > We ask that developers and themers all spend a couple minutes
> looking
> > around, create an account and upload some content as the only work
> on
> > there so far is a few modules and all of my work. Remember, this is
> a
> > great way to get some feedback on your content and for users to
> show
> > some appreciation for all your hard effort!
> > 
> > 
> > For those that want to develop apps that pull/push themes from the
> > Exchange, we have a full API documented here:
> > http://code.google.com/p/e17-exchange/wiki/ExchangeAPI (please
> direct
> > any questions about the API to iamsthitha)
> > 
> > mcalamelli is already working on an application that will let you
> > download and install themes from exchange without having to visit
> the
> > website and go through the hassle of installing them.
> > http://staff.get-e.org/?p=users/mcalamelli/exchange.git;a=summary
> > (this is still in very early stages as of today, but is something
> to
> > keep an eye on!)
> > 
> >
> -
> > 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=100&url=/
> > ___
> > enlightenment-users mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> > 
> 
> 
> 
>   
> 
> -
> 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=100&url=/
> ___
> enlightenment-users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users

-
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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Exchange - A new place to trade themes and showcase applications and modules.

2008-07-26 Thread Toma
Renaming widgets to E17 theme might work since that group covers the
main e17 interface.
Toma

On 7/26/08, Dave Andreoli <[EMAIL PROTECTED]> wrote:
>
> - "Andrew G. Stack" <[EMAIL PROTECTED]> ha scritto:
>
>> Hi all,
>>
>> The new site looks nice -- I like the fact that it has nice big
>> screen
>> shots and I'm sure it will be less work for morlenxus. :)  I'm
>> traveling right now but as soon as I get back I'll get to work on an
>> updated version of steampunk and upload it (I want to theme a few
>> more
>> modules first).
>>
>> One question I have regarding the themes:  let's say I was a new user
>> and wanted to download "a theme" for e17.  Where would I look?  It
>> seems the themes section is divided up into all the parts of e17 but
>> there is no option for just an e17 theme.  Obviously there is no
>> clear
>> definition for what a complete e17 theme might be, for example, mine
>> is
>> missing quite a few parts like entrance, etk & ewl widgets, etc., but
>> it seems like an additional tab under themes for e17 themes would be
>> nice.  Or maybe a way to rank the themes based on the completeness of
>> their included list?  So if I just want to download something to
>> replace the default e17 theme I can browse some of the more complete
>> themes and pick one.
>
> I agree: for a new user is such confusing. And another request: IMO we miss
> an 'homepage' field in apps/modules, for example penguins is in cvs and
> I don't know where to put the link to the penguins page.
> Also should be usefull to have the ability to upload more than 1 screenshot.
>
> Just my two cents...
> Thanks
> Dave
>
>>
>> Cheers,
>> Andrew
>> (Rooster)
>>
>> --- Toma <[EMAIL PROTECTED]> wrote:
>>
>> > Ladies and Gentlemen!
>> >
>> > We are proud to announce the launch of Exchange:
>> > http://www.exchange.enlightenment.org
>> >
>> > This is a new website for exchanging themes, efl based applications
>> > and modules for these applications. It was built specifically for
>> E,
>> > and therefore takes advantage of some of the features of edje to
>> > automatically detect themes and allow users
>> > to find themes for exactly what they want to theme.
>> >
>> > Its also a nice place to showcase your applications and will
>> > hopefully
>> > become a central location for people to look for EFL based apps.
>> >
>> > We ask that developers and themers all spend a couple minutes
>> looking
>> > around, create an account and upload some content as the only work
>> on
>> > there so far is a few modules and all of my work. Remember, this is
>> a
>> > great way to get some feedback on your content and for users to
>> show
>> > some appreciation for all your hard effort!
>> >
>> >
>> > For those that want to develop apps that pull/push themes from the
>> > Exchange, we have a full API documented here:
>> > http://code.google.com/p/e17-exchange/wiki/ExchangeAPI (please
>> direct
>> > any questions about the API to iamsthitha)
>> >
>> > mcalamelli is already working on an application that will let you
>> > download and install themes from exchange without having to visit
>> the
>> > website and go through the hassle of installing them.
>> > http://staff.get-e.org/?p=users/mcalamelli/exchange.git;a=summary
>> > (this is still in very early stages as of today, but is something
>> to
>> > keep an eye on!)
>> >
>> >
>> -
>> > 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=100&url=/
>> > ___
>> > enlightenment-users mailing list
>> > [EMAIL PROTECTED]
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>> >
>>
>>
>>
>>
>>
>> -
>> 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=100&url=/
>> ___
>> enlightenment-users mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
> -
> 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=100&url=/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@l

Re: [E-devel] [Evas] possible bug in gradient

2008-07-26 Thread The Rasterman
On Wed, 09 Jul 2008 19:33:14 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:

it's a matter of how high level you want the api. in fact your end api (the
minimal one) is exactly what my original gradient api had.. just add a point a
distance from another with a color - it's linear interpolation. clear it and
re-fill it again when you want to change i. if you want different interpolation
types (logarithmic, etc.) a higher level api can break this down int a series
of linear interp points. the more points - the better the quality. the other
option is to be able to define gradient interp point angles(like defining a
spline curve...) but evas has nothing for that currently... so a simple linear
point api means there is less to worry about... for now :)

but i've never been into gradients. personally. so i am not the one to comment.
i'm no expert nor do i have vested interests. so don't take my comments too
seriously.

>  So, if anyone has any comments, suggestions, issues.. *anything* with
>  evas gradients -- now would be a good time to pipe in. :)
>  
> >>>
> >>> I'd _love_ using gradients, in fact I would use them much more 
> >>> often, _if_ not everytime I start using them, it all feels like I'm 
> >>> operating a powerful machine that has 100s of controls and I don't 
> >>> understand anything.
> >>>
> >>> Perhaps this is an inherent problem from the gradient complexity, 
> >>> but I'd appreciate if we had some documentary material that outlines 
> >>> how to achieve which kind of results, which gradient type to use for 
> >>> what, how many stops for what effect etc. etc.
> >>>   
> >>
> >>  Ok, let me try and give you a fairly simplified description of what
> >> gradients are basically about, and how evas tries to deal with this.. 
> >> for
> >> better or worse.
> >>
> >> ...
> >> ...
> >> ...But to get back to the subject at hand here, and 
> >> before going on to give
> >> more details on current evas gradients, let me ask you this:
> >> How would you answer the above two 'general' questions.. or rather, 
> >> what would
> >> *you* like to see as an api that would make you want to use gradients 
> >> more?
> >>
> >
> >  Not much time to reflect on this? Well, that's understandable :)
> > Let me go ahead and review the current set of gradient api funcs in evas,
> > give some criticisms, and propose some changes I'd like to make to 
> > improve
> > things there (and yes, they would break all gradient stuff).
> >
> >  First, recall I mentioned the two parts involved in gradients:
> > 1) Those aspects related to defining a 1-dim image (or "spectrum" as I
> >   sometimes call it).
> > 2) Those aspects related to defining how to map the above to a 2-dim
> >   region - and this covers things like the gradient type, spread-mode,
> >   and such things.
> >
> >  Ok, for (1) in evas we currently have the following (set) api funcs:
> >
> > void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta);
> > void evas_object_gradient_alpha_stop_add(obj, a, int delta);
> > void evas_object_gradient_color_data_set(obj, *data, len, has_alpha);
> > void evas_object_gradient_alpha_data_set(obj, *data, len);
> > void evas_object_gradient_direction_set(obj, *data, int direction);
> > void evas_object_gradient_offset_set(obj, *data, float offset);
> > and also,
> > void evas_object_gradient_clear(obj);
> >
> >  The 'clear' api func removes any stops or data that might have been
> > set before.
> >  The 'offset' api func effectively moves the origin of the 1-dim 
> > image,
> > this is something that as far as I know isn't supported by any vgfx 
> > api/spec
> > (which is unfortunate since it can give very nice animation effects 
> > which are
> > otherwise difficult to obtain for some gradient types, eg. radial ones).
> >  The 'direction' api func just reverses the start/end of the 1-dim,
> > and though not directly supported by most vgfx apis/specs, it can be 
> > easily
> > obtained - it's mostly a simple convenience function.
> >  The 'color_data' and 'alpha_data' api funcs are to allow for setting
> > such a 1-dim image with premul and alpha-only data, rather than going 
> > thru
> > any kind of procedural description. It's not supported by any vgfx 
> > api/spec
> > that I know of, not directly anyway.. though you can certainly 
> > consider such
> > data as an equi-distant set of stops and add it that way (modulo some 
> > gymnastics
> > with premul data and alpha masks and such).
> >
> >  The 'color_stop' and 'alpha_stop' api funcs evas' current procedural
> > descriptions for defining the spectrum -- and these I have real issues 
> > with.
> >
> >  Not only is this method of specifying stops not supported by any
> > 'standard' vgfx api/spec, the use of the "int delta" as either some kind
> > of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and 
> > very
> > difficult to work with for gui editors and such.
> >  I p

Re: [E-devel] [Patch] Escaping of single quotes in Efreet_Desktop

2008-07-26 Thread The Rasterman
On Sun, 6 Jul 2008 14:42:27 +0400 [EMAIL PROTECTED] babbled:

sorry - it's already in cvs... :)  just no response on the mail! :) sorry! :)

> Since no one responded in 3 months and the bug is still there, I'd like to
> bump it up. BTW, there is a bug in Bugzilla about this:
> http://bugzilla.enlightenment.org/show_bug.cgi?id=395
> 
> On Wed, Mar 26, 2008 at 3:47 AM, Гусев Фёдор <[EMAIL PROTECTED]> wrote:
> > Hello.
> >
> > From bash manpage: A single quote may not occur between single quotes,
> > even when preceded by a backslash. Thus, current quoting does not work
> > for files with a single quote in the name. Like
> >
> > Someone's speech.avi
> >
> > Currently, efreet will quote this to
> >
> > 'Someone\'s speech.avi'
> >
> > Obviously, this is not right. Attached patch does the quoting as follows:
> >
> > 'Someone'\''s speech.avi'
> >
> > I found this solution somewhere on the internet.
> >
> > --
> > Sincerely yours, Fedor Gusev.
> >
> -- 
> С уважением, Гусев Ф.Е.


-- 
- 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Epsilon custom thumb size

2008-07-26 Thread The Rasterman
On Thu, 29 May 2008 19:21:25 -0300 "Leo Sobral Cunha"
<[EMAIL PROTECTED]> babbled:

i'm all about having more control possible -and custom thumb sizes...
definitely helps! so patch - in! :)

> hi,
> 
> During the development of canola, we had the requirement of generating
> thumbnails in any size, different from those specified at
> freedesktop's spec.
> At that moment we kept some internal ugly patches to do so, but I
> think this could be an interesting use case for various apps.
> 
> Attached is an initial patch of an api for setting a custom geometry
> and dir path for the thumbs. This patch can be improved (now it is
> checking the dir path every time, etc),
> but I just want to know if this is of interest to be included upstream
> in epsilon. In this api one of the orientations (w or h) can be
> negative, indicating that there is no maximum
> size restriction (for example, fixed height thumbnails that keep the
> aspect ratio, we use this in canola :).
> 
> Another point I wanted to note, is that now epsilon is just generating
> PNG thumbnails and this is ~3 times slower than JPG in mobile devices
> (N800, maemo).
> It would be interesting to maintain the option of generating JPG thumbs.
> 
> Should epsilon just generate thumbs in freedesktop's spec?
> I think that it would not hurt to provide these extra features for
> applications outside the desktop context.
> 
> Any comments are appreciated.
> 
> BR,
> -- 
> // leo
> 
> ---
> Leonardo Sobral Cunha
> OpenBossa Labs
> INdT - Instituto Nokia de Tecnologia
> PGP: 0x5751676C @ wwwkeys.pgp.net
> ---
> 


-- 
- 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Tiling module: new URL and merge request

2008-07-26 Thread The Rasterman
On Sun, 1 Jun 2008 22:57:06 +0200 Michael Stapelberg  babbled:

yeah. sorry - am busy. ummm... cvs eh? then we need to give you cvs access. can
you hold off for a while longer - i need to do some catching up...

> Hi,
> 
> I've just now migrated the tiling module from the old server dev.twice-irc.de
> to code.stapelberg.de with a working CACert-SSL-certificate and IPv6-support.
> You can now find it at
> https://code.stapelberg.de/git/?p=e17-tiling/.git;a=summary To change your
> git-repository, just edit .git/config and replace the old URL with
> git://code.stapelberg.de/e17-tiling
> 
> Of course, the mirror at staff.get-e.org still exists.
> 
> Furthermore, I now consider the module stable. I've been using it for nearly
> two months and yesterday I fixed the only bug I've encountered during these
> two months (only showed up when using xinerama).
> 
> Therefore, I'd be happy to see it in official CVS. I've mailed raster about
> this, but he seems to be quite busy. If anyone of you wants to merge, please
> apply the included desk.patch to apps/e/src/bin first and then put the module
> in e_modules/tiling - thanks!
> 
> Best regards,
> Michael
> 
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] How to display a custom animated bitmap in evas/edje?

2008-07-26 Thread The Rasterman
On Fri, 06 Jun 2008 15:08:44 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:

>Cedric wrote:
> 
> > I did some test around this and I think it came from the fact that
> > o->dirty_pixels is not set to 1 after the second call to
> > evas_object_image_size_set. A quick fix for your example is to call
> > evas_object_image_pixels_dirty_set just after
> > evas_object_image_size_set. I currently don't know enough to properly
> > fix evas, but this could help others find the right solution.
> >   
> 
>   Well, the semantics of the image-size-set function has always
> been that if there is no data or file for the image, it will create
> data of the requested size, and if there is data (possibly from a
> file), it will create new data of the requested size and copy as much
> as possible of the current data to the new one and then set that new
> one as the current data.

actually that depends - eys. this is the case... *IF* the data is
malloced/controlled by evas. if it's set from an external pointer - evas doesn't
touch it.. it's up to the application that set the pixel data to reset it to
the new data - if needed.

>   So, for the test program there, after the inital rendering
> (of a blue area), when the resize is called the image would have
> new data (not the provided pixels) one pixel less in width, so the
> subsequent ecore induced rendering would still show the same result
> (even though there's no further call to 'set data' as the callback
> won't get triggered since 'dirty pixels' isn't called again, and
> it's been unset after the first rendering).
> 
>   This would seem to show some new problem with the 'image-resize'
> function when external data has been set before on the image.. and
> indeed if I get rid of the pixels callback and simply set the data
> (after the initial image size setting), then the problem is still
> there even without the first call to evas render.. ie. the second
> call to image-size-set seems to be the culprit.

i need to make some more extensive tests for this in expedite - but expedite
does that test code for setting data - but it it only makes uses of external
data in yuv - and then the external data is only the yuv planes. the plane
pointerlist that is internal to evas is managed by evas, so i don't actually
test this case... which i should.

> 
> Click here to choose from a huge selection of shipping supplies!
> http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3n4Viav5LsS9677sjCU7lfWs22zXRdg638OZwylwP7y0XmIv/
> 
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [RFC] Evas_Object_Polygons speed improvements

2008-07-26 Thread The Rasterman
On Wed, 11 Jun 2008 17:38:35 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:

> Hi,
> 
>I wanted to improve evas polygons. In the current situation, we
> need to setup and destroy each polygon every time we call evas_render.
> It would be nice to make it survive during two call to evas_render and
> being able to modify it a little bit. Moving it around and adding
> point would be nice to have. So here is a patch that just give this
> possibility. Older code should still work fine, but as I only know one
> app that use it (expedite) I need your comment on this stuff.
> 
>Of course, this improve speed for the OpenGL engine from something
> around 650 to something around 800.
> 
> As always have fun with this patch :-)

this is fair enough. being able to move a poly around is useful - and resize
would also be... :) but isn't implemented in this patch. the polygon code
frankly is nothing more than a checkbox item tho... that's why its so poorly
handled and supported. jose has some good points - he's right. returning a list
would be useful. i tried to make it as simple as possible as i really had no
need for vector graphics (when i wrote it) so to keep support to a minimum.

overall it may be a good idea just to put this on hold for a whole
vector-graphics revamp of evas? maybe replace poly objects with "vgfx" objects
that can contain whole paths, with gradients, etc. etc. and multiple paths etc
(ie a vgfx object could be a whole svg graphic for example, or multiple vgfx
objects could produce a svg object etc.)

so you basically move/resize the vgfx object - it is more of a classic object
and behaves like one (like an image object). to modify the polygon - or vgfx...
you dig into the vgfx object and play around... this would also nuke the line
object (probably a good thing!)...

and this of course links on to later threads :)

-- 
- 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Line + width support.

2008-07-26 Thread The Rasterman
On Tue, 20 May 2008 10:14:48 -0300 "Diego Bitencourt Contezini"
<[EMAIL PROTECTED]> babbled:

hmm. i'd rather hold here in favor of a much more... expansive set of vgfx
support... and nail this kind of thing all in one shot.

> We decided to improve the line implementation to speed up the use of
> evas-lines in python (our case). Yes, we could just use polygons, but we are
> trying to reduce processor usage at this point.
> Its faster to draw lines (with lines implementation) directly, specially
> dealing with vertical/horizontal/45 deg. lines.
> Calculating where points of polygons must be drawn relative to width of line
> in python-side is a lost of processing too.
> 
> Being faster, simpler and without breaking any compatibility, I dont know
> why Lines should not to have width support. Specially thinking about how
> simpler it makes to work with Lines.
> Yes, the code may be optimized, but its working fine and fast here.
> 
> Greetings,
> 
> Diego B. Contezini
> 
> On Sun, May 18, 2008 at 11:51 PM, The Rasterman Carsten Haitzler <
> [EMAIL PROTECTED]> wrote:
> 
> > On Tue, 13 May 2008 17:20:27 -0300 "Diego Bitencourt Contezini"
> > <[EMAIL PROTECTED]> babbled:
> >
> > any reason you didnt just use polygons? :)
> >
> > > Hello all.
> > > Working with evas+Lines in python, is fast. But if you need a line with
> > more
> > > then one pixel of width, it gets very slow (in dispositives like N800),
> > > because object Line dont have width support, so its needen to use
> > Rectangles
> > > to make it works.
> > >
> > > I made a modification to support width in Lines object. It is composed by
> > 3
> > > patchs.
> > > *First*, in evas/lib/*, it changes internal call to engine line drawer,
> > > inserting more one argument to the same function. It is a callback, so,
> > no
> > > modification is needen in any engine module that dosnt support Lines with
> > > more then 1 pixel (they will just draw with only 1 pixel). Has added new
> > > functions to deal with width, without breaking any compatibility of other
> > > functions.
> > > *Second*, in evas/engine/software16 to add support to width.
> > > *Third,* in python-evas binding, to add support to use the modifications
> > > made in evas.
> > >
> > > If anyone get any bug or suggest any modification to patch, im a
> > listener.
> > >
> > > Thanks all
> > >
> > > Diego Bitencourt Contezini
> > >
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
> >
> >
> 


-- 
- 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [RFC] Async preload of image data

2008-07-26 Thread The Rasterman
On Tue, 24 Jun 2008 09:51:37 -0300 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:

> On Mon, Jun 23, 2008 at 1:14 PM, The Rasterman Carsten Haitzler
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 18 Jun 2008 18:53:06 +0200 "Cedric BAIL" <[EMAIL PROTECTED]>
> > babbled:
> >
> >> Hi,
> >>
> >>   Here is a patch that add support for background preloading of a data
> >> image. You can now, if you know what you do, ask evas to load the data
> >> of an image in memory before it is displayed (look at the sample code
> >> for expedite).
> >>
> >>   The code is quite simple, we have now a work queue where we add all
> >> the Image_Entry we need to preload. They are processed one after the
> >> other in another thread. When it's done, it notify evas main thread
> >> with evas async API and work on the next Image_Entry.
> >>
> >>   This means that we now require that engine surface creation and
> >> loader should be thread safe. It's currently the case for all the
> >> engine I know something about, so this should not break anything.
> >> Anyway this code is optionnal and could be completely unactivated in a
> >> per engine basis or globally.
> >>
> >> As always have fun reviewing this patch.
> >
> > hmmm - i like the idea - yes. missing cache surface alloc mutex :( that
> > should not be hard to add - a little bit of extra code. also missing Evas.h
> > prototype for exporting the preload call. looks like most engines have the
> > calls supported. the problem is what to do out fd'with the locks on alloc.
> > as such it is unlikely to cause problems as it stands in the patch - but
> > may if the alloc happens while deleting/freeing an image. the images
> > themselves all need locks now for anything accessing them.
> >
> > for other comments. i dont think we need to worry about fd's - the async fd
> > is wrapped already. we dont need fd's internally in the async loader
> > backend as it is by nature thread-aware and thus can and will use pthread
> > primtitives and can use them for internal syncronisation or anything it
> > likes. look at the evas pipe thread code - it doesnt use any fd's because
> > it doesnt need to use them. there is no NEED for it to wake up select. i
> > dont think u need to worry about this. we need to worry about the locks now
> > needed on all images as the surface alloc is async to the mainloop.
> > mainloop may do other things (like begin to use the image for other things
> > while the async thread is allocing and hasnt been cancelled yet). the safe
> > solution as above is locks on all images - but this is kind of ugly. i'd
> > rather have this be less invasive in this department. but this means all
> > operations on images need a mutex lock/unlock. :(
> 
> I strongly disagree, see my examples, using that will make your life
> much easier. The idea is very simple, the worker thread doesn't even
> need a select, it can just sleep on read() and that's it. Ok, you can
> do that with pthread_* primitives, but I don't see why. You get images
> to process, you send them to the thread, that keeps a "to do" list,
> process by priority order. These images (actually the structure that
> points to it) will be marked with the priority and the state (todo,
> done, canceled, ...) and it will all work well without any locks.
> Summary: worker thread just look at some flag, if it's PROCESS then
> put the pixels, notify back. No image allocation/free should be done
> on the worker thread, thus no locks.

i honestly think its much of a muchness. as it stands there is a simple single
fd that the threads use pthread constructs to wake it up and write messages to
it to wake up the process. with many fd's you need to read one and write to
another... as evas only has 1 async fd... so for the work queue going out to
the thread - yes, but for incoming back to the process to say "hey - stuff
happened - wake up!" we really need just 1... and thus pthread lock stuff around
it to avoid it filling with garbage (if the data is large being written and has
meaning. right now it isn't - but it may... one day).

> Also, giving the use case, I'd avoid locks on images and alloc them on

i absolutely agree on this. the fewer locks, the better!

> the main thread before requesting it to be loaded, this way no pointer
> will change, just the contents of it, then no problem. This will make

yup. if just the image data is by workers without locks - this is fine...
except for freeing - the main thread can't free the image until workers have
stopped filling it... so you need to be able to kill them off reliably before
you free.

> life much easier for a feature that is just aimed to make application
> not block while reads huge images from slow access memory (disk),
> avoiding complications on the existing code paths.

yes. it is a nice feature. for small images and absolutely necessary images for
the ui (eg buttons and widgets) you want to block as the ui is pretty useless
without them or with them partially loaded, but the abilit

Re: [E-devel] [PATCH] Theme fetcher

2008-07-26 Thread The Rasterman
On Mon, 30 Jun 2008 13:53:54 +0200 Massimiliano Calamelli
<[EMAIL PROTECTED]> babbled:

i'll repeat. i love the idea... and this is cool. :)

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi devs, i applied the work on wallpaper fetcher to themes, and with
> the attached patch we can get themes directly from get-e.org
> The fetcher works on the same way used by wallpaper. 
> Having ecore with curl support, on "Theme selector" appears a "Online"
> button, on next dialog click on get-e.org entry, wait for feed parsing
> and download of thumbs, then select the theme you want and click "OK".
> Et voila.
> 
> Regards
> 
> Massimiliano
> - -- 
> Massimiliano Calamelli
> http://mcalamelli.netsons.org
> [EMAIL PROTECTED]
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (MingW32)
> 
> iD8DBQFIaMlUleGEL56NNP4RAov+AJ9C5PKn1P+P50lAJw/DoiKzxWJLoQCgnbUa
> Wmebh4jLRs/k6AYrr7FTld8=
> =ng0X
> -END PGP SIGNATURE-
> 


-- 
- 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Theme version and name

2008-07-26 Thread The Rasterman
On Tue, 1 Jul 2008 23:30:45 +0800 Toma <[EMAIL PROTECTED]> babbled:

i like. :)

> Heres what Ive just spent the last 30 mins doing...
> 
> data {
>   item: "e/theme/name""Fireball";
>   item: "e/theme/version" "1.6";
>   item: "e/theme/license" "GPL";
>   item: "e/theme/author"  "Tom Haste ([EMAIL PROTECTED])";
> }
> 
> ---
> 
> data {
>   item: "etk/theme/name"  "Fireball-ETK";
>   item: "etk/theme/version"   "1.1";
>   item: "etk/theme/license"   "GPL";
>   item: "e/theme/author"  "Tom Haste ([EMAIL PROTECTED])";
> }
> 
> -
> 
> data {
>   item: "/theme/name" "Fireball-EWL";
>   item: "/theme/version" "1.2";
>   item: "/theme/license" "CC License:
> http://creativecommons.org/licenses/by-sa/2.5";;
>   item: "/theme/author" "Tom Haste ([EMAIL PROTECTED]) & dj2
> (www.everburning.com)";
>   item: "/theme/font_path" "fonts";
> }
> 
> ---
> 
> data {
>   item: "/theme/name" "Fireball-Entrance";
>   item: "/theme/version"  "1.1";
>   item: "/theme/license"  "GPL";
>   item: "/theme/author"   "Tom Haste ([EMAIL PROTECTED])";
> }
> 
> 
> 
> As you can see, the version string is for the theme itself. The naming
> I tried to stick to what its actually themeing and in the case of EWL,
> I just went with what was already there. Entrance on the other hand,
> is a bit of a mess in terms of group names so I just went with
> /theme/blah.
> 
> Providing a 'Works with this version' tag is a pain. Im not going to
> make themes for different snapshots and CVS. There is only 1 "version"
> IMHO and thats CVS.  Much like how I dont put version numbers in
> filenames, I dont want people building up a directory of old and
> broken themes. When one of my themes break (due to CVS changes) I
> promptly release and update and thats it.
> 
> Im going to spend the next week or so polishing up everything and
> revising code and to let this idea sink in.
> Toma
> 
> 
> 2008/7/1 Sthithaprajna Garapaty <[EMAIL PROTECTED]>:
> > I like this idea a lot. It would be good to make those fields
> > mandatory, and hide
> > themes from the theme configuration dialog if they dont have all of
> > those fields.
> > That would really speed up adoption.
> >
> > Beyond the e/theme/version (which matches the version of E), I would suggest
> > adding a version for the theme itself. This would make it easy to do
> > automatic updates on themes. Seems like Toma suggested this, and then
> > forgot about it.
> >
> > Maybe something like
> >  item: "e/theme/theme-version"  "1.0";
> >
> > On Tue, Jul 1, 2008 at 11:08 AM, Sthithaprajna Garapaty
> > <[EMAIL PROTECTED]> wrote:
> >> I like this idea a lot. It would be good to make those fields
> >> mandatory, and hide
> >> themes from the theme configuration dialog if they dont have all of
> >> those fields.
> >> That would really speed up adoption.
> >>
> >> Beyond the e/theme/version (which matches the version of E), I would
> >> suggest adding a version for the theme itself. This would make it easy to
> >> do automatic updates on themes. Seems like Toma suggested this, and then
> >> forgot about it.
> >>
> >> Maybe something like
> >>  item: "e/theme/theme-version"  "1.0";
> >>
> >>
> >>
> >> On Tue, Jul 1, 2008 at 4:28 AM, The Rasterman Carsten Haitzler
> >> <[EMAIL PROTECTED]> wrote:
> >>> On Mon, 30 Jun 2008 15:23:32 +0200 Brian 'morlenxus' Miculcy
> >>> <[EMAIL PROTECTED]> babbled:
> >>>
> >>> I think adding these in is a good idea. namespacing sounds good. those
> >>> seem important fields - useful. as brian said - the rest is implicit in
> >>> the .edj file contents itself and is simply a matter of making the theme
> >>> chooser better (being able to open and inspect the .edj file - list all
> >>> the groups and from that make an assessment if its a full or partial
> >>> theme - or just a wallpaper, and which bit of e does it try and theme,
> >>> and how much). the theme preview still needs to fake up window borders,
> >>> windows, menus, dialogs etc. not just the wallpaper, so when you select a
> >>> theme you get a preview that somewhat resembles what you will get.
> >>>
>  I like the idea. The four items you selected are a good selection. We
>  don't need a description what a theme file themes - because the edje file
>  itself descripes it. You can get the group parts from the file and so
>  it's possible to show in a dialog what an edje file exactly does.
>  We also need a better theme dialog as we get more and more edje files
>  which only theme a few parts, for example border themes or themes for
>  specific modules. The import button only allows to import full themes,
>  also i think it's somehow confusing to be able to set a background or
>  init theme from the advanced theme dialog and also from the init /
>  wallpaper dialog. We need to reorganise that.
> 
>  Greets,
>  Brian 'morlenxus' Mi

Re: [E-devel] Evas transforms/filters/etc.

2008-07-26 Thread The Rasterman
On Tue, 08 Jul 2008 20:36:10 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:

>   Let me just make it clear what I'm saying here:
> 
>   I think a general (or just serial) gfx filter pipeline for evas render
> is largely unnecessary and mostly useless for real-time gui stuff.. I'd say
> just leave complex pipelines to immediate-mode mechanisms. But it you really
> want such a thing, say via the 'filter a filter' method, then fine -- it'll
> complicate the general implementation, maybe make it harder to optimize some
> things, maybe create some issues with hit-detection... but it can be done.
> 
>   However, what I think would be an absolutely terrible idea is to have
> "transforms" and "masks" exclusively given via such a filters approach, rather
> than via their own api. I'll never be convinced of that anymore than I'll be
> convinced that "move", "resize", "color", ... should also be given solely via
> a filters api rather than via their own.

oh - i ABSOLUTELY agree. transforms and masks CAN be done by filters. but they
really should really be available normally without filters.  a transform filter
is simply a good simple example of a filter. i really do agree with you here.

-- 
- 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Event_Struct and Ecore_Job?

2008-07-26 Thread The Rasterman
On Mon, 7 Jul 2008 19:08:11 +0200 Andreas Volz <[EMAIL PROTECTED]> babbled:

i've been busy oflate... and i need to limit how much email i reply to.. i
already have enough of my day sunk into email! :) but i hope the links help...
normally answers do come - but... people are busy :( srrry :(

> Am Thu, 3 Jul 2008 07:22:50 +0200 (CEST) schrieb Vincent Torri:
> 
> > 
> > Hey,
> > 
> > > in the past I used ecore_main_fd_handler_add() to hook my async
> > > signals from a second thread into the ecore loop (GPS and Joystick
> > > in that case). This works well so far. Now I found this:
> > >
> > > http://docs.enlightenment.org/api/ecore/html/group__Ecore__Job__Group.html
> > >
> > > and
> > >
> > > http://docs.enlightenment.org/books/cookbook/eflcookbook.html#id2540052
> > >
> > > The second contains ecore_event_handler_add(). I wasn't able to find
> > > that in the ecore docs.
> > >
> > > Could you short explain for what both types are used?
> > >
> > > Is one of both able to replace my current way of hooking async
> > > functions from a second thread into the ecore main loop as I did it
> > > with ecore_main_fd_handler_add() like in:
> > >
> > > http://tux-style.de/linux/enlightenment/Dispatcher/C/ecore_dispatcher.c
> > 
> > maybe that thread can interest you:
> > 
> > http://sourceforge.net/mailarchive/message.php?msg_id=Pine.LNX.4.64.0805110644300.12290%40grozny.maths.univ-evry.fr
> 
> Sure this is really interesting as it implements a similar thing. But I
> wonder where I should ask the question above. Nobody on this list or on
> IRC likes to answer it. Maybe nobody knows it?
> 
> regards
> Andreas
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Experiments in Edje

2008-07-26 Thread The Rasterman
On Wed, 9 Jul 2008 08:43:24 +0800 Toma <[EMAIL PROTECTED]> babbled:

> Hey all,
> Ive been toying with the idea of a 'LSD' colour changing border and
> theme for sometime now, and could never quite get it right. I finally
> cracked it by setting the images to a color_class and then having some
> embryo take care of the randf colours thrown at the color_class.
> 
> So I got thinking, If a theme had all white or gray components, then
> set all the images to use maybe 3 or 4 colour classes. The user can
> control theme themes colours with 'enlightenment_remote
> -color-class-color-list' and -set. The cleaner method would be to make
> a 'Theme designated Colors' tab in the Colors settings in the config
> panel.

damn! you hit on my secret plan! you bastard! :)  yes! that is the point of
colorclasses.. to be able to do just this! why do u think i'm doing a
petty-much black and white theme? other than the nice minimalism of black and
white... it allows for... colorclasses to really work well! :)

> This technique could be applied to just about anything using edje. So
> maybe the color-class stuff in enlightenment_remote could be split-out
> into an edje_control sort of app?
> This is all just some food for thought.
> Toma
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E17 bug report : Workspace in weird state after fullscreen video

2008-07-26 Thread The Rasterman
On Wed, 9 Jul 2008 11:07:34 +1000 Erik de Castro Lopo <[EMAIL PROTECTED]>
babbled:

as the tread says - known bug.. just with vlc - xine, mplayer and totem work
fine in fullscreen. unknown if it's e doing bad/strage things, or vlc - or a
combo of both, but fullscreen with vlc invariably ends up with strange
results... :(

> Hi all,
> 
> I'm running a pretty recent version of E17 (pulled from CVS within
> the last week) and I'm seeing some weirdness.
> 
> If I play a video using VLC in fullscreen mode, the desktop isn't
> redrawn after the video finishes. This means that the workspace
> that played the video is all screwed up until I restart E17 using
> Enlightenment -> Restart in the menu.
> 
> The same problem also occurred with the previous version which
> was probably pulled from CVS 6-8 weeks ago.
> 
> Cheers,
> Erik
> -- 
> -
> Erik de Castro Lopo
> -
> "I do have a policy of mandatory evisceration where the crime of
> whitespace in filenames is perpetrated on my systems. This has
> inspired a new range of designer colostomy bag covers in corduroy,
> velvet, and the ever popular denim."
> -- jdub on the SLUG mailing list
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E CVS: apps/e raster

2008-07-26 Thread The Rasterman
On Wed, 09 Jul 2008 07:24:06 +0200 Sebastian Dransfeld
<[EMAIL PROTECTED]> babbled:

oh bugger. i missed that. the warp_to was modified elsewhere implicitly
controlled by the config slide value...


> Enlightenment CVS wrote:
> > ===
> > RCS file: /cvs/e/e17/apps/e/src/bin/e_border.c,v
> > retrieving revision 1.635
> > retrieving revision 1.636
> > diff -u -3 -r1.635 -r1.636
> > --- e_border.c  19 May 2008 04:15:47 -  1.635
> > +++ e_border.c  8 Jul 2008 19:41:42 -   1.636
> > @@ -1376,7 +1376,8 @@
> >   {
> > if (e_border_under_pointer_get(bd->desk, bd))
> >   {
> > -if (!e_border_pointer_warp_to_center(bd))
> > +// FIXME: make this config. this is just annoying to warp all the time
> > here! +//if (!e_border_pointer_warp_to_center(bd))
> >e_border_focus_set(bd, 1, 1);
> >   }
> > else
> > @@ -1385,7 +1386,8 @@
> > else if (e_config->focus_policy == E_FOCUS_CLICK)
> >   e_border_focus_set(bd, 1, 1);
> > else
> > - if (!e_border_pointer_warp_to_center(bd))
> > +// FIXME: make this config. this is just annoying to warp all the time
> > here! +// if (!e_border_pointer_warp_to_center(bd))
> > e_border_focus_set(bd, 1, 1);
> >  
> > ecore_x_pointer_ungrab();
> 
> There is a config value, check in the e_border_pointer_warp_to_center 
> function, it always returns 0 if e_config->pointer_slide is 0
> 
> Sebastian
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] segfault de e

2008-07-26 Thread The Rasterman
On Sun, 13 Jul 2008 11:08:11 +0200 Bouyafa <[EMAIL PROTECTED]> babbled:

> Bonjour,
> 
> J'ai compilé le CVS de samdi 12, hier donc. Tout est nickel j'adore la 
> nouvelle fonction qui permet de télécharger des fonds d'écrans ou 
> autres, via les fenêtres de e. Donc un merci à vous tous, pour les 
> efforts faits au quotidien et au fil des versions.
> 
> Cela dit à titre informatif, sur ma version d'hier, mon e segfault assez 
> facilement lorsque je manipule le contenu des mes gondoles. Dès que 
> j'enlève deux éléments d'une gondole j'ai un segfault de e.
> 
> 
> Thanks a lot for your work, I love E ! So i ve just compiled the last 
> CVS, Saturday 12. I ve got few bugs when i manipulate the items in the 
> shelves, i can remove one item per on item,but if I remove 2 items, E 
> segfault.
> 
> Thanks again, have a nice day/code

what shelf items? have u added extra modules (not the ones that come with e
by default)?

-- 
- 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] e2.enlightenment.org ssh key changed?

2008-07-26 Thread The Rasterman
On Wed, 16 Jul 2008 13:19:52 -0400 "Sthithaprajna Garapaty"
<[EMAIL PROTECTED]> babbled:

yeah. security fixes in debian... :)

> I think it changed almost a month ago. Maybe due to the debian fiasco? dunno..
> 
> On Wed, Jul 16, 2008 at 1:16 PM, David Seikel <[EMAIL PROTECTED]> wrote:
> > Has that key changed?  I wanted to log on and add e_modules/skel to the
> > nightly build tests, but my ssh client tells me the key is different.
> > It can wait.
> >
> > -
> > 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=100&url=/
> > ___
> > 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=100&url=/
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] reorganisation of configure output

2008-07-26 Thread The Rasterman
On Thu, 17 Jul 2008 10:57:27 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]>
babbled:

no objections :) in cvs anyway :)

> 
> Hey,
> 
> i've always found the output of ecore's configure a bit messy. Here is a 
> patch that tries to organise that a bit. There are 3 parts: "Core", 
> "Graphic systems" and "Ecore Evas". Here is an output on Windows:
> 
> Core:
> 
>Ecore_Job: yes
>Ecore_Txt: yes
>Ecore_File...: yes
>  Inotify: no
>  Poll...: yes
>  CURL...: yes
>Ecore_Desktop: no
>Ecore_Con: no
>Ecore_Ipc: no
>Ecore_Config.: no
>Ecore_IMF: yes
>Ecore_IMF_Evas...: yes
> 
>   Graphic systems:
> 
>Ecore_X..: no
>Ecore_Win32..: yes
>Ecore_SDL: no
>Ecore_FB.: no
>Ecore_DFB: no
>Ecore_WinCE..: no
> 
>   Ecore Evas:
> 
>Ecore_Evas...: yes
>  Software Memory Buffer.: yes
>  Software X11...: no
>  XRender X11: no
>  OpenGL X11.: no
>  Software DirectDraw: yes
>  Direct3D...: yes
>  OpenGL Glew: yes
>  Software SDL...: no
>  DirectFB...: no
>  Software Framebuffer...: no
>  Software 16bit X11.: no
>  Software 16bit DirectDraw..: yes
>  Software 16bit WinCE...: no
> 
> The options are hidden if the module is not available.
> 
> Note that I can replace
> 
> Ecore_X
> Ecore_Win32
> Ecore_SDL
> Ecore_FB
> Ecore_DFB
> Ecore_WinCE
> 
> by
> 
> X Window
> Windows (gdi)
> SDL
> Framebuffer
> DirectFB
> Windows CE (gdi)
> 
> if you think it's better (I can do the same for the "Core" part).
> 
> If nobody objects, I'll commit the patch in some days.
> 
> Vincent


-- 
- 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E CVS: libs/eet cedric

2008-07-26 Thread The Rasterman
On Thu, 17 Jul 2008 22:35:08 +0200 Peter Wehrfritz <[EMAIL PROTECTED]>
babbled:

it should be unsigned long - this will then match the size of void *. changed
in cvs.

> Vincent Torri schrieb:
> > Hey,
> >
> > in eet_data.c, in _eet_free_hash() :
> >
> > long int ptr = (long int)(data);
> >
> > hash ^= ptr >> 32;
> > and the others
> >
> > long int is 32 bits long on 32 bits computers. Is it possible that a 
> > problem can arise, here ?
> >   
> Right, that produces a warning. I fixed that (hopefully right) and some 
> other compile warnings in eet_data.c. There are still some warnings in 
> eet_lib.c and eet_iamge.c
> 
> eet_lib.c: In function 'eet_internal_read2':
> eet_lib.c:856: warning: comparison between signed and unsigned
> eet_lib.c: In function 'eet_internal_read1':
> eet_lib.c:949: warning: comparison between signed and unsigned
> eet_lib.c: In function 'eet_internal_read':
> eet_lib.c:1083: warning: comparison between signed and unsigned
> eet_lib.c: In function 'eet_open':
> eet_lib.c:1182: warning: comparison between signed and unsigned
> eet_image.c: In function 'eet_data_image_jpeg_rgb_decode':
> eet_image.c:234: warning: comparison between signed and unsigned
> eet_image.c:238: warning: comparison between signed and unsigned
> eet_image.c:241: warning: comparison between signed and unsigned
> eet_image.c:241: warning: comparison between signed and unsigned
> eet_image.c:245: warning: comparison between signed and unsigned
> eet_image.c:249: warning: comparison between signed and unsigned
> eet_image.c:270: warning: comparison between signed and unsigned
> eet_image.c:274: warning: comparison between signed and unsigned
> eet_image.c:277: warning: comparison between signed and unsigned
> eet_image.c:277: warning: comparison between signed and unsigned
> eet_image.c:281: warning: comparison between signed and unsigned
> eet_image.c:285: warning: comparison between signed and unsigned
> eet_image.c: In function 'eet_data_image_jpeg_alpha_decode':
> eet_image.c:376: warning: comparison between signed and unsigned
> eet_image.c:380: warning: comparison between signed and unsigned
> eet_image.c:383: warning: comparison between signed and unsigned
> eet_image.c:383: warning: comparison between signed and unsigned
> eet_image.c:387: warning: comparison between signed and unsigned
> eet_image.c:391: warning: comparison between signed and unsigned
> 
> 
> -
> 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=100&url=/
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] License questions

2008-07-26 Thread The Rasterman
On Fri, 25 Jul 2008 01:53:15 +0200 "Jorge Luis Zapata Muga"
<[EMAIL PROTECTED]> babbled:


> I have a question here, where is the authorship then? if i have an app
> A licensed with L, i guess im free to relicense another (or the same)
> app with license M right? and if so, being myself the author how can i
> not put my own code into another app with license N? does the
> authorship get relegated to the license itself?

any code you own (are the author of) you are free to re-license yourself
elsewhere any way you like! that is why if you have 1 owner or a smallset of
owners, they can release something as open source AND as closed, as they are
owners - hey are free to also release it under another license. the owner has
the right to release their work under any licence they like and as often as
they like - and change the license (in a new release). existing releases retain
existing licenses.

> > The reason we originally required all items in the repo to be BSD
> > licensed (and yes, this decision was made a long time ago) was so that
> > code could be moved seamlessly between projects without having to
> > worry about relicensing or infecting other projects.
> >
> > It sounds like you're rescinding that decision.  If so, that's fine,
> > but everyone needs to understand that code can't just move around at
> > will any more.  But it's your call.
> >
> >> as i said - IMHO GPL is not right - it infects beyond the boundaries
> >> of its container. LGPL is acceptable.
> >
> > Unfortunately, so does the LGPL.
> >
> > Let's look at LGPLv2.1 first
> > (http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html).  According
> > to Section 2a, any "work based on the Library" (that is, anything
> > containing the Library's code, or any portion thereof, even just a
> > single function or code block cut-and-pasted in) MUST itself be a
> > LIBRARY.
> >
> > Wait, what?  Yup, that's right.  The LGPL forbids you from snagging a
> > portion of code from an LGPL library and using it in a program (i.e.,
> > independent executable).  In fact, I can't find anything anywhere in
> > the LGPLv2.1 that allows it to be used for non-libraries.  LGPLv3
> > doesn't appear to have this limitation, since "Library" is defined as
> > any work covered by the LGPLv3.  But LGPLv2.1 only covers objects you
> > link with to create executables, not executables.  So LGPL code cannot
> > be used in applications (e.g., E itself).
> >
> > Based on the clear language of the license, trying to apply it to a
> > software program (like OpenOffice.org) doesn't seem to make any sense,
> > since the legal term Library used throughout the license cannot apply
> > to something like Writer which you would never "link against to form
> > executables."
> >
> > The only provision in LGPLv2.1 that would allow someone to use LGPL
> > code in an application is Section 3 which allows the LGPL to be
> > replaced by the GPL at any time (and at version 2 or any later
> > version).  So in order to cut-paste-and-modify code from an LGPL
> > library into an application, the application MUST become GPL.
> >
> > Obviously this does not include linking, but one of the primary
> > reasons we picked the license we did was so that our code could be
> > used in other software under other licenses (Apache, Artistic,
> > Mozilla, or yes, even the GPL).  Because of Sections 2c and 3, any
> > code coming from an LGPL project which is used in any way other than
> > linking can only be used in GPL/LGPL software.
> >
> > Here's an example of the danger: Let's say EWL is BSD, and the authors
> > want to borrow a small bit of code from a large LGPL'd library
> > (without linking to it); EWL would have to be LGPL'd.  Worse yet, if
> > EWL wanted to borrow some code from E, and E were "LGPL'd" (which
> > really means GPL'd since it's not a library), EWL would have to become
> > GPL'd.  Then all software using EWL would be GPL'd.
> >
> > So yes, even the LGPL can "infect" other code.  Just not as badly.
> >
> > The LGPLv3, unlike the LGPLv2.1, is not a separate license in its own
> > right.  It is a set of addendums to the GPLv3 which provide additional
> > "permissions" above and beyond those granted by the GPL.  Having not
> > read the GPLv3 myself, I'm not prepared to discuss whether it's better
> > or worse.  The LGPLv3, as I said before, does seem to allow itself to
> > be applied to applications as well as libraries, so it would really
> > seem to be the only option for LGPL'ing the programs that link with
> > the EFL.
> >
> > If all we care about is linking, then LGPL is just as fine as BSD.
> > But is that all we care about?
> >
> > Michael
> >
> > --
> > Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
> > Linux Server/Cluster Admin, LBL.gov   Author, Eterm (www.eterm.org)
> > ---
> >  "Kyrie eleison down the road that I must travel.  Kyrie eleison
> >  through the darkness of the night. 

Re: [E-devel] License questions

2008-07-26 Thread The Rasterman
On Thu, 24 Jul 2008 14:08:03 -0700 Michael Jennings <[EMAIL PROTECTED]> babbled:

> Assuming no one using another license ever wants to use that code.  If
> Peter writes a really badass EWL app and LGPL's or GPL's it, that code
> could not be used in E or Evas (unless Peter himself relicensed it)
> without changing their licenses to LGPL/GPL.
> 
> The reason we originally required all items in the repo to be BSD
> licensed (and yes, this decision was made a long time ago) was so that
> code could be moved seamlessly between projects without having to
> worry about relicensing or infecting other projects.
> 
> It sounds like you're rescinding that decision.  If so, that's fine,
> but everyone needs to understand that code can't just move around at
> will any more.  But it's your call.

i think we asked people to do it - for ease - it is a good thing to do, but,
they still are free to license as they see fit - it is their work and their
code.

> > as i said - IMHO GPL is not right - it infects beyond the boundaries
> > of its container. LGPL is acceptable.
> 
> Unfortunately, so does the LGPL.
> 
> Let's look at LGPLv2.1 first
> (http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html).  According
> to Section 2a, any "work based on the Library" (that is, anything
> containing the Library's code, or any portion thereof, even just a
> single function or code block cut-and-pasted in) MUST itself be a
> LIBRARY.

yes - known. but if you LINK to it - it doesn't matter. if you literally
include it verbatim - it infects.

so:

-lwhateverlib - does not infect
#include "whateverlib.c" - does.

i'm just caring about linking here. it means you can make a nice clearly
defined boundary that is also convenient :)

> Wait, what?  Yup, that's right.  The LGPL forbids you from snagging a
> portion of code from an LGPL library and using it in a program (i.e.,
> independent executable).  In fact, I can't find anything anywhere in
> the LGPLv2.1 that allows it to be used for non-libraries.  LGPLv3
> doesn't appear to have this limitation, since "Library" is defined as
> any work covered by the LGPLv3.  But LGPLv2.1 only covers objects you
> link with to create executables, not executables.  So LGPL code cannot
> be used in applications (e.g., E itself).
> 
> Based on the clear language of the license, trying to apply it to a
> software program (like OpenOffice.org) doesn't seem to make any sense,
> since the legal term Library used throughout the license cannot apply
> to something like Writer which you would never "link against to form
> executables."
> 
> The only provision in LGPLv2.1 that would allow someone to use LGPL
> code in an application is Section 3 which allows the LGPL to be
> replaced by the GPL at any time (and at version 2 or any later
> version).  So in order to cut-paste-and-modify code from an LGPL
> library into an application, the application MUST become GPL.
> 
> Obviously this does not include linking, but one of the primary
> reasons we picked the license we did was so that our code could be
> used in other software under other licenses (Apache, Artistic,
> Mozilla, or yes, even the GPL).  Because of Sections 2c and 3, any
> code coming from an LGPL project which is used in any way other than
> linking can only be used in GPL/LGPL software.
> 
> Here's an example of the danger: Let's say EWL is BSD, and the authors
> want to borrow a small bit of code from a large LGPL'd library
> (without linking to it); EWL would have to be LGPL'd.  Worse yet, if
> EWL wanted to borrow some code from E, and E were "LGPL'd" (which
> really means GPL'd since it's not a library), EWL would have to become
> GPL'd.  Then all software using EWL would be GPL'd.
> 
> So yes, even the LGPL can "infect" other code.  Just not as badly.
> 
> The LGPLv3, unlike the LGPLv2.1, is not a separate license in its own
> right.  It is a set of addendums to the GPLv3 which provide additional
> "permissions" above and beyond those granted by the GPL.  Having not
> read the GPLv3 myself, I'm not prepared to discuss whether it's better
> or worse.  The LGPLv3, as I said before, does seem to allow itself to
> be applied to applications as well as libraries, so it would really
> seem to be the only option for LGPL'ing the programs that link with
> the EFL.
> 
> If all we care about is linking, then LGPL is just as fine as BSD.
> But is that all we care about?
> 
> Michael
> 
> -- 
> Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
> Linux Server/Cluster Admin, LBL.gov   Author, Eterm (www.eterm.org)
> ---
>  "Kyrie eleison down the road that I must travel.  Kyrie eleison
>   through the darkness of the night.  Kyrie eleison; where I'm going,
>   will you follow?" -- Mr. Mister, "Kyrie"
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move 

Re: [E-devel] [PATCH] No propagate event

2008-07-26 Thread The Rasterman
On Mon, 21 Jul 2008 18:08:32 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:

> I wasn't able to get evas_object_propagate_events_set working as
> specified by the documentation. In fact, by reading the code, I don't
> see how it can detect that a callback was found. So here is a patch
> that just did this, I didn't apply it as I fear I could have
> misunderstood the test and break every thing. So please review and
> test this patch.

in cvs! :)

-- 
- 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=100&url=/
___
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.

2008-07-26 Thread The Rasterman
On Wed, 23 Jul 2008 17:27:35 -0300 "imx31cpu ." <[EMAIL PROTECTED]> babbled:

> Hi,
> 
> 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.

in fact.. you have to do almost no work... get openembedded up and working.
openmoko uses it 0 for am arm based phone. mamona uses it for a fully open
build for the nokia n8xx (arm based).. etc. etc.

as such - all you need is an xserver.. and e will work. there is no porting to
do that is arm-related - the code has been fixed and cleaned long ago so it
"just works"... once you compile it. your biggest problem is a cross-compile
environment for building software - you need to solve this anyway - and once
you do (openembedded is a good option here), things just work. openembedded
already has builds for enlightenment in it - as far as illume goes - it's a
module for e17 to make e have a ui layout/setup that is much more
"phone/pda/handheld device" friendly ui.

as vincent mentioned... openglES is an interesting idea - to date i have not
had any time to really look at it. i know leonardo started playing with it...
but didn't have any success. one day i'll get to it! :) but as such most of the
work is done in the gl engine - it just needs some changes to adapt to GLES.

-- 
- 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [EFM] Typebuf

2008-07-26 Thread The Rasterman
On Fri, 25 Jul 2008 12:30:57 +0400 "Гусев Фёдор" <[EMAIL PROTECTED]> babbled:

> Hello everyone.
> 
> Attached patch fixes a couple issues with current typebuf in EFM.
> First, now typebuf is cleared out when you change current directory.
> Second, it has a 5 seconds timeout, so if you don't type anything
> during this time, it's cleared out too.

in cvs. :) thx!

> PS: Typebuf is a way for faster navigation in EFM, you type what you
> what to find, and matching file is automatically selected.



-- 
- 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=100&url=/
___
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-26 07:10:27 -0700

2008-07-26 Thread Nightly build system
Build log for Enlightenment DR 0.17 on 2008-07-26 07:10:27 -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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] The bleeding edge of edc?

2008-07-26 Thread The Rasterman
On Sat, 19 Jul 2008 05:56:53 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:

>   Or rather, what to do with "edc" and its use for representing gfx
> components in both edje and evolve... that's the real question here.
> 
>   Right now, evolve has no direct 'gfx' representations other than via
> edje/edc, and the latter is limited to what has been available in evas so far.
> Edje/edc itself deals mostly with defining "groups" -- which are a kind of
> 'template' for creating stateful, compound evas objs (certain smart objs) from
> basic gfx components (ie. the "parts").
>   But with an extended set of gfx capabilities for evas (vgfx stuff,
> transforms, masks, filters, ...), one can *begin* looking into extending the
> descriptions of such parts so that such new gfx aspects can be represented
> via edc and/or scripting.

yup. indeed. and with edje.. i'm open to this. for example - if we have enough
vgfx to do full svg (and scale it realtime) then i see no problem adding proper
svg support so u can include svg's just like you do png/jpg etc.

this has already been discussed with respect to native video format handling
for evas - getting 2 codecs in place that:

1. allow for very efficient lossless encoding AND fast decode (beter than
encoding X full images).
2. allow for lossy encoding (mpeg/mpeg4/h263/624/theora - whatever but use one)
that can also provide an alpha channel.

so open for improving it.

>   More could also be done in evolve/edc to introduce *canvas*
> presentations, by which I mean something like what Flash/mxml and
> Silverlight/xaml (and svg) allow developers/designers to define.

i've looked at flash before - in detail. i know where it stands relative to
edje :) i get where you are coming from - and yes - we should/need to/want to
expand to support this kind of stuff. one of the steps was more extensive
scripting - ie more embryo - or look at lua.

>   In fact, I'd encourage those interested in gfx matters to take a look
> at those two formats (and the apis behind the relevant libs) and see what
> can be learned from them in terms of expressive capabilities so that one can
> *begin* getting ideas as to what could also be done in both edje/edc and
> evolve/edc (and possibly with scripting and/or C as well).

indeed - agree. and i have. i've kept mental notes for edje for a while... that
is one reason for the video codec and extended scripting. basically from
flash/swf. if we have better vgfx in evas we can consider svg support too...
and more. i'd like to extend the tweening and animation stuff - add spline
curves, paths, containers.. and more. there is room to improve. it just takes
time and effort. one step at a time! :)

>   Thoughts or comments on this?
> 
> 
> Click here for free information on nursing degrees, up to $150/hour
> http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nEnkrJKQmsKO8b7JLixuV9RDtG9jt3GM18aQCwyTuM9kxb6/
> 
> -
> 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=100&url=/
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Exchange - A new place to trade themes and showcase applications and modules.

2008-07-26 Thread Sthithaprajna Garapaty
There is a way to see all the themes that apply to enlightenment.
If you go into the enlightenment app
http://exchange.enlightenment.org/application/show/4
and scroll down, it shows a list of themes that apply to it.
Of course, it shows any theme that applies, not "complete" themes, so
it catches border themes and wallpapers too.

There is no practical definition for a complete theme, because there
are way too many things to theme, and... even if a theme is complete
in themeing everything in the core E, it will probably leave out a
whole bunch of 3rd party modules.
Also, using "widgets" can work right now, because all the themes that
are complete provide widgets, but.. I actually made half of a
widget-only theme.. to be a generic theme that can be matched with
some border themes.. so that wont really apply for long..

We need a clear definition, so I can translate that into a category.
What do you think about checking for:
1. Border
2. Widget
3. Shelf
4. Wallpaper
and if it contains themes for all these components, marking it as an
full Enlightenment theme.. Is there something else that needs to be in
that list?


As far as a homepage link for apps and modules, please feel free to
put that link in the description.
Most apps and modules in CVS dont have a homepage, so it would be
empty for the majority of apps/themes.

-Sthitha


On Sat, Jul 26, 2008 at 9:56 AM, Toma <[EMAIL PROTECTED]> wrote:
> Renaming widgets to E17 theme might work since that group covers the
> main e17 interface.
> Toma
>
> On 7/26/08, Dave Andreoli <[EMAIL PROTECTED]> wrote:
>>
>> - "Andrew G. Stack" <[EMAIL PROTECTED]> ha scritto:
>>
>>> Hi all,
>>>
>>> The new site looks nice -- I like the fact that it has nice big
>>> screen
>>> shots and I'm sure it will be less work for morlenxus. :)  I'm
>>> traveling right now but as soon as I get back I'll get to work on an
>>> updated version of steampunk and upload it (I want to theme a few
>>> more
>>> modules first).
>>>
>>> One question I have regarding the themes:  let's say I was a new user
>>> and wanted to download "a theme" for e17.  Where would I look?  It
>>> seems the themes section is divided up into all the parts of e17 but
>>> there is no option for just an e17 theme.  Obviously there is no
>>> clear
>>> definition for what a complete e17 theme might be, for example, mine
>>> is
>>> missing quite a few parts like entrance, etk & ewl widgets, etc., but
>>> it seems like an additional tab under themes for e17 themes would be
>>> nice.  Or maybe a way to rank the themes based on the completeness of
>>> their included list?  So if I just want to download something to
>>> replace the default e17 theme I can browse some of the more complete
>>> themes and pick one.
>>
>> I agree: for a new user is such confusing. And another request: IMO we miss
>> an 'homepage' field in apps/modules, for example penguins is in cvs and
>> I don't know where to put the link to the penguins page.
>> Also should be usefull to have the ability to upload more than 1 screenshot.
>>
>> Just my two cents...
>> Thanks
>> Dave
>>
>>>
>>> Cheers,
>>> Andrew
>>> (Rooster)
>>>
>>> --- Toma <[EMAIL PROTECTED]> wrote:
>>>
>>> > Ladies and Gentlemen!
>>> >
>>> > We are proud to announce the launch of Exchange:
>>> > http://www.exchange.enlightenment.org
>>> >
>>> > This is a new website for exchanging themes, efl based applications
>>> > and modules for these applications. It was built specifically for
>>> E,
>>> > and therefore takes advantage of some of the features of edje to
>>> > automatically detect themes and allow users
>>> > to find themes for exactly what they want to theme.
>>> >
>>> > Its also a nice place to showcase your applications and will
>>> > hopefully
>>> > become a central location for people to look for EFL based apps.
>>> >
>>> > We ask that developers and themers all spend a couple minutes
>>> looking
>>> > around, create an account and upload some content as the only work
>>> on
>>> > there so far is a few modules and all of my work. Remember, this is
>>> a
>>> > great way to get some feedback on your content and for users to
>>> show
>>> > some appreciation for all your hard effort!
>>> >
>>> >
>>> > For those that want to develop apps that pull/push themes from the
>>> > Exchange, we have a full API documented here:
>>> > http://code.google.com/p/e17-exchange/wiki/ExchangeAPI (please
>>> direct
>>> > any questions about the API to iamsthitha)
>>> >
>>> > mcalamelli is already working on an application that will let you
>>> > download and install themes from exchange without having to visit
>>> the
>>> > website and go through the hassle of installing them.
>>> > http://staff.get-e.org/?p=users/mcalamelli/exchange.git;a=summary
>>> > (this is still in very early stages as of today, but is something
>>> to
>>> > keep an eye on!)
>>> >
>>> >
>>> -
>>> > This SF.Net email is sponsored by the Moblin Your Move Developer

Re: [E-devel] Experiments in Edje

2008-07-26 Thread Toma
Ha! I beat you to the punch ;) so im guessing you have plans to setup
some more recognised colour classes or theme defined ones so the
Colour selector can choose them?
Toma

On 7/26/08, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote:
> On Wed, 9 Jul 2008 08:43:24 +0800 Toma <[EMAIL PROTECTED]> babbled:
>
>> Hey all,
>> Ive been toying with the idea of a 'LSD' colour changing border and
>> theme for sometime now, and could never quite get it right. I finally
>> cracked it by setting the images to a color_class and then having some
>> embryo take care of the randf colours thrown at the color_class.
>>
>> So I got thinking, If a theme had all white or gray components, then
>> set all the images to use maybe 3 or 4 colour classes. The user can
>> control theme themes colours with 'enlightenment_remote
>> -color-class-color-list' and -set. The cleaner method would be to make
>> a 'Theme designated Colors' tab in the Colors settings in the config
>> panel.
>
> damn! you hit on my secret plan! you bastard! :)  yes! that is the point
> of
> colorclasses.. to be able to do just this! why do u think i'm doing a
> petty-much black and white theme? other than the nice minimalism of black
> and
> white... it allows for... colorclasses to really work well! :)
>
>> This technique could be applied to just about anything using edje. So
>> maybe the color-class stuff in enlightenment_remote could be split-out
>> into an edje_control sort of app?
>> This is all just some food for thought.
>> Toma
>>
>> -
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> ___
>> 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]
>
>

-- 
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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Exchange - What else can we share?

2008-07-26 Thread Sthithaprajna Garapaty
So, I've been thinking, what else can we share on the Exchange.
One simple thing is screenshots. Screenshots are nice eye candy and
could be good for building a community/showing off E. But, beyond that
they have no practical use.

A more complex thing is sharing parts of your E config. Like sharing
shelf layouts or gadget layouts. Or sharing sets of keybindings and
mouse bindings. Or sharing Window Locks and Remember settings.
Of course, you cant share them yet, they're in the monolithic e
config, so we need a module to pull them out of the config and put it
in a format that can be easily shared.
But, would it be useful to share these? Would anyone actually download them?

And, are there any other things people would want to share on the Exchange?

-
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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Exchange - A new place to trade themes and showcase applications and modules.

2008-07-26 Thread Toma
2008/7/27 Sthithaprajna Garapaty <[EMAIL PROTECTED]>:
> There is a way to see all the themes that apply to enlightenment.
> If you go into the enlightenment app
> http://exchange.enlightenment.org/application/show/4
> and scroll down, it shows a list of themes that apply to it.
> Of course, it shows any theme that applies, not "complete" themes, so
> it catches border themes and wallpapers too.
>
> There is no practical definition for a complete theme, because there
> are way too many things to theme, and... even if a theme is complete
> in themeing everything in the core E, it will probably leave out a
> whole bunch of 3rd party modules.
> Also, using "widgets" can work right now, because all the themes that
> are complete provide widgets, but.. I actually made half of a
> widget-only theme.. to be a generic theme that can be matched with
> some border themes.. so that wont really apply for long..
>
> We need a clear definition, so I can translate that into a category.
> What do you think about checking for:
> 1. Border
> 2. Widget
> 3. Shelf
> 4. Wallpaper
> and if it contains themes for all these components, marking it as an
> full Enlightenment theme.. Is there something else that needs to be in
> that list?
>

I like it. Personally I never call any of my themes anywhere near dun
unlit they have an Execbuf and Winlist theme too. But at the end of
the day, theyre still just modules.

>
> As far as a homepage link for apps and modules, please feel free to
> put that link in the description.
> Most apps and modules in CVS dont have a homepage, so it would be
> empty for the majority of apps/themes.
>
> -Sthitha
>
>
> On Sat, Jul 26, 2008 at 9:56 AM, Toma <[EMAIL PROTECTED]> wrote:
>> Renaming widgets to E17 theme might work since that group covers the
>> main e17 interface.
>> Toma
>>
>> On 7/26/08, Dave Andreoli <[EMAIL PROTECTED]> wrote:
>>>
>>> - "Andrew G. Stack" <[EMAIL PROTECTED]> ha scritto:
>>>
 Hi all,

 The new site looks nice -- I like the fact that it has nice big
 screen
 shots and I'm sure it will be less work for morlenxus. :)  I'm
 traveling right now but as soon as I get back I'll get to work on an
 updated version of steampunk and upload it (I want to theme a few
 more
 modules first).

 One question I have regarding the themes:  let's say I was a new user
 and wanted to download "a theme" for e17.  Where would I look?  It
 seems the themes section is divided up into all the parts of e17 but
 there is no option for just an e17 theme.  Obviously there is no
 clear
 definition for what a complete e17 theme might be, for example, mine
 is
 missing quite a few parts like entrance, etk & ewl widgets, etc., but
 it seems like an additional tab under themes for e17 themes would be
 nice.  Or maybe a way to rank the themes based on the completeness of
 their included list?  So if I just want to download something to
 replace the default e17 theme I can browse some of the more complete
 themes and pick one.
>>>
>>> I agree: for a new user is such confusing. And another request: IMO we miss
>>> an 'homepage' field in apps/modules, for example penguins is in cvs and
>>> I don't know where to put the link to the penguins page.
>>> Also should be usefull to have the ability to upload more than 1 screenshot.
>>>
>>> Just my two cents...
>>> Thanks
>>> Dave
>>>

 Cheers,
 Andrew
 (Rooster)

 --- Toma <[EMAIL PROTECTED]> wrote:

 > Ladies and Gentlemen!
 >
 > We are proud to announce the launch of Exchange:
 > http://www.exchange.enlightenment.org
 >
 > This is a new website for exchanging themes, efl based applications
 > and modules for these applications. It was built specifically for
 E,
 > and therefore takes advantage of some of the features of edje to
 > automatically detect themes and allow users
 > to find themes for exactly what they want to theme.
 >
 > Its also a nice place to showcase your applications and will
 > hopefully
 > become a central location for people to look for EFL based apps.
 >
 > We ask that developers and themers all spend a couple minutes
 looking
 > around, create an account and upload some content as the only work
 on
 > there so far is a few modules and all of my work. Remember, this is
 a
 > great way to get some feedback on your content and for users to
 show
 > some appreciation for all your hard effort!
 >
 >
 > For those that want to develop apps that pull/push themes from the
 > Exchange, we have a full API documented here:
 > http://code.google.com/p/e17-exchange/wiki/ExchangeAPI (please
 direct
 > any questions about the API to iamsthitha)
 >
 > mcalamelli is already working on an application that will let you
 > download and install themes from exchange without having to visit
 the
 > website 

Re: [E-devel] Exchange - What else can we share?

2008-07-26 Thread Toma
2008/7/27 Sthithaprajna Garapaty <[EMAIL PROTECTED]>:
> So, I've been thinking, what else can we share on the Exchange.
> One simple thing is screenshots. Screenshots are nice eye candy and
> could be good for building a community/showing off E. But, beyond that
> they have no practical use.
>
> A more complex thing is sharing parts of your E config. Like sharing
> shelf layouts or gadget layouts. Or sharing sets of keybindings and
> mouse bindings. Or sharing Window Locks and Remember settings.
> Of course, you cant share them yet, they're in the monolithic e
> config, so we need a module to pull them out of the config and put it
> in a format that can be easily shared.
> But, would it be useful to share these? Would anyone actually download them?
>

That all comes down to good 'Profiles' support right? I think desktop
layout should be included in profile support. Another cool thing this
could do, is add a sort of Profile hinting in the theme/ data then ask
the user if they want to set that profile when the theme is applied.
Another thing is allowing the user to say, "This is a replica of
Raster's Desktop using his own Profile settings and theme! *Gloat
Gloat* " Or even letting people try out different arrangements and
feels without too much hassle.

eg. heres an old layout I was using when tinkering with Fireball.
(Ignore the Facebook)
http://members.iinet.net.au/~haste/e17/layouttest.png

Icon themes. You might all be aware im tinkering away with making a
gnome2edje icon builder. Id like it to be able to pull all the needed
files for things used internally for E, (like Theme, Virtual Desktops,
Modules) which wont ever follow a specific MIME type icon. As such, an
'Icons' section would be nice with checks for
1. e/icons/enlightenment/e
2. e/icons/enlightenment/unknown
3. e/icons/enlightenment/configuration
4. e/icons/enlightenment/modules
5. e/icons/enlightenment/themes

As discussed on IRC, MIME types in EFM should really be coming from
the "Icon Theme" selector. Same with the icons for the 'Desktop'
'Home' 'Root' icons from the E favorites menu. There are icons to
handle those! (user-desktop.png, user-home.png)

But yeh, thats my 2 cents.
Toma

> And, are there any other things people would want to share on the Exchange?
>
> -
> 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=100&url=/
> ___
> 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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Exchange - A new place to trade themes and showcase applications and modules.

2008-07-26 Thread Dave Andreoli

- "Toma" <[EMAIL PROTECTED]> ha scritto:

> Renaming widgets to E17 theme might work since that group covers the
> main e17 interface.
> Toma

Yes, maybe rename it to 'Full E17 theme'?
Dave

> 
> On 7/26/08, Dave Andreoli <[EMAIL PROTECTED]> wrote:
> >
> > - "Andrew G. Stack" <[EMAIL PROTECTED]> ha scritto:
> >
> >> Hi all,
> >>
> >> The new site looks nice -- I like the fact that it has nice big
> >> screen
> >> shots and I'm sure it will be less work for morlenxus. :)  I'm
> >> traveling right now but as soon as I get back I'll get to work on
> an
> >> updated version of steampunk and upload it (I want to theme a few
> >> more
> >> modules first).
> >>
> >> One question I have regarding the themes:  let's say I was a new
> user
> >> and wanted to download "a theme" for e17.  Where would I look?  It
> >> seems the themes section is divided up into all the parts of e17
> but
> >> there is no option for just an e17 theme.  Obviously there is no
> >> clear
> >> definition for what a complete e17 theme might be, for example,
> mine
> >> is
> >> missing quite a few parts like entrance, etk & ewl widgets, etc.,
> but
> >> it seems like an additional tab under themes for e17 themes would
> be
> >> nice.  Or maybe a way to rank the themes based on the completeness
> of
> >> their included list?  So if I just want to download something to
> >> replace the default e17 theme I can browse some of the more
> complete
> >> themes and pick one.
> >
> > I agree: for a new user is such confusing. And another request: IMO
> we miss
> > an 'homepage' field in apps/modules, for example penguins is in cvs
> and
> > I don't know where to put the link to the penguins page.
> > Also should be usefull to have the ability to upload more than 1
> screenshot.
> >
> > Just my two cents...
> > Thanks
> > Dave
> >
> >>
> >> Cheers,
> >> Andrew
> >> (Rooster)
> >>
> >> --- Toma <[EMAIL PROTECTED]> wrote:
> >>
> >> > Ladies and Gentlemen!
> >> >
> >> > We are proud to announce the launch of Exchange:
> >> > http://www.exchange.enlightenment.org
> >> >
> >> > This is a new website for exchanging themes, efl based
> applications
> >> > and modules for these applications. It was built specifically
> for
> >> E,
> >> > and therefore takes advantage of some of the features of edje to
> >> > automatically detect themes and allow users
> >> > to find themes for exactly what they want to theme.
> >> >
> >> > Its also a nice place to showcase your applications and will
> >> > hopefully
> >> > become a central location for people to look for EFL based apps.
> >> >
> >> > We ask that developers and themers all spend a couple minutes
> >> looking
> >> > around, create an account and upload some content as the only
> work
> >> on
> >> > there so far is a few modules and all of my work. Remember, this
> is
> >> a
> >> > great way to get some feedback on your content and for users to
> >> show
> >> > some appreciation for all your hard effort!
> >> >
> >> >
> >> > For those that want to develop apps that pull/push themes from
> the
> >> > Exchange, we have a full API documented here:
> >> > http://code.google.com/p/e17-exchange/wiki/ExchangeAPI (please
> >> direct
> >> > any questions about the API to iamsthitha)
> >> >
> >> > mcalamelli is already working on an application that will let
> you
> >> > download and install themes from exchange without having to
> visit
> >> the
> >> > website and go through the hassle of installing them.
> >> >
> http://staff.get-e.org/?p=users/mcalamelli/exchange.git;a=summary
> >> > (this is still in very early stages as of today, but is
> something
> >> to
> >> > keep an eye on!)
> >> >
> >> >
> >>
> -
> >> > 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=100&url=/
> >> > ___
> >> > enlightenment-users mailing list
> >> > [EMAIL PROTECTED]
> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> >> >
> >>
> >>
> >>
> >>
> >>
> >>
> -
> >> 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=100&url=/
> >> ___
> >> enlightenment-users mailing list
> >> [EMAIL PROTECTED]
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> >
> >
> -
> > This S

Re: [E-devel] [RFC] Async preload of image data

2008-07-26 Thread Gustavo Sverzut Barbieri
On Sat, Jul 26, 2008 at 9:24 AM, The Rasterman Carsten Haitzler
<[EMAIL PROTECTED]> wrote:
> On Tue, 24 Jun 2008 09:51:37 -0300 "Gustavo Sverzut Barbieri"
> <[EMAIL PROTECTED]> babbled:
>
>> On Mon, Jun 23, 2008 at 1:14 PM, The Rasterman Carsten Haitzler
>> <[EMAIL PROTECTED]> wrote:
>> > On Wed, 18 Jun 2008 18:53:06 +0200 "Cedric BAIL" <[EMAIL PROTECTED]>
>> > babbled:
>> >
>> >> Hi,
>> >>
>> >>   Here is a patch that add support for background preloading of a data
>> >> image. You can now, if you know what you do, ask evas to load the data
>> >> of an image in memory before it is displayed (look at the sample code
>> >> for expedite).
>> >>
>> >>   The code is quite simple, we have now a work queue where we add all
>> >> the Image_Entry we need to preload. They are processed one after the
>> >> other in another thread. When it's done, it notify evas main thread
>> >> with evas async API and work on the next Image_Entry.
>> >>
>> >>   This means that we now require that engine surface creation and
>> >> loader should be thread safe. It's currently the case for all the
>> >> engine I know something about, so this should not break anything.
>> >> Anyway this code is optionnal and could be completely unactivated in a
>> >> per engine basis or globally.
>> >>
>> >> As always have fun reviewing this patch.
>> >
>> > hmmm - i like the idea - yes. missing cache surface alloc mutex :( that
>> > should not be hard to add - a little bit of extra code. also missing Evas.h
>> > prototype for exporting the preload call. looks like most engines have the
>> > calls supported. the problem is what to do out fd'with the locks on alloc.
>> > as such it is unlikely to cause problems as it stands in the patch - but
>> > may if the alloc happens while deleting/freeing an image. the images
>> > themselves all need locks now for anything accessing them.
>> >
>> > for other comments. i dont think we need to worry about fd's - the async fd
>> > is wrapped already. we dont need fd's internally in the async loader
>> > backend as it is by nature thread-aware and thus can and will use pthread
>> > primtitives and can use them for internal syncronisation or anything it
>> > likes. look at the evas pipe thread code - it doesnt use any fd's because
>> > it doesnt need to use them. there is no NEED for it to wake up select. i
>> > dont think u need to worry about this. we need to worry about the locks now
>> > needed on all images as the surface alloc is async to the mainloop.
>> > mainloop may do other things (like begin to use the image for other things
>> > while the async thread is allocing and hasnt been cancelled yet). the safe
>> > solution as above is locks on all images - but this is kind of ugly. i'd
>> > rather have this be less invasive in this department. but this means all
>> > operations on images need a mutex lock/unlock. :(
>>
>> I strongly disagree, see my examples, using that will make your life
>> much easier. The idea is very simple, the worker thread doesn't even
>> need a select, it can just sleep on read() and that's it. Ok, you can
>> do that with pthread_* primitives, but I don't see why. You get images
>> to process, you send them to the thread, that keeps a "to do" list,
>> process by priority order. These images (actually the structure that
>> points to it) will be marked with the priority and the state (todo,
>> done, canceled, ...) and it will all work well without any locks.
>> Summary: worker thread just look at some flag, if it's PROCESS then
>> put the pixels, notify back. No image allocation/free should be done
>> on the worker thread, thus no locks.
>
> i honestly think its much of a muchness. as it stands there is a simple single
> fd that the threads use pthread constructs to wake it up and write messages to
> it to wake up the process. with many fd's you need to read one and write to
> another... as evas only has 1 async fd... so for the work queue going out to
> the thread - yes, but for incoming back to the process to say "hey - stuff
> happened - wake up!" we really need just 1... and thus pthread lock stuff 
> around
> it to avoid it filling with garbage (if the data is large being written and 
> has
> meaning. right now it isn't - but it may... one day).

ok, you might need the lock to write to fd, but if we write a simple
internal api to dispatch commands you might get that in one single
place. We're using it at ProFUSION to integrate media engines (so far
GStreamer) into applications without pain and it works beautiful (we
cannot use emotion because we need very custom pipelines and video
output is in another plane, ...)   We can easily share this command
exchange under BSD, it's not even 300 lines of code :-)


>> Also, giving the use case, I'd avoid locks on images and alloc them on
>
> i absolutely agree on this. the fewer locks, the better!
>
>> the main thread before requesting it to be loaded, this way no pointer
>> will change, just the contents of it, then no problem. This will make

Re: [E-devel] Porting E to an ARM based embedded system.

2008-07-26 Thread Gustavo Sverzut Barbieri
On Sat, Jul 26, 2008 at 10:10 AM, The Rasterman Carsten Haitzler
<[EMAIL PROTECTED]> wrote:
> On Wed, 23 Jul 2008 17:27:35 -0300 "imx31cpu ." <[EMAIL PROTECTED]> babbled:
>
>> Hi,
>>
>> 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.
>
> in fact.. you have to do almost no work... get openembedded up and working.
> openmoko uses it 0 for am arm based phone. mamona uses it for a fully open
> build for the nokia n8xx (arm based).. etc. etc.
>
> as such - all you need is an xserver.. and e will work. there is no porting to
> do that is arm-related - the code has been fixed and cleaned long ago so it
> "just works"... once you compile it. your biggest problem is a cross-compile
> environment for building software - you need to solve this anyway - and once
> you do (openembedded is a good option here), things just work. openembedded
> already has builds for enlightenment in it - as far as illume goes - it's a
> module for e17 to make e have a ui layout/setup that is much more
> "phone/pda/handheld device" friendly ui.

well, I think his "port" was more about getting E into ltib, the
canonical imx31 build platform. It's something like openembedded, but
instead of .bb they use handicapped .rpm, with no dependency in the
.rpm, since they moved dependency tracking to kconfig (linux kernel
config/menuconfig, like busybox did)

ProFUSION just got one imx31 board from freescale brazil, we did some
packages but they're not finished yet.


> as vincent mentioned... openglES is an interesting idea - to date i have not
> had any time to really look at it. i know leonardo started playing with it...
> but didn't have any success. one day i'll get to it! :) but as such most of 
> the
> work is done in the gl engine - it just needs some changes to adapt to GLES.

Since we got one of these boards, we may try to give gles a try. But
really, before even trying I might talk to you to check for things to
look, like analyzing texture size and upload bandwidth, otherwise the
port will be useless...   BTW, on my macbook with intel 965 mobile
expedite reports about 2x gains on the software engine compared to gl,
and this is using newer mesa/x, so I get the shaders and all fancy
stuff on these boards Evas software engine rocks hard :-)

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
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.

2008-07-26 Thread Nick Hughart
Gustavo Sverzut Barbieri wrote:
> On Sat, Jul 26, 2008 at 10:10 AM, The Rasterman Carsten Haitzler
> <[EMAIL PROTECTED]> wrote:
>   
>> On Wed, 23 Jul 2008 17:27:35 -0300 "imx31cpu ." <[EMAIL PROTECTED]> babbled:
>>
>> 
>>> Hi,
>>>
>>> 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.
>>>   
>> in fact.. you have to do almost no work... get openembedded up and working.
>> openmoko uses it 0 for am arm based phone. mamona uses it for a fully open
>> build for the nokia n8xx (arm based).. etc. etc.
>>
>> as such - all you need is an xserver.. and e will work. there is no porting 
>> to
>> do that is arm-related - the code has been fixed and cleaned long ago so it
>> "just works"... once you compile it. your biggest problem is a cross-compile
>> environment for building software - you need to solve this anyway - and once
>> you do (openembedded is a good option here), things just work. openembedded
>> already has builds for enlightenment in it - as far as illume goes - it's a
>> module for e17 to make e have a ui layout/setup that is much more
>> "phone/pda/handheld device" friendly ui.
>> 
>
> well, I think his "port" was more about getting E into ltib, the
> canonical imx31 build platform. It's something like openembedded, but
> instead of .bb they use handicapped .rpm, with no dependency in the
> .rpm, since they moved dependency tracking to kconfig (linux kernel
> config/menuconfig, like busybox did)
>
> ProFUSION just got one imx31 board from freescale brazil, we did some
> packages but they're not finished yet.
>
>
>   
>> as vincent mentioned... openglES is an interesting idea - to date i have not
>> had any time to really look at it. i know leonardo started playing with it...
>> but didn't have any success. one day i'll get to it! :) but as such most of 
>> the
>> work is done in the gl engine - it just needs some changes to adapt to GLES.
>> 
>
> Since we got one of these boards, we may try to give gles a try. But
> really, before even trying I might talk to you to check for things to
> look, like analyzing texture size and upload bandwidth, otherwise the
> port will be useless...   BTW, on my macbook with intel 965 mobile
> expedite reports about 2x gains on the software engine compared to gl,
> and this is using newer mesa/x, so I get the shaders and all fancy
> stuff on these boards Evas software engine rocks hard :-)
>   
A bit off-topic, but bear with me :)

Well the i965 driver is actually quite shitty atm.  They are working 
more on render acceleration then 3D acceleration at this point from what 
I've seen.

I just tested expedite on my NVIDIA 6600gt and it pretty much creamed 
the software engine in almost every test.  The only ones that the 
software really pulled out ahead where some of the simpler blending 
tests near the end.  Text rendering was even much faster which is 
something that I've never seen till I tested on this card.  So there may 
still be hope for the GL engine :)

Another note, the XRender engine still sucks with NVIDIA :P


-
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=100&url=/
___
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.

2008-07-26 Thread Nick Hughart
Nick Hughart wrote:
> Gustavo Sverzut Barbieri wrote:
>   
>> On Sat, Jul 26, 2008 at 10:10 AM, The Rasterman Carsten Haitzler
>> <[EMAIL PROTECTED]> wrote:
>>   
>> 
>>> On Wed, 23 Jul 2008 17:27:35 -0300 "imx31cpu ." <[EMAIL PROTECTED]> babbled:
>>>
>>> 
>>>   
 Hi,

 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.
   
 
>>> in fact.. you have to do almost no work... get openembedded up and working.
>>> openmoko uses it 0 for am arm based phone. mamona uses it for a fully open
>>> build for the nokia n8xx (arm based).. etc. etc.
>>>
>>> as such - all you need is an xserver.. and e will work. there is no porting 
>>> to
>>> do that is arm-related - the code has been fixed and cleaned long ago so it
>>> "just works"... once you compile it. your biggest problem is a cross-compile
>>> environment for building software - you need to solve this anyway - and once
>>> you do (openembedded is a good option here), things just work. openembedded
>>> already has builds for enlightenment in it - as far as illume goes - it's a
>>> module for e17 to make e have a ui layout/setup that is much more
>>> "phone/pda/handheld device" friendly ui.
>>> 
>>>   
>> well, I think his "port" was more about getting E into ltib, the
>> canonical imx31 build platform. It's something like openembedded, but
>> instead of .bb they use handicapped .rpm, with no dependency in the
>> .rpm, since they moved dependency tracking to kconfig (linux kernel
>> config/menuconfig, like busybox did)
>>
>> ProFUSION just got one imx31 board from freescale brazil, we did some
>> packages but they're not finished yet.
>>
>>
>>   
>> 
>>> as vincent mentioned... openglES is an interesting idea - to date i have not
>>> had any time to really look at it. i know leonardo started playing with 
>>> it...
>>> but didn't have any success. one day i'll get to it! :) but as such most of 
>>> the
>>> work is done in the gl engine - it just needs some changes to adapt to GLES.
>>> 
>>>   
>> Since we got one of these boards, we may try to give gles a try. But
>> really, before even trying I might talk to you to check for things to
>> look, like analyzing texture size and upload bandwidth, otherwise the
>> port will be useless...   BTW, on my macbook with intel 965 mobile
>> expedite reports about 2x gains on the software engine compared to gl,
>> and this is using newer mesa/x, so I get the shaders and all fancy
>> stuff on these boards Evas software engine rocks hard :-)
>>   
>> 
> A bit off-topic, but bear with me :)
>
> Well the i965 driver is actually quite shitty atm.  They are working 
> more on render acceleration then 3D acceleration at this point from what 
> I've seen.
>
> I just tested expedite on my NVIDIA 6600gt and it pretty much creamed 
> the software engine in almost every test.  The only ones that the 
> software really pulled out ahead where some of the simpler blending 
> tests near the end.  Text rendering was even much faster which is 
> something that I've never seen till I tested on this card.  So there may 
> still be hope for the GL engine :)
>   
Gah, screwed that up.  The first sentence was talking about using the GL 
engine in expedite.
> Another note, the XRender engine still sucks with NVIDIA :P
>
>
> -
> 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=100&url=/
> ___
> 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=100&url=/
___
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.

2008-07-26 Thread Gustavo Sverzut Barbieri
On Sat, Jul 26, 2008 at 9:08 PM, Nick Hughart <[EMAIL PROTECTED]> wrote:
> Gustavo Sverzut Barbieri wrote:
>>
>> On Sat, Jul 26, 2008 at 10:10 AM, The Rasterman Carsten Haitzler
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> On Wed, 23 Jul 2008 17:27:35 -0300 "imx31cpu ." <[EMAIL PROTECTED]>
>>> babbled:
>>>
>>>

 Hi,

 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.

>>>
>>> in fact.. you have to do almost no work... get openembedded up and
>>> working.
>>> openmoko uses it 0 for am arm based phone. mamona uses it for a fully
>>> open
>>> build for the nokia n8xx (arm based).. etc. etc.
>>>
>>> as such - all you need is an xserver.. and e will work. there is no
>>> porting to
>>> do that is arm-related - the code has been fixed and cleaned long ago so
>>> it
>>> "just works"... once you compile it. your biggest problem is a
>>> cross-compile
>>> environment for building software - you need to solve this anyway - and
>>> once
>>> you do (openembedded is a good option here), things just work.
>>> openembedded
>>> already has builds for enlightenment in it - as far as illume goes - it's
>>> a
>>> module for e17 to make e have a ui layout/setup that is much more
>>> "phone/pda/handheld device" friendly ui.
>>>
>>
>> well, I think his "port" was more about getting E into ltib, the
>> canonical imx31 build platform. It's something like openembedded, but
>> instead of .bb they use handicapped .rpm, with no dependency in the
>> .rpm, since they moved dependency tracking to kconfig (linux kernel
>> config/menuconfig, like busybox did)
>>
>> ProFUSION just got one imx31 board from freescale brazil, we did some
>> packages but they're not finished yet.
>>
>>
>>
>>>
>>> as vincent mentioned... openglES is an interesting idea - to date i have
>>> not
>>> had any time to really look at it. i know leonardo started playing with
>>> it...
>>> but didn't have any success. one day i'll get to it! :) but as such most
>>> of the
>>> work is done in the gl engine - it just needs some changes to adapt to
>>> GLES.
>>>
>>
>> Since we got one of these boards, we may try to give gles a try. But
>> really, before even trying I might talk to you to check for things to
>> look, like analyzing texture size and upload bandwidth, otherwise the
>> port will be useless...   BTW, on my macbook with intel 965 mobile
>> expedite reports about 2x gains on the software engine compared to gl,
>> and this is using newer mesa/x, so I get the shaders and all fancy
>> stuff on these boards Evas software engine rocks hard :-)
>>
>
> A bit off-topic, but bear with me :)
>
> Well the i965 driver is actually quite shitty atm.  They are working more on
> render acceleration then 3D acceleration at this point from what I've seen.
>
> I just tested expedite on my NVIDIA 6600gt and it pretty much creamed the
> software engine in almost every test.  The only ones that the software
> really pulled out ahead where some of the simpler blending tests near the
> end.  Text rendering was even much faster which is something that I've never
> seen till I tested on this card.  So there may still be hope for the GL
> engine :)

I know, but I just want to alert people that being HW or GL is not
always good or better than sw implementation, some hardware is crappy,
some lack good texture upload bandwidth, some have very small texture
size and some, like i965, supposed to be great, are just bad and even
having all those things are still slower than sw implementation.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E17 bug report : Workspace in weird state after fullscreen video

2008-07-26 Thread Erik de Castro Lopo
Carsten Haitzler (The Rasterman) wrote:

> On Wed, 9 Jul 2008 11:07:34 +1000 Erik de Castro Lopo <[EMAIL PROTECTED]>
> babbled:
> 
> as the tread says - known bug.. just with vlc - xine, mplayer and totem work
> fine in fullscreen. unknown if it's e doing bad/strage things, or vlc - or a
> combo of both, but fullscreen with vlc invariably ends up with strange
> results... :(

Any way you would suggest to debug this? I just prefer vlc to any
of the other players.

Erik
-- 
-
Erik de Castro Lopo
-
Sex tourism islamic style:
http://timesofindia.indiatimes.com/articleshow/1219601.cms

-
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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel