> but for instance the code you did there can be avoided
> by use of parts of "type: GROUP" using "source: "button_bar""

aha! That wasn't on the edjebook :). It was strange that something so
obvious should be missing!

> +   ed = embryo_program_data_get(ep);
> +
> +   rp = ed->table_parts[part_id % ed->table_parts_size];
> +   if (!rp || rp->part->type != EDJE_PART_TYPE_SWALLOW) return 0;
>
> no, see below.
>
> +        evas_object_smart_member_del(new_obj);
> +        return 0;
> +     }
> +
> +   _edje_real_part_swallow(rp, new_obj);
>
> This is not ok. The first statement should be a simple
> evas_object_del(new_obj),

Ok, I took the first line from unswallow but it was possibly not what I
needed.

> the second should be
> evas_object_part_swallow(), this also remove the need of
> embryo_program_data_get() and working with table_parts and like...
> They're not really wrong, as it will work, but it's not good as it's
> too intrusive, let's use the public api and have just one place to
> work on the internals.

I went that way at first, but I liked the compile time validation that
PART:"foo" did by checking if "foo" was a part... and since it does the
validation while looking up the part I ended with a part index... getting
the name and then using the public API didn't sound very good either :S.



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to