Re: [E-devel] [RFC] Evas_Object_Polygons speed improvements
Cedric wrote: > On Fri, Jul 4, 2008 at 2:46 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > That would probably be a good way to do it. So, the vertex coords are floats which correspond to sub-pixel precision canvas coords. Every time one 'sets' the poly points the previous poly obj geometry is invalidated and the new one calculated thus determining the obj's size and pos (top-left corner of int bounding rect). Moving the poly obj will mean rendering the vertices suitably translated. Resizing the poly internally scales the vertices by the float fraction of the new size to the input-poly-size, and presrves the poly obj's pos. This will again mean rendering the so changed vertices accordingly. Note that this may have a bit of 'jitter' due to sizes being only integer values.. but one is also always free to transform the set of vertices as desired and set them again. In fact, it would eventually be good to have an api function for setting such a vertex transformation on such objects - say something like evas_object_polygon_points_transform_set(obj, *t); where the 't' will be an evas transformation, say possibly an affine and/or projective transform. This transform will act on the vertices for the purposes of rendering, but not affect the reported object size or position - though one would eventually like to have the effective 'bounding rect' of any transformed obje, whether it's a result of a general object (surface) transform or of a specilaized vertex transform on certain objects that might support that. >>> Though this wouldn't have to be done til later (if desired), let me >>> suggest a possible semantics for the use of such 'set' transforms on >>> vertex-based objects like polys. >>> First of all, I'd limit the transforms to only affine ones (though >>> I won't into why here - just mentioning it), so if one inputs a transform >>> with projective components, only the affine part is used. >>> > > I would like to know why we should have such a restriction as I don't > have as much background on this as you have. > > Basically, because the overwhelming majority of libs/apis/specs that deal with vgfx don't support projective transforms for their vector objects (polygons in particular), only affine ones. This includes cairo, flash, silverlight, svg (spec), .. Why they don't we'd have to ask each one, but there are certain 'issues' of semantics that are best avoided by restricting such vector/vertex based objects that can be stroked and/or filled to only supporting affine transforms of their geometric defining data. See more on transforms below. >>> Then, one would first scale the input vertices according to the poly >>> obj size but rel to the origin, apply the transform to those points, and >>> translate forward to its obj position. >>> So for example if one had input a rectangular poly with vertices >>> (-50,0), (50, 0), (50, 100), and (-50, 100) thus giving a poly obj at an >>> initial pos of (-50, 0) of initial size 100x100, and then resizes this >>> to be 200x200, one'd internally get the vertices (-100, 0), (100, 0), >>> (100, 200), and (-100, 200). One'd then apply the transform to those >>> vertices, and lastly translate vertices those by whatever amount would've >>> brought the un-transformed (but re-sized scaled) poly to the current obj >>> pos, and one would then render that set of vertices. >>> >>> Let me also mention yet another possible way to proceed with all >>> this poly stuff -- just for the sake of argument and completeness. >>> >> Note btw that this trio of transformations - scale the input poly >> points, apply the input affine transform to that result, and translate >> those further by the required offset.. can all be composed into a single >> affine transform to be applied to the input poly -- and this is something >> that a given engine might or might not be able to take advantage of. >> The point here being that, as with all other objects as well, one >> needs to have engine level poly-objs which hold all relevant canvas level >> state about the obj needed for its rendering.. and thus gives a single >> unified form to the engine-level obj rendering functions. One absolutely >> needs to have this for things like images (and all others really), if >> one wants to be able to introduce things like transforms to image objs -- >> ie. the engines need to have a concept of an image obj which contains >> such information as not only the src image data (what is currently used) >> but also its borders, the fill size, the object size, smooth scaling, >> the transform, and others. >> > > >> Note also that when one does introduce transforms, either 'surface' >> ones for the objs or 'vertex' ones for vertex-base
Re: [E-devel] Evas transforms/filters/etc.
Carsten wrote: > On Sat, 26 Apr 2008 00:42:47 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled: > > >>Gustavo wrote: >> >> >>> On Thu, Apr 24, 2008 at 3:54 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: >>> >>> Ok, let me give you some 'criticisms' I have of parts of the approaches to this filters stuff that both Carsten and Gustavo suggested, and let me start with: I just don't see a realistic "need" for having a built-in mechanism of arbitrary lists of arbitrary filters to be applied to any evas obj (or the rendering of such an obj), or as a canvas modifier object itself. I wish someone would point out an interesting, and/or common, real-time gui use of something besides: one specialty filter (say a blur or a bumpmap) followed by a geometric transform (and possibly all clipped by a mask). >>> in order to do cover flow-like we need: >>>1 - projection; >>>2 - mirror; >>>3 - blur the mirror; >>> >>> >>> >> That's one way, though in fact projection and mirror are >> expressible as one transform. The simplest way to do this is to >> perform the required transform and mask with a suitable gardient- >> like image (could also be defined as a single especialty filter). >> Would you like me to send you some simple software-based >> examples of how you can do this? >> > > yes projection and mirror can be merged, but blur is still a separate > filter... > so point still stands that u need to have filter pipelines. the ability to > know > what parts of the screen have what filter chain applied to what source object > data > > No you don't *need* to, not for this case - not if you have separate transforms/masks and a 'filter set' mechanism. It would reduce to what I stated: One specialty filter followed by a transform (with an optional mask which itself can be filtered, transformed - not masked). Though mind you, going thru a blur just to get a reflection-like effect is really overkill, just do a reflection with a 'fade' alpha mask.. you have some demos man. If you really must have a serial pipeline of filters, then just do the "filter a filter" bit and you can have that.. feel free to implement away, unless Gustavo beats you to it. I'll hold off on the transforms and masks. Beauty Advice Just Got a Makeover Read reviews about the beauty products you have always wanted to try http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UzujNOh13BULIPBC4zV11A2C05qQ7hIcKYlDMqSz6043SE/ - 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
Re: [E-devel] Evas transforms/filters/etc.
Carsten Haitzler (The Rasterman) wrote: > On Thu, 24 Apr 2008 14:54:20 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled: > > >> Ok, let me give you some 'criticisms' I have of parts of the >> approaches to this filters stuff that both Carsten and Gustavo >> suggested, and let me start with: >> >> I just don't see a realistic "need" for having a built-in >> mechanism of arbitrary lists of arbitrary filters to be applied >> to any evas obj (or the rendering of such an obj), or as a canvas >> modifier object itself. >> > > why not? in the end if u make it simple like clip objects work, you > effectively > build a list of filters as u apply one to another. example: > > to make a soft dropshadow for ANY objects you'd: > > 1. have a filter that makes a "copy" of an object's output/pixels > 2. takes the copy stream and reduces color to just "Black" > 3. offsets pixles by an amount > 4. applies a blur filter to this. > > Sure, and if you want to render an object with a multiplier color and a blend op, at some point on the canvas, you could: 1. have a filter that makes a "copy" of an object's output/pixels 2. takes the copy stream and multiplies it by the given color 3. offsets pixles by an amount etc... You can always break up any sufficiently involved operation into some extended set of parts, and you can consider just about any kind of operation as a 'filter'. This is not an argument for or against the issue at hand. Are you suggesting that "move", "resize", "color", ... should all be removed and made part of a general filter pipeline? Or conversely, that the existence of such separate kinds of filters (move, resize,..) is a good argument for the need for such a pipeline? What we're talking about is a realistic, real-time, need for an arbitrary gfx filter pipeline that's automatic, ie. a sequence of gfx filters is prepared and applied, if need be, when evas render calls. > of course this is actually probably more sensical if a special "dropshadow > anything" filter existed that just did all of this. > > Errr.. Gee, how about that. Are you feeling ok, maybe too much partying lately..? :) >> I wish someone would point out an interesting, and/or common, >> real-time gui use of something besides: one specialty filter (say a >> blur or a bumpmap) followed by a geometric transform (and possibly >> all clipped by a mask). >> > > as above. :) > See what above... some artificial construct that you then point as being basically just one standard filter (blur with radius,... params)? > >> Anything more involved than that I'd say should be left to >> immediate-mode mechanisms for people to compose things as they >> wish (working with image objs), ie. draw the obj to an image obj >> and proceed to work with such.. use whatever eventual im obj to >> represent whatever bizarre, complex, slowly-arrived-at result you >> wanted.. I doubt one'd be going thru these steps all the time, >> so might as well create what complex effect you want and save it >> as an image obj for your actual real-time use (and any animations >> on this kind of thing you'd probably want to do apart from that, >> ie. on that result). >> >> Summer Spa Sweepstakes Enter for your chance to WIN a Summer Spa Vacation! http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UbeoRzA9UoKkFU8OyRY3e6l2cBkTpQR2y4vfE6h7LmpdPu/ - 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
Re: [E-devel] Evas_Quartz Code, Ready for Reviews!
On Mon, 7 Jul 2008, Timothy P. Horton wrote: > I've uploaded a very preliminary version of my Summer of Code project, > the Evas_Quartz engine to Google Code, and opened it up for reviews. > Anyone interested, please come review my code! > > I'll warn anyone who's interested in reviewing that the code is rather > preliminary, there's lots of stuff missing, etc. > > Google Code project (for review): http://code.google.com/p/evas-quartz/ why didn't you add quartz support to the current glew engine ? It would have only been a matter of writing something similar to your gl_quartz/evas_quartz_main.c in gl_glew/ and minor modifications. That is, you would have had an engine almost without any work remark 1: i would rename the directory "quartz" to "software_quartz" if it does not use any specific acceleration, like other engines. remark 2: in quartz/engine.h, you defined a structure named _Evas_Quartz_Window but it is not obvious that it represents a window. In addition, in the definition of eng_window_new(), the parameters w and h are not used. Maybe you should remove them. anyway, nice work :) Vincent - 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
Re: [E-devel] Evas_Quartz Code, Ready for Reviews!
and a more direct link to view the code: http://code.google.com/p/evas-quartz/source/browse On Mon, Jul 7, 2008 at 9:09 PM, Timothy P. Horton <[EMAIL PROTECTED]> wrote: > I've uploaded a very preliminary version of my Summer of Code project, > the Evas_Quartz engine to Google Code, and opened it up for reviews. > Anyone interested, please come review my code! > > I'll warn anyone who's interested in reviewing that the code is rather > preliminary, there's lots of stuff missing, etc. > > Google Code project (for review): http://code.google.com/p/evas-quartz/ > > Thanks! > > Tim Horton > > - > 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 > - 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
[E-devel] Evas_Quartz Code, Ready for Reviews!
I've uploaded a very preliminary version of my Summer of Code project, the Evas_Quartz engine to Google Code, and opened it up for reviews. Anyone interested, please come review my code! I'll warn anyone who's interested in reviewing that the code is rather preliminary, there's lots of stuff missing, etc. Google Code project (for review): http://code.google.com/p/evas-quartz/ Thanks! Tim Horton - 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
Re: [E-devel] Shared Strings
On Mon, Jul 7, 2008 at 6:45 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > I've put now the evas stringshare code into a standalone lib. I know > that Nathan is working on improving ecore_hash, so that ecore_string > becomes faster. We can still change the code later, since the API and > ABI remains the same. I called that lib "edt" for "enlighten data > types". At this point, I'm going to point you to Jorge's edata. Stuff should go in there if anything. -- Hisham Mardam Bey http://hisham.cc/ - 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
Re: [E-devel] Theme version and name
I agree with you KainX. It is a bit of a mess. The application the
theme generally themes is put in the name or filename of it.
And yes, lets stick to KISS to begin with and then go from there. If a
definite need to have those other things is found, then I guess it can
be adopted, but I cant see that happening.
Viktor: Im not too sure on that one. EWL has some of these components
in the theme already and they start with /theme, but I wasnt sure if
/theme/ and theme/ were the same thing. Otherwise, definitely scrap
the leading /.
Toma
2008/7/8 Viktor Kojouharov <[EMAIL PROTECTED]>:
> Since the current naming practice for edje parts is to start with a
> letter, instead of '/', wouldn't it be better to keep it here:
>
> item: "theme/application/e/version" "xxx"
>
> On Mon, 2008-07-07 at 14:23 +0200, Dave Andreoli wrote:
>> - "Toma" <[EMAIL PROTECTED]> ha scritto:
>>
>> > So change /theme/base_version to /theme/application_version too?
>> > Sounds fun. What about themes that contain multiple themes packs? Eg.
>> > detour? Or the new idea of combining e17 themes with etk and ewl
>> > components installed? Would items with the same name be overwritten
>> > by
>> > the last one loaded? Or just load them with "e etk ewl" in the same
>> > space...
>>
>> hmmm, this is a problem... we can use:
>> item: "/theme/applications" "e etk ewl";
>>
>> but then we also need multiple "application_version" fiels, like:
>> item: "/theme/e_version""xxx"
>> item: "/theme/etk_version" "xxx"
>> item: "/theme/ewl_version" "xxx"
>>
>> Dave
>>
>>
>>
>> > Toma
>> >
>> > 2008/7/7 Dave Andreoli <[EMAIL PROTECTED]>:
>> > >
>> > > - "Toma" <[EMAIL PROTECTED]> ha scritto:
>> > >
>> > >> Ok folks! Heres a final revision. Note the removal of e/ so that
>> > it
>> > >> can be universally used without the need to figure out the leading
>> > >> name (if there are any). Also included is 'base_version' to
>> > outline
>> > >> the base version of the application needed to use the theme.
>> > Again,
>> > >> its a non-specific name so it can be used universally too. If
>> > there
>> > >> are no objections, Ill start stuffing this into my themes and hope
>> > >> that it gets picked up by everyone else soon enough.
>> > >>
>> > >> data {
>> > >> item: "/theme/name" "Fireball";
>> > >> item: "/theme/version" "1.6";
>> > >> item: "/theme/license" "GPL";
>> > >> item: "/theme/author""Tom Haste ([EMAIL PROTECTED])";
>> > >> item: "/theme/base_version" "CVS";
>> > >> }
>> > >
>> > > IMHO I would add a fileld with the name of the application the theme
>> > is for.
>> > > like
>> > > item: "/theme/application" "e";
>> > > item: "/theme/application" "etk";
>> > > item: "/theme/application" "edje_editor";
>> > >
>> > > Or you will have to read all the contents everytime just to check if
>> > the
>> > > theme is right for you.
>> > > Also applications that want to make a check on the theme, will just
>> > have
>> > > to read at this fields instead of reading all of the parts list.
>> > >
>> > > Dave
>> > >
>> > >>
>> > >> Toma.
>> > >>
>> > >> Also... CVS can be swapped with '16.999.043' for people that wish
>> > to
>> > >> stay with the snapshots or the folks in elive can name it
>> > >> accordingly.
>> > >>
>> > >> 2008/7/2 Dale Anderson <[EMAIL PROTECTED]>:
>> > >> > Toma wrote:
>> > >> >>
>> > >> >> 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 actu
Re: [E-devel] Shared Strings
Peter Wehrfritz schrieb: > Yesterday we had a discussion on irc, if we should put abstract data > types of ecore and of evas into a single standalone lib. The whole > discussion came up because of the two implementations of the shared > strings. And in fact if we really want to share strings efficient, we > have to share them over the borders of the different libraries. > > Raster's idea was to first put the shared string stuff in this new > library because both implementation have the same api (of course the > names are different) and the same functionality. Remains the question > which implementation we use. > I've put now the evas stringshare code into a standalone lib. I know that Nathan is working on improving ecore_hash, so that ecore_string becomes faster. We can still change the code later, since the API and ABI remains the same. I called that lib "edt" for "enlighten data types". If you prefer another name I can change it easily. It isn't much work at that point. I also can change the function names they are now: edt_stringshare_init edt_stringshare_shutdown edt_stringshare_add edt_stringshare_del If you like it, i can commit it. Next step would be to make ecore and evas depend on edt. And make their functions to be only wrappers around edt's one. And then we can replace step by step the names in the libs and apps. You can find the lib here: www.mowem.de/e/edt.tar.gz Kind Regards Peter - 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
Re: [E-devel] [RFC] Evas_Rectangles for evas_object_render_pre_effect_updates
On Fri, 6 Jun 2008 11:05:57 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> babbled: > With the last serie of patch I committed inside evas, evas_render > should now be working again correctly. This fixed version only give > around 7% of speedup to expedite test and some are a little bit slower > than the previous. > > So after diging a little bit more the slower tests case of expedite, I > think the attached patch will make all expedite test as fast as > without the cache inside evas_render and give a global 10% speedup to > expedite without any cache. > > The idea is to remove as much allocation and list manipulation as > possible by implementing a special array of Evas_Rectangle. This patch > work for me on all my application, E17 and edje old test application. > > So as always have fun reviewing this patch ! overall sounds good to me. in cvs it is. we can nuke mini-bugs found as needed :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] Ecore_Con.h problem
On Mon, 26 May 2008 17:13:43 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> babbled: the real problem is struct hostent... imho we should virtualise this into our own struct for compatibility or remove the dns lookup call. i know we have the guards there now, but it isn't pretty. does anyone actually use this call (*as it's not strictly needed as ecore_con does the dns lookup async for you in the background anyway when connecting...)? > Hey, > > I have added guards around the inclusion of netdb.h in Ecore_Con.h > > That implies that for all projects that uses Ecore_Con.h, netdb.h must be > checks by AC_CHECK_HEADERS (or just define HAVE_NETDB_H when compiling the > program / library) > > In one hand, it is safer to check netdb.h, on the other hand, I find ugly > to have such guards in Ecore_Con.h > > What do you think it is the best ? removing thos guards, or keeping them ? > > Vincent > > - > 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] - 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
Re: [E-devel] Evas transforms/filters/etc.
On Thu, 24 Apr 2008 14:54:20 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled: > > Ok, let me give you some 'criticisms' I have of parts of the > approaches to this filters stuff that both Carsten and Gustavo > suggested, and let me start with: > > I just don't see a realistic "need" for having a built-in > mechanism of arbitrary lists of arbitrary filters to be applied > to any evas obj (or the rendering of such an obj), or as a canvas > modifier object itself. why not? in the end if u make it simple like clip objects work, you effectively build a list of filters as u apply one to another. example: to make a soft dropshadow for ANY objects you'd: 1. have a filter that makes a "copy" of an object's output/pixels 2. takes the copy stream and reduces color to just "Black" 3. offsets pixles by an amount 4. applies a blur filter to this. of course this is actually probably more sensical if a special "dropshadow anything" filter existed that just did all of this. > I wish someone would point out an interesting, and/or common, > real-time gui use of something besides: one specialty filter (say a > blur or a bumpmap) followed by a geometric transform (and possibly > all clipped by a mask). as above. :) > Anything more involved than that I'd say should be left to > immediate-mode mechanisms for people to compose things as they > wish (working with image objs), ie. draw the obj to an image obj > and proceed to work with such.. use whatever eventual im obj to > represent whatever bizarre, complex, slowly-arrived-at result you > wanted.. I doubt one'd be going thru these steps all the time, > so might as well create what complex effect you want and save it > as an image obj for your actual real-time use (and any animations > on this kind of thing you'd probably want to do apart from that, > ie. on that result). > > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > 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] - 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
Re: [E-devel] [PATCH] e_desklock: Erase binding
On Mon, 19 May 2008 23:20:34 +0200 Beber <[EMAIL PROTECTED]> babbled: > Hi, > > Here is a patch for e_desklock to add a binding on Ctrl-U to flush > input password as the common way on Unix system to flush an input. in cvs. :) thanks! -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] Evas transforms/filters/etc.
On Sat, 26 Apr 2008 00:42:47 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled: >Gustavo wrote: > > > On Thu, Apr 24, 2008 at 3:54 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > > > >> Ok, let me give you some 'criticisms' I have of parts of the > >> approaches to this filters stuff that both Carsten and Gustavo > >> suggested, and let me start with: > >> > >> I just don't see a realistic "need" for having a built-in > >> mechanism of arbitrary lists of arbitrary filters to be applied > >> to any evas obj (or the rendering of such an obj), or as a canvas > >> modifier object itself. > >> > >> I wish someone would point out an interesting, and/or common, > >> real-time gui use of something besides: one specialty filter (say a > >> blur or a bumpmap) followed by a geometric transform (and possibly > >> all clipped by a mask). > >> > > > > in order to do cover flow-like we need: > >1 - projection; > >2 - mirror; > >3 - blur the mirror; > > > > > > That's one way, though in fact projection and mirror are > expressible as one transform. The simplest way to do this is to > perform the required transform and mask with a suitable gardient- > like image (could also be defined as a single especialty filter). > Would you like me to send you some simple software-based > examples of how you can do this? yes projection and mirror can be merged, but blur is still a separate filter... so point still stands that u need to have filter pipelines. the ability to know what parts of the screen have what filter chain applied to what source object data -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] [Ecore] pipe wrapper
On Sun, 11 May 2008 06:59:29 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> babbled: hmm. the pipe abstraction looks strange to me. why should i be limited to writing just 1 void * down the pipe at a time. isn't the diea that i write whatever i want (void *'s, int's, chars, whole arrays of ints or void *'s) and the other end just picks them up? u really need to be able to set the pipe up as blocking or non-blocking and be able to get the read or write fd from the pipe. you will want this when read()ing off a blocking pipe in a sub-thread, if that is how you are waiting for messages there, for example. > Hey, > > > seems a good simple start - needs to be more complete, like actually close() > > ing pips on delete - also i agree with peter, ecore_pipe_add and > > ecore_pipe_del - also i would add ecore events for pipe data - like > > ecore_con, and pass the WHOLE data read (not just 1 void* size element at a > > time). yes - then u need to handle decode of multiple bytes - but that's > > reality really). > > > > so go the event + event struct with pipe data in it + ecore_pipe_add/del and > > finish off the free stuff and i think you have a winner :) > > I've attached a new version. I've renamed the functions, closed the fd's. > I've also added an event that is added in the event queue when data is > received. > > About passing the whole data, i don't know how to do that. I send the > pointer of the data, i thought it was sufficient. It's what is done in > emotion, btw. > > Vincent -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] initial scrolled_view->viewport
2008/7/7 Tick Chen <[EMAIL PROTECTED]>: > Hi List, > Because of scrolled_view->viewport may not initialized before used, > the etk_tree will crash from Jun first. > I created a small patch to deal with this issue. > > Cheers, > Tick > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIcl5vPNWONWpVfqoRAoWJAJ9RUmWJ6w9/hJlrpudcqlHqm/GuEwCggOIV > 7K7e1vgjk5byjKjNR25OB04= > =CXqJ > -END PGP SIGNATURE- > > - > 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 > > Good work! If you have just a little more time, you can also fix three compiler warnings on etk_scrolled_view.c , lines 727, 770 and 806 , lust a trivial fix. Thx Massimiliano - 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
[E-devel] initial scrolled_view->viewport
Hi List, Because of scrolled_view->viewport may not initialized before used, the etk_tree will crash from Jun first. I created a small patch to deal with this issue. Cheers, Tick Index: etk/src/lib/etk_scrolled_view.c === --- etk.orig/src/lib/etk_scrolled_view.c 2008-07-08 02:00:18.0 +0800 +++ etk/src/lib/etk_scrolled_view.c 2008-07-08 02:01:27.0 +0800 @@ -324,6 +324,8 @@ if (!scrolled_view) return; + scrolled_view->viewport = NULL; + scrolled_view->hpolicy = ETK_POLICY_AUTO; scrolled_view->vpolicy = ETK_POLICY_AUTO; signature.asc Description: Digital signature - 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
Re: [E-devel] Theme version and name
Since the current naming practice for edje parts is to start with a
letter, instead of '/', wouldn't it be better to keep it here:
item: "theme/application/e/version" "xxx"
On Mon, 2008-07-07 at 14:23 +0200, Dave Andreoli wrote:
> - "Toma" <[EMAIL PROTECTED]> ha scritto:
>
> > So change /theme/base_version to /theme/application_version too?
> > Sounds fun. What about themes that contain multiple themes packs? Eg.
> > detour? Or the new idea of combining e17 themes with etk and ewl
> > components installed? Would items with the same name be overwritten
> > by
> > the last one loaded? Or just load them with "e etk ewl" in the same
> > space...
>
> hmmm, this is a problem... we can use:
> item: "/theme/applications" "e etk ewl";
>
> but then we also need multiple "application_version" fiels, like:
> item: "/theme/e_version""xxx"
> item: "/theme/etk_version" "xxx"
> item: "/theme/ewl_version" "xxx"
>
> Dave
>
>
>
> > Toma
> >
> > 2008/7/7 Dave Andreoli <[EMAIL PROTECTED]>:
> > >
> > > - "Toma" <[EMAIL PROTECTED]> ha scritto:
> > >
> > >> Ok folks! Heres a final revision. Note the removal of e/ so that
> > it
> > >> can be universally used without the need to figure out the leading
> > >> name (if there are any). Also included is 'base_version' to
> > outline
> > >> the base version of the application needed to use the theme.
> > Again,
> > >> its a non-specific name so it can be used universally too. If
> > there
> > >> are no objections, Ill start stuffing this into my themes and hope
> > >> that it gets picked up by everyone else soon enough.
> > >>
> > >> data {
> > >> item: "/theme/name" "Fireball";
> > >> item: "/theme/version" "1.6";
> > >> item: "/theme/license" "GPL";
> > >> item: "/theme/author""Tom Haste ([EMAIL PROTECTED])";
> > >> item: "/theme/base_version" "CVS";
> > >> }
> > >
> > > IMHO I would add a fileld with the name of the application the theme
> > is for.
> > > like
> > > item: "/theme/application" "e";
> > > item: "/theme/application" "etk";
> > > item: "/theme/application" "edje_editor";
> > >
> > > Or you will have to read all the contents everytime just to check if
> > the
> > > theme is right for you.
> > > Also applications that want to make a check on the theme, will just
> > have
> > > to read at this fields instead of reading all of the parts list.
> > >
> > > Dave
> > >
> > >>
> > >> Toma.
> > >>
> > >> Also... CVS can be swapped with '16.999.043' for people that wish
> > to
> > >> stay with the snapshots or the folks in elive can name it
> > >> accordingly.
> > >>
> > >> 2008/7/2 Dale Anderson <[EMAIL PROTECTED]>:
> > >> > Toma wrote:
> > >> >>
> > >> >> 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.
> > >>
Re: [E-devel] Theme version and name
On Monday, 07 July 2008, at 10:22:50 (-0700), Michael Jennings wrote: > 1. Use the hierarchy you already have. Don't invent silly additional > separators (like '_') for no reason. > > item: "/theme/application/e/min_version""0.16.999.043"; > item: "/theme/application/ewl/min_version" "0.5.1"; Or even better, taking my own advice: item: "/theme/application/e/version/min""0.16.999.043"; item: "/theme/application/ewl/version/min" "0.5.1"; Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "Oh gaze of love, so melt my pride that I may in your house but kneel, and in my brokenness to cry spring worship unto thee." -- Jars of Clay, "Hymn" - 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
Re: [E-devel] Theme version and name
On Monday, 07 July 2008, at 14:23:51 (+0200), Dave Andreoli wrote: > hmmm, this is a problem... we can use: > item: "/theme/applications" "e etk ewl"; > > but then we also need multiple "application_version" fiels, like: > item: "/theme/e_version""xxx" > item: "/theme/etk_version" "xxx" > item: "/theme/ewl_version" "xxx" 1. Use the hierarchy you already have. Don't invent silly additional separators (like '_') for no reason. item: "/theme/application/e/min_version""0.16.999.043"; item: "/theme/application/ewl/min_version" "0.5.1"; 2. Don't duplicate information. Think like a database: normalize. The existence of "/theme/application/" implies that "/theme/applications" would contain "". 3. This whole mess is a very bad idea. Handling versioned dependencies is a much, much harder problem than you realize. And restricting what applications are allowed to peek at a theme's bits is silly. Just make the bits available to whatever application wants to use them, and don't try to reinvent dependencies. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "This is how the world ends: swallowed in fire, but not in darkness. You will live on. The voice of all our ancestors, the voice of our fathers and our mothers to the last generation. We created the world we think you would have wished for us, and now we leave the cradle for the last time." -- Babylon Five - 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
Re: [E-devel] Event_Struct and Ecore_Job?
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
Re: [E-devel] Theme version and name
I think we need to stop guessing / forcing a method of detecting theme
compatibility.
/theme/applications being a set of space-separated values looks very
hackish and not at all useful.
Instead we should let each app decide how they want to handle it..
probably by using their own attribute name.
Its already possible to detect which app a theme applies to by looking
at the edje groups.
Also, I dont see any need to have a contact field separate from the
author field, nor do I see any need to be able to easily retrieve the
author's email programatically. Its only useful for spammers, normal
users can take the time to type the email address.
I think we were going in the right direction in the beginning.
If a specific app needs extra features, that app can require them..
but the generic pieces should start out short and simple.
On Mon, Jul 7, 2008 at 9:38 AM, Toma <[EMAIL PROTECTED]> wrote:
> 2008/7/7 muzzle <[EMAIL PROTECTED]>:
>> Hi
>>
>> On Mon, Jul 7, 2008 at 3:14 AM, Toma <[EMAIL PROTECTED]> wrote:
>>>
>>> Ok folks! Heres a final revision. Note the removal of e/ so that it
>>> can be universally used without the need to figure out the leading
>>> name (if there are any). Also included is 'base_version' to outline
>>> the base version of the application needed to use the theme. Again,
>>> its a non-specific name so it can be used universally too. If there
>>> are no objections, Ill start stuffing this into my themes and hope
>>> that it gets picked up by everyone else soon enough.
>>>
>>> data {
>>> item: "/theme/name" "Fireball";
>>> item: "/theme/version" "1.6";
>>> item: "/theme/license" "GPL";
>>> item: "/theme/author""Tom Haste ([EMAIL PROTECTED])";
>>
>> I think it would be useful to have a different field for the author
>> email and another for the author/theme website. Future theme manager
>> applications might take advantage of this to let the user send
>> feedback (or praise) quickly.
>
> In that respect, a /theme/contact could link straight to a website or
> an email address. No need for 2 really, since those with a website
> generally have their email on that and those without a website could
> just drop an email in there. Or just simply leave the field blank.
> Toma
>
>>
>> Cheers,
>>
>> Emme
>>
>>> item: "/theme/base_version" "CVS";
>>> }
>>>
>>> Toma.
>>>
>>> Also... CVS can be swapped with '16.999.043' for people that wish to
>>> stay with the snapshots or the folks in elive can name it accordingly.
>>>
>>> 2008/7/2 Dale Anderson <[EMAIL PROTECTED]>:
>>> > Toma wrote:
>>> >>
>>> >> 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.
>>> >>
>>> >
>>> > Thats all very well and fine while e17 is still *in development* , but
>>> > when
>>> > there are releases we need to be able to cater for such down the track.
>>> > Themer's are going to have to take this into account also in the future.
>>> >
>>> > Cheers
>>> > Dale.
>>> >
>>> >> Im going to spend the next week or so polishing up everyt
[E-devel] Nightly build log for E17 on 2008-07-07 07:10:22 -0700
Build log for Enlightenment DR 0.17 on 2008-07-07 07:10:22 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edvi http://download.enlightenment.org/tests/logs/edvi.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log express http://download.enlightenment.org/tests/logs/express.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, 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, 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, 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. - 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
Re: [E-devel] Theme version and name
2008/7/7 muzzle <[EMAIL PROTECTED]>:
> Hi
>
> On Mon, Jul 7, 2008 at 3:14 AM, Toma <[EMAIL PROTECTED]> wrote:
>>
>> Ok folks! Heres a final revision. Note the removal of e/ so that it
>> can be universally used without the need to figure out the leading
>> name (if there are any). Also included is 'base_version' to outline
>> the base version of the application needed to use the theme. Again,
>> its a non-specific name so it can be used universally too. If there
>> are no objections, Ill start stuffing this into my themes and hope
>> that it gets picked up by everyone else soon enough.
>>
>> data {
>> item: "/theme/name" "Fireball";
>> item: "/theme/version" "1.6";
>> item: "/theme/license" "GPL";
>> item: "/theme/author""Tom Haste ([EMAIL PROTECTED])";
>
> I think it would be useful to have a different field for the author
> email and another for the author/theme website. Future theme manager
> applications might take advantage of this to let the user send
> feedback (or praise) quickly.
In that respect, a /theme/contact could link straight to a website or
an email address. No need for 2 really, since those with a website
generally have their email on that and those without a website could
just drop an email in there. Or just simply leave the field blank.
Toma
>
> Cheers,
>
> Emme
>
>> item: "/theme/base_version" "CVS";
>> }
>>
>> Toma.
>>
>> Also... CVS can be swapped with '16.999.043' for people that wish to
>> stay with the snapshots or the folks in elive can name it accordingly.
>>
>> 2008/7/2 Dale Anderson <[EMAIL PROTECTED]>:
>> > Toma wrote:
>> >>
>> >> 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.
>> >>
>> >
>> > Thats all very well and fine while e17 is still *in development* , but when
>> > there are releases we need to be able to cater for such down the track.
>> > Themer's are going to have to take this into account also in the future.
>> >
>> > Cheers
>> > Dale.
>> >
>> >> 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
Re: [E-devel] Theme version and name
Hi
On Mon, Jul 7, 2008 at 3:14 AM, Toma <[EMAIL PROTECTED]> wrote:
>
> Ok folks! Heres a final revision. Note the removal of e/ so that it
> can be universally used without the need to figure out the leading
> name (if there are any). Also included is 'base_version' to outline
> the base version of the application needed to use the theme. Again,
> its a non-specific name so it can be used universally too. If there
> are no objections, Ill start stuffing this into my themes and hope
> that it gets picked up by everyone else soon enough.
>
> data {
> item: "/theme/name" "Fireball";
> item: "/theme/version" "1.6";
> item: "/theme/license" "GPL";
> item: "/theme/author""Tom Haste ([EMAIL PROTECTED])";
I think it would be useful to have a different field for the author
email and another for the author/theme website. Future theme manager
applications might take advantage of this to let the user send
feedback (or praise) quickly.
Cheers,
Emme
> item: "/theme/base_version" "CVS";
> }
>
> Toma.
>
> Also... CVS can be swapped with '16.999.043' for people that wish to
> stay with the snapshots or the folks in elive can name it accordingly.
>
> 2008/7/2 Dale Anderson <[EMAIL PROTECTED]>:
> > Toma wrote:
> >>
> >> 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.
> >>
> >
> > Thats all very well and fine while e17 is still *in development* , but when
> > there are releases we need to be able to cater for such down the track.
> > Themer's are going to have to take this into account also in the future.
> >
> > Cheers
> > Dale.
> >
> >> 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";
Re: [E-devel] Theme version and name
- "Toma" <[EMAIL PROTECTED]> ha scritto:
> So change /theme/base_version to /theme/application_version too?
> Sounds fun. What about themes that contain multiple themes packs? Eg.
> detour? Or the new idea of combining e17 themes with etk and ewl
> components installed? Would items with the same name be overwritten
> by
> the last one loaded? Or just load them with "e etk ewl" in the same
> space...
hmmm, this is a problem... we can use:
item: "/theme/applications" "e etk ewl";
but then we also need multiple "application_version" fiels, like:
item: "/theme/e_version""xxx"
item: "/theme/etk_version" "xxx"
item: "/theme/ewl_version" "xxx"
Dave
> Toma
>
> 2008/7/7 Dave Andreoli <[EMAIL PROTECTED]>:
> >
> > - "Toma" <[EMAIL PROTECTED]> ha scritto:
> >
> >> Ok folks! Heres a final revision. Note the removal of e/ so that
> it
> >> can be universally used without the need to figure out the leading
> >> name (if there are any). Also included is 'base_version' to
> outline
> >> the base version of the application needed to use the theme.
> Again,
> >> its a non-specific name so it can be used universally too. If
> there
> >> are no objections, Ill start stuffing this into my themes and hope
> >> that it gets picked up by everyone else soon enough.
> >>
> >> data {
> >> item: "/theme/name" "Fireball";
> >> item: "/theme/version" "1.6";
> >> item: "/theme/license" "GPL";
> >> item: "/theme/author""Tom Haste ([EMAIL PROTECTED])";
> >> item: "/theme/base_version" "CVS";
> >> }
> >
> > IMHO I would add a fileld with the name of the application the theme
> is for.
> > like
> > item: "/theme/application" "e";
> > item: "/theme/application" "etk";
> > item: "/theme/application" "edje_editor";
> >
> > Or you will have to read all the contents everytime just to check if
> the
> > theme is right for you.
> > Also applications that want to make a check on the theme, will just
> have
> > to read at this fields instead of reading all of the parts list.
> >
> > Dave
> >
> >>
> >> Toma.
> >>
> >> Also... CVS can be swapped with '16.999.043' for people that wish
> to
> >> stay with the snapshots or the folks in elive can name it
> >> accordingly.
> >>
> >> 2008/7/2 Dale Anderson <[EMAIL PROTECTED]>:
> >> > Toma wrote:
> >> >>
> >> >> 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.
> >> >>
> >> >
> >> > Thats all very well and fine while e17 is still *in development*
> ,
> >> but when
> >> > there are releases we need to be able to cater for such down the
> >> track.
> >> > Themer's are going to have to take this into account also in the
> >> future.
> >> >
> >> > Cheers
> >> > Dale.
> >> >
> >> >> 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
Re: [E-devel] Theme version and name
So change /theme/base_version to /theme/application_version too?
Sounds fun. What about themes that contain multiple themes packs? Eg.
detour? Or the new idea of combining e17 themes with etk and ewl
components installed? Would items with the same name be overwritten by
the last one loaded? Or just load them with "e etk ewl" in the same
space...
Toma
2008/7/7 Dave Andreoli <[EMAIL PROTECTED]>:
>
> - "Toma" <[EMAIL PROTECTED]> ha scritto:
>
>> Ok folks! Heres a final revision. Note the removal of e/ so that it
>> can be universally used without the need to figure out the leading
>> name (if there are any). Also included is 'base_version' to outline
>> the base version of the application needed to use the theme. Again,
>> its a non-specific name so it can be used universally too. If there
>> are no objections, Ill start stuffing this into my themes and hope
>> that it gets picked up by everyone else soon enough.
>>
>> data {
>> item: "/theme/name" "Fireball";
>> item: "/theme/version" "1.6";
>> item: "/theme/license" "GPL";
>> item: "/theme/author""Tom Haste ([EMAIL PROTECTED])";
>> item: "/theme/base_version" "CVS";
>> }
>
> IMHO I would add a fileld with the name of the application the theme is for.
> like
> item: "/theme/application" "e";
> item: "/theme/application" "etk";
> item: "/theme/application" "edje_editor";
>
> Or you will have to read all the contents everytime just to check if the
> theme is right for you.
> Also applications that want to make a check on the theme, will just have
> to read at this fields instead of reading all of the parts list.
>
> Dave
>
>>
>> Toma.
>>
>> Also... CVS can be swapped with '16.999.043' for people that wish to
>> stay with the snapshots or the folks in elive can name it
>> accordingly.
>>
>> 2008/7/2 Dale Anderson <[EMAIL PROTECTED]>:
>> > Toma wrote:
>> >>
>> >> 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.
>> >>
>> >
>> > Thats all very well and fine while e17 is still *in development* ,
>> but when
>> > there are releases we need to be able to cater for such down the
>> track.
>> > Themer's are going to have to take this into account also in the
>> future.
>> >
>> > Cheers
>> > Dale.
>> >
>> >> 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
>> >>> ite
Re: [E-devel] Theme version and name
- "Toma" <[EMAIL PROTECTED]> ha scritto:
> Ok folks! Heres a final revision. Note the removal of e/ so that it
> can be universally used without the need to figure out the leading
> name (if there are any). Also included is 'base_version' to outline
> the base version of the application needed to use the theme. Again,
> its a non-specific name so it can be used universally too. If there
> are no objections, Ill start stuffing this into my themes and hope
> that it gets picked up by everyone else soon enough.
>
> data {
> item: "/theme/name" "Fireball";
> item: "/theme/version" "1.6";
> item: "/theme/license" "GPL";
> item: "/theme/author""Tom Haste ([EMAIL PROTECTED])";
> item: "/theme/base_version" "CVS";
> }
IMHO I would add a fileld with the name of the application the theme is for.
like
item: "/theme/application" "e";
item: "/theme/application" "etk";
item: "/theme/application" "edje_editor";
Or you will have to read all the contents everytime just to check if the
theme is right for you.
Also applications that want to make a check on the theme, will just have
to read at this fields instead of reading all of the parts list.
Dave
>
> Toma.
>
> Also... CVS can be swapped with '16.999.043' for people that wish to
> stay with the snapshots or the folks in elive can name it
> accordingly.
>
> 2008/7/2 Dale Anderson <[EMAIL PROTECTED]>:
> > Toma wrote:
> >>
> >> 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.
> >>
> >
> > Thats all very well and fine while e17 is still *in development* ,
> but when
> > there are releases we need to be able to cater for such down the
> track.
> > Themer's are going to have to take this into account also in the
> future.
> >
> > Cheers
> > Dale.
> >
> >> 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
Re: [E-devel] [RFC] Evas_Object_Polygons speed improvements
On Fri, Jul 4, 2008 at 2:46 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: >>> That would probably be a good way to do it. So, the vertex >>> coords are floats which correspond to sub-pixel precision canvas coords. >>> Every time one 'sets' the poly points the previous poly obj >>> geometry is invalidated and the new one calculated thus determining >>> the obj's size and pos (top-left corner of int bounding rect). >>> Moving the poly obj will mean rendering the vertices suitably >>> translated. >>> Resizing the poly internally scales the vertices by the float >>> fraction of the new size to the input-poly-size, and presrves the poly >>> obj's pos. >>> This will again mean rendering the so changed vertices accordingly. Note >>> that >>> this may have a bit of 'jitter' due to sizes being only integer values.. but >>> one is also always free to transform the set of vertices as desired and set >>> them again. In fact, it would eventually be good to have an api function for >>> setting such a vertex transformation on such objects - say something >>> like >>> >>> evas_object_polygon_points_transform_set(obj, *t); >>> >>> where the 't' will be an evas transformation, say possibly an affine >>> and/or projective transform. This transform will act on the vertices for the >>> purposes of rendering, but not affect the reported object size or position - >>> though one would eventually like to have the effective 'bounding rect' of >>> any >>> transformed obje, whether it's a result of a general object (surface) >>> transform or of a specilaized vertex transform on certain objects that might >>> support that. >> >> Though this wouldn't have to be done til later (if desired), let me >> suggest a possible semantics for the use of such 'set' transforms on >> vertex-based objects like polys. >> First of all, I'd limit the transforms to only affine ones (though >> I won't into why here - just mentioning it), so if one inputs a transform >> with projective components, only the affine part is used. I would like to know why we should have such a restriction as I don't have as much background on this as you have. >> Then, one would first scale the input vertices according to the poly >> obj size but rel to the origin, apply the transform to those points, and >> translate forward to its obj position. >> So for example if one had input a rectangular poly with vertices >> (-50,0), (50, 0), (50, 100), and (-50, 100) thus giving a poly obj at an >> initial pos of (-50, 0) of initial size 100x100, and then resizes this >> to be 200x200, one'd internally get the vertices (-100, 0), (100, 0), >> (100, 200), and (-100, 200). One'd then apply the transform to those >> vertices, and lastly translate vertices those by whatever amount would've >> brought the un-transformed (but re-sized scaled) poly to the current obj >> pos, and one would then render that set of vertices. >> >> Let me also mention yet another possible way to proceed with all >> this poly stuff -- just for the sake of argument and completeness. > > Note btw that this trio of transformations - scale the input poly > points, apply the input affine transform to that result, and translate > those further by the required offset.. can all be composed into a single > affine transform to be applied to the input poly -- and this is something > that a given engine might or might not be able to take advantage of. > The point here being that, as with all other objects as well, one > needs to have engine level poly-objs which hold all relevant canvas level > state about the obj needed for its rendering.. and thus gives a single > unified form to the engine-level obj rendering functions. One absolutely > needs to have this for things like images (and all others really), if > one wants to be able to introduce things like transforms to image objs -- > ie. the engines need to have a concept of an image obj which contains > such information as not only the src image data (what is currently used) > but also its borders, the fill size, the object size, smooth scaling, > the transform, and others. > Note also that when one does introduce transforms, either 'surface' > ones for the objs or 'vertex' ones for vertex-based objs like polys, lines, > paths, ... then the update region that objects need to generate is no longer > limited to be a subregion of the object's 'geometry' as is exclusively > done now - one needs the object's effective bounding rect. I like the idea of behing able to apply a transformation to a polygon, it should be easy to add to the polygon and easy to understand in this scope, but this API should stay consistent with other evas object. I don't think we are ready at this point to plan this kind of transformation to all evas object and making it a special case only for polygons, could make it harder for a later implementation. So I would plan this kind of API for later. First we change the way we define polygons point
