summaryrefslogtreecommitdiff
path: root/src/lib/elementary/elm_naviframe_part.eo (follow)
AgeCommit message (Collapse)Author
2017-11-20efl: Split Efl.Container and Efl.ContentJean-Philippe Andre
When I first implemented the Efl.Container interface I made a mistake of mixing "single slot" content API's with "multiple children" content API's. This should fix that, by separating API's that are for a single part and those that deal with a list of children. Efl.Content: Single slot. This will be used a lot by efl_part() objects, and for the default content of widgets (eg. the window content). Efl.Container: Multiple children. Used by lists, boxes, layouts (edje/elm), etc... I didn't see any class that implemented both interfaces (note: Layout implements Container and Button implements Content, so technically Button implements both through inheritance). For now the eo_prefix is not changed in Efl.Container. I wonder if it should be reset (to efl_container) or not. This would only affect the C API. Ref T5328
2017-09-21elm: Split off text and content for efl_partJean-Philippe Andre
This is VERY tricky. For legacy, just create an internal class that has both. It's easier this way. For parts that are handled by Layout directly, we know from Edje which type to return. For EO objects we should know from the part name which kind of part we are dealing with: - text (overridden by the widget) - content (overridden by the widget) - special (new efl_part based functions) - generic (handled by Layout) Note: Efl.Ui.Slider was handling "span size" on ALL parts. That's bad... This is now limited to "span" only.
2017-09-13edje/elm: Rename _internal_ to _part_ (EO)Jean-Philippe Andre
In Edje and Elementary, we have part objects, which are what is returned by the interface efl_part(). Those objects can't be of an opaque type as this doesn't work nicely with strongly typed languages such as C++ or C#. In JS, Lua, C the types are weak and mostly runtime-based so it doesn't matter much. As a consequence, the documentation and the types need to look nice in this EO API. Thus, we remove the abusive term "internal" and explicitly call all those classes "part" something. Eventually we want the types to be declared in the EO file so bindings (C#, C++, ...) can generate the proper access methods, returning the best possible types. Note that right now a few of those part types are used in the legacy API but don't actually need to be exposed externally. This is kind of a mega commit that does all the renaming at once, but it's really just a big sed operation. The power of good IDEs :) Ref T5315 Ref T5306