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

Re: [E-devel] ewl layer handling

Nathan Ingersoll schrieb:

On 4/15/06, Peter Wehrfritz <peter.wehrfritz@web.de> wrote:
Hi all,

While I'm playing around with ewl_embed to replace my old context menu
in elitaire, I recognize that this is nearly impossible, because ewl
spreads its objects over the whole layer range, starting with -1000 upto
1000 (I'm not sure if the number are really correct). And swallow it in
a edje is indeed impossible.

Actually, it can start at any layer, as long as it's set on the smart
object for the embed. The default is -1000.

So the the current layer system may work well for stand alone ewl apps,
but it is useless when you want overlap an ewl_embed and some
evas_objects. I think it would make sense to switch to the "new"
(perhaps six month old) evas_smart_object layer system, so that every
ewl widget is a smart member of the ewl_embed smart object and all ewl's
magic happens in only one layer.

This is certainly a possibility. It might solve some problems we've
also seen with using shaped windows and ewl_embed. The object cache
introduces a few key points that we could use to hook into adding to
the smart object. I have avoided this in the past because of the way
clipping was done in Evas, and the additional memory allocations used
to add an object to a smart object. With the new layering and
clipping, this should be negligible now.

I know this is not an easy step or an one-day-job, I've already done
this in elitaire. On the other hand the most code I've seen in ewl
concerning to layering was put this object over another or put this
object to the top and that is easily done with stack_above() and raise().

You're mostly correct in how layering is used, but there is a
circumstance where this is not so trivial. The most basic example is a
tooltip, if a window contains a tooltip above some widgets, then a
widget is added that should be stacked above the existing widgets, we
need to maintain the layering of the tooltip above other widgets. The
same situation applies to imenu's. Right now we use a large layer
offset for these types of widgets to make it extremely unlikely that
any new widget will get stacked above them.

I don't think this issue is a show-stopper to your proposed change,
but it does need to be considered and addressed.
I see what you mean.

I see two ways to do this:
1. Trying to stay as nearly as possible to the current system. E.g. just
replacing the evas_object_layer_set(o, 1000) with evas_object_raise(o).
This should be possible but might become tricky in the detail.

IIRC, this is not a hard coded layer setting, except that the default
layer is -1000 or so. It should presently use whatever layer that is
set on the smart object as the starting layer and spread the range of
widgets upward from that point.
Sorry, yes it is relative to the embed. Using the ewl function ewl_widget_layer_set()

2. Every widget get a dummy smart object, with no callbacks. So this
smart object holds in a "normal" widget the clip and the edje theme and
in the case of a container also the smart object of the children. This
approach would be cleaner and easier, but I don't know if  it cause
extra  overhead.

Unfortunately, this could be a lot of overhead. You can potentially
have thousands (millions?) or widgets, so performing extra allocations
like this really adds up. Right now we scale pretty well, and a lot of
the scalability improvements came from the fact that we limit the
number of evas objects to what is presently on screen at any given
time. So the only way I see this being feasible is if we can create
the smart objects at the time of a reveal callback (like we do for the
clip and theme object). That may work, but not if we rely on object
persistence to get layering right.

So I will start with option number 1 and hope it works that way.

Would do you think about it ? Have I  missed anythink or should I try a
start (without guaranty of success)?

If we can figure out how the issues I mentioned earlier can be
addressed, I would be quite happy to accept a patch for this.

It might be worthwhile to test if adding all of the evas objects to
the embed's smart object solves the issue completely. If the layering
within a smart object is relative to that smart object only and not
the global layering, then there may not be any additional work
required. I can't claim strong knowledge of how the layering works
now, but maybe raster can shed some insight.
When I understand you right this won't work, because a smart object afaik has only one layer stack. So function calls like evas_object_layer_set() are just ignored by evas when the object is a smart member.


Thanks for your fast response