On Fri, 7 Nov 2003 18:57:54 -0600 Ibukun Olumuyiwa <[EMAIL PROTECTED]>
babbled:
> > me for one will be saying "nup - NOT going into edje". for ONE it breaks the
> > model where now edje is dependant on X. no. the answer is NO. if you want
> > this - DIY.
> >
>
> I certainly agree that inside of Edje is not the place to add such a hack.
> However, I would rather favor it as an image loader of sorts in Evas
> instead -- that seems to be much more logical. And since it is an ugly
> hack and has its problems, it should be optional, rather than compiled in
> by default -- and application developers will have to make sure that their
> apps look fine without the feature available.
it is orthogonal ot real transparency. the ONLY place i could see this as
working is ecore_evas. anywhere else is WRONG. if in ecore_evas it'd be another
option to the canvas to put in a background object in the canvas that keeps sync
witht eh canvas window on the screen and the desktop pixmap - but i am not going
to get my fingers dirty with this.
> > its horrid. its nasty. its just plain WRONG (tm). wait until x has REAL
> > transparency. until then i'm not putting in such horrid hacks - ESPECIALLY
> > not in edje. it just breaks the model entirely.
> >
>
> It's going to be another aeon before X gets support for alpha masks and
> alpha color values. In the mean time, half a loaf is better than none. My
> proposal is -- make it optionally available (rather than a core
i say work on making better cheese and ham and wait for the loaf to arrive :)
> functionality) so that whomever wants to use it can. It really wouldn't
> hurt that much, as long as it is not made a core feature such that the
> system would have to depend on it.
>
> Speaking of Edje, I liked Azundris' idea of the "transparency" keyword.
> The actual implementation of that should not be in Edje as Edje should
> never be tied diretly to the rendering backend (whether it be X11, FB or
> Qtopia). But Edje should be able to invoke the necessary functionality in
> Evas to effect that if necessary. For the mean time it will be an ugly
> hack, but in the future if and when X finally gets the ability, it can
> easily be changed.
definitely not. transparency is alreayd there - in the alpha hcannel of images
and rgba colours etc. it just makes no SENSE in edje. edje makes complex
resizable and reacting canvas objects. it is the job of putting a "fake"
background elsewhere in the canvas where these edje objects live - then when
they are transparent they will be transparent ontop of the faked bg. see above.
but again. i'm not getting my fingers dirty with this. its ugly. its
inefficient. it doesnt even obey the laws of "we will use more cpu but get
higher quality in return" (give and take). or vice-versa. you get extra overhead
with cpu, bus, ram AND a reduction in imaeg quality.... no aspect of this is
positive.
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 [EMAIL PROTECTED]
Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
