Page MenuHomePhabricator

efl.part
Closed, ResolvedPublic

Description

| |interface Efl.Part
| |├ (M) part_get :: @protected

Related Objects

StatusAssignedTask
Resolvedzmike
Resolvedzmike
zmike created this task.Jan 8 2019, 11:39 AM
zmike triaged this task as TODO priority.
zmike updated the task description. (Show Details)Jan 9 2019, 6:05 AM
segfaultxavi moved this task from Backlog to Evaluating on the efl: api board.Feb 6 2019, 3:47 AM
zmike moved this task from Evaluating to "easy" on the efl: api board.Feb 6 2019, 5:36 AM
zmike added a comment.Feb 7 2019, 9:48 AM

One thing I strongly dislike about the function of this api is that it can't return NULL. It instead returns an 'invalid' part, but there's not really any way (that I know of) to detect it other than hooking a callback onto the layout object...which is absolutely abysmal from a developer perspective.

And then all attempts to set properties on the returned part just print error messages on the console and everything keeps going.

Why is part_get protected?

zmike added a comment.Feb 8 2019, 11:11 AM

Oh I guess there's a type_get for parts, but since everything just passes efl_part(obj, "somepart") directly this is not super helpful?

cedric added a comment.Feb 8 2019, 1:40 PM

efl_part is calling part_get and setup the self destruct logic (so that it unref completely the part after the first use of it). part_get is to be used only by bindings directly that needs to handle the life cycle of the part to fit their own needs. This is why it is protected. You can see the code of efl_part in efl_interface_main.c

I guess my complaint is more with the existing usage of efl_part() in the tree and not with the interface. The interface is probably fine.

zmike moved this task from "easy" to Stabilized on the efl: api board.Feb 15 2019, 11:59 AM
bu5hm4n raised the priority of this task from TODO to Normal.Feb 22 2019, 1:19 AM
zmike closed this task as Resolved.Mon, Mar 11, 10:47 AM
zmike claimed this task.