path: root/src/lib/elementary/efl_ui_progressbar_part.eo (follow)
Commit message (Collapse)AuthorAgeFilesLines
* elementary: remove Efl.Ui.Layout namespaceJaehyun Cho2018-11-161-1/+1
| | | | | | | | | | | | | | | | | | Summary: Efl.Ui.Layout namespace is removed to keep consistency with other widgets. Consequently, "Efl.Ui.Layout.Object" is renamed to "Efl.Ui.Layout" and "Efl.Ui.Layout." is renamed to "Efl.Ui.Layout_". Reviewers: segfaultxavi, bu5hm4n, cedric Reviewed By: segfaultxavi Subscribers: #reviewers, #committers, SanghyeonLee, woohyun Tags: #efl Differential Revision: https://phab.enlightenment.org/D7291
* Efl.Ui.Progressbar_Part (from Efl.Ui.Progressbar.Part)Xavi Artigas2018-04-241-1/+1
| | | | | | Ref https://phab.enlightenment.org/T6847 Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
* Efl.Ui.Progressbar: implement range min maxAmitesh Singh2018-01-311-0/+1
* elm: Remove range "span_size" API in EOJean-Philippe Andre2017-09-211-2/+1
| | | | | | | | | | | | | | | | | Reasons: - This API has been confused with the min size of the widget, resulting in badly laid out applications. - The EO API was not very nice (Range is about numbers, the Gfx size hint in a part is really ugly). While I understand the value of this API and how it can be used in scalable applications, it is in fact not absolutely necessary. Alternatively to that span size, the widget min size can already be defined from the application side, or the widget can simply be expanded to fill in its parent. This can obviously be reinstated later if the need arises for EO. For now, keep this feature as legacy-only.
* elm: Split off text and content for efl_partJean-Philippe Andre2017-09-211-1/+1
| | | | | | | | | | | | | | | | | 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.
* elm: Move base implementation for efl_part in widgetJean-Philippe Andre2017-09-211-1/+1
| | | | | | | | | This means that ALL part handles inherit from the base part class Efl.Ui.Widget.Part. Layout is the only exception where Efl.Part is specially overridden. This is a first step towards generic part APIs, including background in all widgets.
* edje/elm: Rename _internal_ to _part_ (EO)Jean-Philippe Andre2017-09-131-0/+9
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