summaryrefslogtreecommitdiff
path: root/src/lib/elementary/elm_dayselector.c (follow)
AgeCommit message (Collapse)Author
2019-07-30elm/efl_ui: remove elm_layout_sizing_eval implementationsMike Blumenkrantz
Summary: historically there have been two methods of calculating sizes in elm: * elm_layout_sizing_eval * evas_object_smart_calculate (now efl_canvas_group_calculate) the former was used to set size hints on widgets, while the latter was used to perform internal size calcs for the widget. for things to work correctly, these functions had to be triggered in just the right order at just the right time. many hard-to-fix bugs related to widget sizing over the years have been the result of this split this patch removes elm_layout_sizing_eval implementations so that all widgets perform both internal size calcs and size hint setting all in the same function, ensuring that these are always in sync the result is that in the vast majority of cases, far fewer recalcs happen for widgets, and they are quicker to achieve their final size Depends on D9438 Reviewers: bu5hm4n Reviewed By: bu5hm4n Subscribers: bu5hm4n, cedric, #reviewers, #committers Tags: #efl_widgets Maniphest Tasks: T8059 Differential Revision: https://phab.enlightenment.org/D9439
2019-06-26efl_ui: remove nstate widgetMike Blumenkrantz
Summary: this doesn't seem to serve a purpose anymore and there's no point in keeping it in tree fix T7866 Reviewers: woohyun, Jaehyun_Cho Reviewed By: Jaehyun_Cho Subscribers: cedric, #reviewers, #committers Tags: #efl_widgets Maniphest Tasks: T7866 Differential Revision: https://phab.enlightenment.org/D9176
2019-06-20efl_ui_radio: cleanup APIMarcel Hollerbach
This is a bit of a giant commit. However, the problem here is that cleaning up the API went hand in hand with rewriting most of the usages. In the process of renewing and removing old API the following was done: - Legacy API testcases have been ported back to smart callbacks - EO-API testcases have been ported to efl_add syntax - weird event #defines have been removed - Wrong constructor usage has been removed - Ported to the new box object introduced before - removed legacy API from efl_ui_radio -> no more ptr(int) q66 will do jumps of happiness -> no more ununderstandable group_add methods -> Seperated code in blocks only for legacy, and blocks only for non-legacy To verify this commit, you can check all the tests that have been touched here. Additionally, the cxx example has been adjusted ref T7867 Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Differential Revision: https://phab.enlightenment.org/D9060
2019-04-18ui.widget: remove elm_widget_sub_object_parent_add from each of widgetsYeongjong Lee
since commit a1addad60e, To add myself as a sub object of parent object will be done in Efl.Ui.Widget constructor. Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de> Differential Revision: https://phab.enlightenment.org/D8280
2019-03-07elm_dayselector: remove all legacy usage from eo filesMike Blumenkrantz
this takes the current generated output from eolian for legacy code in efl and adds it to the tree, then removes legacy references from the corresponding eo files. in the case where the entire eo file was for a legacy object, that eo file has been removed from the tree ref T7724 Reviewed-by: Cedric BAIL <cedric.bail@free.fr> Differential Revision: https://phab.enlightenment.org/D8164
2019-03-04efl.ui: remove Efl.Ui.Theme_Apply_ErrorMike Blumenkrantz
Summary: now that the error codes have been change to be compatible with eina_error, this can be removed and will work through eina_error naturally fix T7718 Depends on D8067 Reviewers: cedric Reviewed By: cedric Subscribers: cedric, #reviewers, #committers Tags: #efl_api Maniphest Tasks: T7718 Differential Revision: https://phab.enlightenment.org/D8068
2019-03-04efl.ui: Efl.Ui.Theme_Apply_Result -> Efl.Ui.Theme_Apply_ErrorMike Blumenkrantz
Summary: this swaps the values of "no error" and "error" in order to maintain consistency with the rest of efl where the zero value means "no error" Depends on D8060 Reviewers: cedric Reviewed By: cedric Subscribers: segfaultxavi, cedric, #reviewers, #committers Tags: #efl_api Differential Revision: https://phab.enlightenment.org/D8063
2019-01-02elementary: rename Efl.Ui.Translatable -> Efl.Ui.L10nCedric BAIL
If we are to choose Efl.Ui.I18n for the internationalization support, the localization API should be named accordingly L10n. Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es> Differential Revision: https://phab.enlightenment.org/D7507
2018-11-20efl_ui_theme: Introduce Efl.Ui.Theme classJaehyun Cho
Summary: Efl.Ui.Theme class is required to support language bindings. Efl.Ui.Theme works based on current elm_theme features. This patch fixes T7357. Reviewers: segfaultxavi, cedric, lauromoura, woohyun, zmike, SanghyeonLee Reviewed By: segfaultxavi, SanghyeonLee Subscribers: SanghyeonLee, herdsman, #reviewers, #committers Tags: #efl Maniphest Tasks: T7357 Differential Revision: https://phab.enlightenment.org/D7244
2018-06-19elm_dayselector: fix improperly named API theme partsMike Blumenkrantz
Summary: API parts require namespacing, these parts have been namespaced with compatibility code added to handle legacy naming Depends on D6210 Reviewers: cedric Reviewed By: cedric Subscribers: #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D6211
2018-05-24elementary: due to lifecycle difference between legacy object and unified ↵Cedric BAIL
object, we need to track their lifecycle more explicitely. It is my understanding that some items view are created with efl_add directly and manipulate VIEW directly with Eo new API. This clash with the inconsistent behavior that evas_object_del expect. To work around this, we track object life by explictely relying on efl_wref_add while holding the pointer to the object.
2018-05-24elementary: dayselector use efl_add to create the object, calling efl_del ↵Cedric BAIL
during destructor make no sense. Differential Revision: https://phab.enlightenment.org/D6106
2018-05-24efl: major rewrite of efl_part.Cedric BAIL
The interface efl_part_get should not be directly called from C, but the efl_part wrapper should. It rely on efl_noref to properly destroy the object. Binding can control the lifecycle of the reference the way they want by either calling the wrapper or efl_part_get directly. It also means that the ugly ___efl_auto_unref_set doesn't need to be exposed outside of EFL anymore. Differential Revision: https://phab.enlightenment.org/D6098
2018-04-24Efl.Access.Object (from Efl.Access)Xavi Artigas
Ref https://phab.enlightenment.org/T6847 Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
2018-04-17eolian gen: enable constness generation on property getter implsDaniel Kolesa
This changes a lot of things all across the EFL. Previously, methods tagged @const had both their external prototype and internal impl generated with const on object, while property getters only had const on the external API. This is now changed and it all has const everywhere. Ref T6859.
2018-01-08widget: rename elm widget to Efl.Ui.Widget.Amitesh Singh
2017-11-07elm: Create legacy widgets with elm_legacy_addJean-Philippe Andre
This will be used to solve issues around style_set: if the widget is legacy or pure eo we may need to select a different style. So in the constructor we need to know whether we are legacy or eo. Note that calling style_set in finalize only is too late as we would lose information such as efl_text_set() called inside efl_add().
2017-10-24widget: Rename EO APIs to efl_ui_widget_xxxJean-Philippe Andre
This only changes the eo_prefix for APIs. Ref T5363
2017-10-19elm: rename Elm_Interface_Atspi_Accessible interfaceLukasz Stanislawski
Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D5341
2017-10-10elm_dayselector: remove old api!Marcel Hollerbach
2017-09-26widget: Implement translation API in layoutJean-Philippe Andre
This moves the API entry points from Widget to Layout parts. I don't think the other widgets support translation, but that is easy to fix. The actual code implementation remains in elm_widget.c. Legacy-only widgets are covered by Part_Legacy, while all EO widgets that have text inherit from Layout (except Win but I don't think the window title was translatable in legacy). This removes 2/3 remaining part APIs from Widget. Ref T5363
2017-09-26elm: Introduce interface Efl.Ui.TranslatableJean-Philippe Andre
This will be used to replace the part translation API in Elm.Widget. It should work for both parts and non-parts (ie. the main text of a button, for instance). For now I'm taking the following approach: - All efl_text_set/get strings are untranslatable, i.e. get() returns the visible string, set replaces and can not be translated. - translatable_text_set/get needs to be used to enable automatic translation, which in turns calls efl_text_set to modify the visible string. Thus, translatable applications will have to use efl_ui_translatable_text_set a lot more than efl_text_set, unless they translate strings application-side. Note that some other frameworks take a simpler approach equivalent to calling efl_text_set() with an already translated text. This prevents runtime language changes of the application, unless the application handles them specifically.
2017-09-21elm: Move base implementation for efl_part in widgetJean-Philippe Andre
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.
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
2017-08-30widget: Simplify & document "translate"Jean-Philippe Andre
This is a protected function. It doesn't need to return anything, as all implementation just returned true, always. Also, the legacy API was just a wrapper doing nothing special (except verify that we have a widget, which the recursive code already does). Tested with fr_FR :) Ref T5363
2017-08-09elm: Cleanup theme and style set functionsJean-Philippe Andre
This makes efl_ui_layout_theme_set() return a Theme_Apply error code. The type is now public as Efl.Ui.Theme.Apply. Ref T5329 Ref T5363
2017-08-08elm: Rename elm_layout to Efl.Ui.LayoutJean-Philippe Andre
Some names have not been changed, hopefully making a distinction between legacy APIs and internal code (elm_layout_blah) and valid EO usages. This means many internal functions are still elm_layout_ as their sole purpose is to support the legacy API. Ref T5315
2017-08-08elm: Move elm_layout_sizing_eval to legacyJean-Philippe Andre
elm_layout_sizing_eval() marks an object as requiring recalc. Unfortunately, it's been massively abused by various widgets into actually doing the calc, or the min calc. So we end up with one API that has 3 different definitions depending on the widget type: 1. Mark as requiring recalc (correct, respects doc, elm_layout) 2. Calculate min size and other size hints 3. Actually do some geometry modification I believe we need to clarify these 3 requirements into 3 very clear and specific APIs in elementary. Right now we have similar functions in evas for 1 (evas_object_smart_changed) and 3 (smart_calculate). But their exact definition also isn't necessarily what we want for elementary. Another clear problem is that layout_eval does not do any calculation (in theory), so the "eval" word is a bit of a stretch here. Once we're sure about the exact API we want, we can add this back to EO and make it work across our EO widgets. For now let's just keep the legacy API, and its EO overrides, as is. Ref T5315
2017-07-29elm dayselector - remove double set of content varCarsten Haitzler (Rasterman)
this looks like a leftover from legacy to eo porting. it was harmless but analysis hates it found by PVS studio
2017-07-07evas,edje,elm: Mark all legacy objects as suchJean-Philippe Andre
2017-06-14widget: Implement mirrored from Efl.Ui.BaseJean-Philippe Andre
Ref T5363
2017-05-19evas/elm: Make group_add/group_del internal functionsJean-Philippe Andre
This hides those two legacy functions from the EO API.
2017-02-21dayselector: Fix DaySelector widgetJean-Philippe Andre
An invalid strcmp() led to always reject the swallowed widgets, which were Elm.Check instead of Elm_Check. Use efl_isa() instead. Fixes T5034
2016-08-30Efl object: Rename Eo_Event -> Efl_Event.Tom Hacohen
This is the last step of the Eo renaming efforts.
2016-08-26Efl Object: remove legacy callback calls from event_callback_callVitor Sousa
Efl.Object.event_callback_call no longer calls legacy smart callbacks; calling only event callbacks registered with the given event description pointer. Create the method Efl.Object.event_callback_legacy_call to inherit the old behavior from Efl.Object.event_callback_call, calling both Efl.Object events and legacy smart callbacks. Update all other files accordingly in order to still supply legacy callbacks while they are necessary.
2016-08-15Eo: Finish the renaming of Eo to the EFL.Tom Hacohen
This renames all the rest of the API to the EFL namespace except for Eo_Event that will follow soon. Obviously breaks both API and ABI.
2016-08-11Change the EFL to follow the new Eo rename.Tom Hacohen
2016-07-01theme: return enum from elm_widget_style_set instead of boolJinyong Park
Summary: if trying to apply incorrect theme, widget apply default theme and return TRUE. so there is no way to check it really apply correct theme. To resolve this problem, _elm_theme_set return three type enum * related history : 4ca3ef45146e05908a13d1010909abeba9693ad6 * elm_object_style_set is public api, so I didn't change it. * typedef name [ Theme_Apply ] is temporarily, please suggest better one. @fix Reviewers: singh.amitesh, herb, Hermet, cedric, jpeg, raster Subscribers: cedric, jpeg Differential Revision: https://phab.enlightenment.org/D4073
2016-06-21evas: Rename Evas.Object to Efl.Canvas.ObjectJean-Philippe Andre
One step closer to make the EO inheritance tree look like it's all Efl.
2016-06-20Adjust the code according to the eo event stop changes.Tom Hacohen
This was changed in the previous commit.
2016-06-17Evas: Rename smart object into Efl.Canvas.GroupJean-Philippe Andre
2016-06-17Evas: Add smart_ prefix to all smart functions (eo)Jean-Philippe Andre
This is a first step at separating legacy smart object features away from standard efl interfaces.
2016-06-17Evas: Move smart_callbacks_descriptions to legacyJean-Philippe Andre
2016-06-03elm: Partially revert "elementary: avoid random memory access."Jean-Philippe Andre
This reverts commit ac5a0b7e79d6b32285bd7b794f050826f38cc7c2. I added assert(pd == sd) in the modified code and couldn't find anything suspicious. The proper class is used in eo_data_scope_get(). I also can't find a crash or a bug currently in hover. I know there was a problem earlier, but that was fixed in 3092e08a83f754ba8d49c. Now, if there is still a problem, we should check it carefully. Pinging @cedric
2016-06-02elementary: avoid random memory access.Cedric BAIL
It seems that this content_get function are not getting the data pointer they expect at all.
2016-06-01Revert "Eo: Remove eo_del() and make eo_unref() the replacement."Tom Hacohen
This reverts commit 546ff7bbba788ec834c5608361c0834853f2d5d7. It seems that eo_del() is useful and removing it was creating bugs. The issue is that the way we defined parents in eo, both the parent and the programmer share a reference to the object. When we eo_unref() that reference as the programmer, eo has no way to know it's this specific reference we are freeing, and not a general one, so in some circumstances, for example: eo_ref(child); eo_unref(child); // trying to delete here eo_unref(container); // container is deleted here eo_unref(child); // child already has 0 refs before this point. We would have an issue with references and objects being freed too soon and in general, issue with the references. Having eo_del() solves that, because this one explicitly unparents if there is a parent, meaning the reference ownership is explicitly taken by the programmer. eo_del() is essentially a convenience function around "check if has parent, and if so unparent, otherwise, unref". Which should be used when you want to delete an object although it has a parent, and is equivalent to eo_unref() when it doesn't have one.
2016-05-26Efl: Remove part name in Efl.Container (use Efl.Part)Jean-Philippe Andre
This touches Edje and also Elementary where part names are used. This commit blew up in size since now all content part APIs (get, set, unset) require to use Efl.Part instead. This is a big refactoring commit, but no logic should have been changed. Fingers crossed.
2016-05-17eolian: add event_prefix and have classes follow that or eo_prefix by defaultDaniel Kolesa
Previously events used to use class name as a prefix and ignored eo_prefix when specified. This is no longer the case. Events follow eo_prefix by default now. In order to get around this for classes where this is undesirable, a new field event_prefix was added which takes priority over eo_prefix. If neither is specified, class name is used like previously. @feature
2016-05-17Eo: Remove eo_del() and make eo_unref() the replacement.Tom Hacohen
We used to have eo_del() as the mirrored action to eo_add(). No longer, now you just always eo_unref() to delete an object. This change makes it so the reference of the parent is shared with the reference the programmer has. So eo_parent_set(obj, NULL) can free an object, and so does eo_unref() (even if there is a parent). This means Eo no longer complains if you have a parent during deletion.
2016-04-26Efl: Introduce Efl.Container and unify APIsJean-Philippe Andre
This removes Efl.Pack_Named which had a terrible name, removes Elm.Container which should have been renamed Efl.Ui.Container anyway, and introduces an interface Efl.Container instead. The hierarchy tree is now changed as objects don't inherit from Efl.Container (it's an interface, not a regular class) but only implement it. Obviously it is very easy to reintroduce an Efl.Ui.Container parent class if we need it, but I guess it should have some actual logic. It's basically part of what Elm.Widget already does. Some function names have been modified to look better in C with the efl_content prefix. @feature