[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Resizing Edje Parts - on the road to entrance preview

brian.mattern@gmail.com wrote:
On Mon, Aug 21, 2006 at 05:33:26PM +0100, Essien Ita Essien wrote:
Carsten Haitzler (The Rasterman) wrote:
On Mon, 21 Aug 2006 16:11:52 +0200 Simon TRENY <simon.treny@free.fr> babbled:

On Mon, 21 Aug 2006 14:36:05 +0100,
Essien Ita Essien <essien@wazobialinux.com> wrote :

Carsten Haitzler (The Rasterman) wrote:
On Mon, 21 Aug 2006 13:55:45 +0100 Essien Ita Essien
<essien@wazobialinux.com> babbled:

no attachment :)

but - note the livethumb uses a BUFFER canvas - it sets the
resolution of the BUFFER canvas to be higher than the output. make
this resolution high enough (eg 800x600) and evas will scale that
800x600 "buffer" canvas down to the size of the output of the
preview. that is how the livethumb works.
uhh... i'm going to have to bug you once more. *brainbox* <-----
buffer_overflow ;)

I've been staring at e_livethumb.c and e_widget_preview ,
e_int_config_theme.c, where it is used and trying to develop an
understanding of the relationships so far, i'm missing a tiny link.

As I understand (from a day+ of Esmart/Evas/Ecore_Evas induction), when
I'm creating an evas esmart object, I create all my individual evas
objects, poke them into the esmart data and write call backs that
manipulate. In my initializer, I take an evas, add the esmart object to
it and this action results in an Evas_Object that is linked to my evas
and is an instance of my esmart. Once I manipulate this new evas object,
i'm well and happy.

*please correct me if i'm wrong at any step*

Now, for using the buffer canvas, I don't seem to see how to relate the
ecore_evas_object_image_new() that i create to the rest of the esmart
objects. Normally, in the examples I've seen and the minientrance code I
sent, I had a *clip* member that was an evas_rectangle (honestly, I'm
not sure what that clip is used for :) ), but when I created by
background object and main object, i set their clip to the internal clip
object, and in the clip_set callback, i set the passed in clip to the
internal clip. This is how I seem to see that all the objects in my evas
get linked together.

A clip makes objects only show up within the bounds of the clip object.
E.g clipping A to B below will result in C:

+--------------+ | | +---+---+ | +---+ | A | B | | C | +---+---+ | +---+ | | +--------------+

ahh... i c. i suspected, but didn't want to assume anything :)
Looking at e_livethumb, I see that the ecore_evas_object_image is
created and a smart member is set on it (that's where I first start
getting confused.)

"Smart members" are the sub objects of a smart objects. You tell evas
that each of your 100 little pieces that make up the smartobj are
members, and it does some stuff for you (keeps them layered together,
So this means that instead of manually building the evas_smart by going the normal route, i can dynamically assemble a quick and dirty evas_smart object using the smart_member_add() then?

Next, in e_livethumb_thum_set(), I was expecting that i'd see the thumb
member being somehow linked to the buffer canvas (evas_obj), but its not
happening. Instead the thumb is being sized on its own.

So my question really is how do these hook up together, when using the
buffer canvas. I'm sure i'm missign something small, but i just can't
seem to see it. :)

The buffer canvas is a fullblown evas of its own. Its contents are being
displayed in an image on your primary evas. What you'll want to do is
add you smart object to the BUFFER evas. The buffer canvas will have a
fixed size that you set. The rendered version of that gets scaled to the
size of the image object.
with all the help i've gotten on this so far, I now have a perfect understanding of things. My missing link was how to obtain the evas from the buffer canvas. CodeWarrior's examples cleared this up more than nicely :)