class Efl.Ui.Datepicker @beta ├ (P) min ├ (P) max ├ (P) date ├ (E) changed
- change the current properties to date_min, date_max (WooHyun)
- changed -> date,changed (WooHyun)
Description
Description
Details
Details
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T7510 evaluate stabilization potential of efl.ui classes and dependencies | ||
| Open | CHAN | T7869 efl.ui.datepicker | ||
| Open | None | T7566 efl.ui.i18n | ||
| Open | None | T7912 enum Efl.Input.Object_Pointer_Mode | ||
| Open | None | T7573 efl.ui.l10n | ||
| Open | None | T7574 efl.ui.selection | ||
| Open | None | T7913 function Efl.Ui.Selection_Data_Ready | ||
| Open | None | T7914 struct Efl.Ui.Selection_Changed | ||
| Open | None | T7915 enum Efl.Ui.Selection_Type | ||
| Open | None | T7916 enum Efl.Ui.Selection_Format | ||
| Open | None | T7578 efl.ui.view | ||
| Open | None | T7917 enum Efl.Ui.Activate | ||
| Resolved | None | T7919 enum Efl.Orient |
Comment Actions
@bu5hm4n @segfaultxavi @zmike @CHAN
How do you think about changing "min -> MinDate" and "max -> MaxDate" ??
(Date -> CurrentDate ? ... I don't think it's nice)
I hope we would take a look at this task together :)
Comment Actions
In the eo this would be date_min date_max date_current ? I think this is an improvement and avoids conflicts.
Comment Actions
On a second though, doesn't min_date, max_date and current_date sound better?
In the current API we have about the same number of properties called *_min and min_*, so that's a mess already.
However, we have 3 properties named current_* and none called *_current.
Comment Actions
Ok. then I will change all (*_min + *_max) to (min_*, max_*), if there would be no objection !
But, about current_*
I think just "time" and "date" look better than "current_time" and "current_date".
How do you think about this ?
Normally, in other platforms, SetDate or GetDate is used instead of SetCurrentDate or GetCurrentDate.
Comment Actions
I think we should use the scheme date_min date_max date_current as we do with other similar properties, e.g., in size hints we have restricted_min combined_max since these are "types" of min/max properties.
Comment Actions
@segfaultxavi
No matter :)
@zmike @segfaultxavi
Do we need to add "_current" ?
just "date (for datepicker)" and "time (for timepicker)" look enough. nope ?
In other platforms - there is no use of work "current" for time relating properties.
Plus, if we add "_current", then "size" also needs to be changed to "size_current" ?
Comment Actions
I think just using date and time here is fine...unless this is something which could become a conflict later with something else that has that property?
Comment Actions
Let's cross that bridge when we get there :)
If there's no conflict now I'm OK with date and time.
Comment Actions
I don't think there would be no conflict -
but we can change it "date,changed" for better understanding.
(Then, we may need to modify other "changed" events properly together)
Do you have any idea on this ?
Comment Actions
There is currently no conflict, but I agree we should play it safe and call it date, changed.
Same thing for timepicker, calendar and clock.
BTW, aren't we again trying to fix C#-specific problems (the name collisions) at the EO level?
Comment Actions
Yes, this is a good point...
I guess we could have the C# generator namespace the events automatically or something? cc @lauromoura
Comment Actions
The C# generator adds an Event suffix to event names, so they have less chance of colliding with class names, properties or methods.
But two events can still clash if a class inherits two classes emitting events with the same name. In C the namespace is always explicit, but not so in C#.