On Fri, 17 Feb 2012 08:21:30 +0000 (GMT) Sumanth Krishna Mannam
<sumant...@samsung.com> said:

first i was strolling along, reading elm_datetime.c... and then i saw:

static int _days_in_month[12] = { 31, 28, 31, 30, 31, 30,
                                  31, 31, 30, 31, 30, 31 };

and then i was like:
  http://www.youtube.com/watch?v=6FWUjJF1ai0

and i saw...
             if (__isleap(*timearr[ELM_DATETIME_YEAR]) &&

and i was like:
  http://www.youtube.com/watch?v=fM1O9jWeNoI


(look at clock module src of e17 (in svn trunk/e/src/modules/clock) - in there
it manages to draw months and handle month sizes by using syscalls that  should
get this from a time database and thus be correct. you can figure out the range
by using syscalls to do it all look @ _time_eval()).

limits for years.. why 1970->2037? that seems a bit silly to limit it - what if
i'm entering the date of birth of my father? it's definitely before 1970  :)

and then i was looking at api:

Elm_Datetime_FieldType -> Elm_Datetime_Field_Type

otherwise i shall not quibble about api :)



> Hi All,
> 
> Attached to the mail is the patch for new elementary widget elm_datetime.
> Refer to the below EFL post history for more details. 
> 
> The datetime widget provides an option to display Date & time based on
> current locale format and the user can edit them through dynamic Modules.
> Dynamic modules can be based on 1. Content Popup/diskselector based list   2.
> Elm_entry with ISE based input   3. Elm_Spinner based  etc. Refer to the
> Screenshots:  <1.ctxpopup_diskselector_UI>   <2.entry_ise_UI>
> <3.spinner_selection_UI>
> 
> Can someone review and push this patch to EFL repository?
> 
> Change description:
> New widget Elm_datetime is added.
> Datetime widget displays the Date &Time fields and provides a customizable
> way to edit them. The widget is implemented in a modular fashion for
> date/time field inputs. Ctxpopup based input is proposed as the default
> selection module. Localization support based on Libc is also supported.
> 
> Sign-Off By:  Sumanth M.V.K  <sumant...@samsug.com>
> 
> 
> Thank you,
> 
> Regards,
> Sumanth M.V.K
> 
> ------------------------------------------------------------------------------
> 
> Re: [E-devel] Lib ICU Integration
> Tom Hacohen
> Fri, 23 Sep 2011 01:12:16 -0700
> 
> On 23/09/11 11:05, Govindaraju SM wrote:
> > ==> You have to wait a little while to make widget patch with proper 
> > documentation, examples :)
> 
> Hehe, sure, Rome was not built in a day. :)
> 
> --
> Tom.
> 
> ------------------------------------------------------------------------------
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> -----Original Message----- 
> From: Tom Hacohen
> Sent: Thursday, September 22, 2011 7:41 PM
> To: Govindaraju SM
> Cc: Enlightenment developer list
> Subject: Re: [E-devel] Lib ICU Integration
> 
> On 22/09/11 13:01, Govindaraju SM wrote:
> > ==> Thanks for your suggestion. I can very much do with libc with out
> > ICU for date formatting, including getting locale strings.
> > ICU integration is dropped.. :)
> 
> I'm glad we agree. :)
> > okay, Why this should widget? I have to display a Date and/or Time in
> > the single line ( as usual date/time display )
> > and able to edit it without launching a calendar or other time edit
> > widget. This new widget does it,
> > Displays date and allows to edit individual fields.
> 
> I don't get an exact visual, I guess I'll have to wait until you finish.
> 
> > ==> If it is just date/time display, then your point is very much
> > agreeable.
> > But this new widget provides option to edit individual fields also
> > without launching Calendar.
> > ( mainly for optimal usage of screen space and change date without too
> > many clicks )
> 
> I don't quite understand, so I guess I'll have to wait until you finish
> to give a proper response. In the meanwhile, from what I understand, it
> sounds cool.
> --
> Tom.
> 
> ==> You have to wait a little while to make widget patch with proper 
> documentation, examples :)
> 
> Regards,
> Govind
> 
> ____________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> Re: [E-devel] Lib ICU Integration
> Tom Hacohen
> Thu, 22 Sep 2011 03:41:18 -0700
> 
> On 22/09/11 13:01, Govindaraju SM wrote:
> > ==> Thanks for your suggestion. I can very much do with libc with out
> > ICU for date formatting, including getting locale strings.
> > ICU integration is dropped.. :)
> 
> I'm glad we agree. :)
> > okay, Why this should widget? I have to display a Date and/or Time in
> > the single line ( as usual date/time display )
> > and able to edit it without launching a calendar or other time edit
> > widget. This new widget does it,
> > Displays date and allows to edit individual fields.
> 
> I don't get an exact visual, I guess I'll have to wait until you finish.
> 
> > ==> If it is just date/time display, then your point is very much
> > agreeable.
> > But this new widget provides option to edit individual fields also
> > without launching Calendar.
> > ( mainly for optimal usage of screen space and change date without too
> > many clicks )
> 
> I don't quite understand, so I guess I'll have to wait until you finish 
> to give a proper response. In the meanwhile, from what I understand, it 
> sounds cool.
> --
> Tom.
> 
> ------------------------------------------------------------------------------
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> Re: [E-devel] Lib ICU Integration
> Govindaraju SM
> Thu, 22 Sep 2011 03:04:33 -0700
> 
> -----Original Message----- 
> From: Tom Hacohen
> Sent: Sunday, September 18, 2011 2:26 PM
> To: Govindaraju SM
> Cc: Enlightenment developer list
> Subject: Re: [E-devel] Lib ICU Integration
> 
> On 16/09/11 04:44, Govindaraju SM wrote:
> > ==> Requirement is providing Date & time input widget which should
> > change the format automatically based on current system locale,
> > also display the date field strings in the locale specific language. so,
> > at this moment ICU lib utilization is only for date & time formatting,
> > locale and resource bundle.
> > based on our experiment, performance overhead added by ICU is
> > negligible. Binary size and its RAM usage, your point is right, due to
> > extensive features supported
> > by ICU. But I see some more features can be utilized, like locale
> > specific number format, currency, regular expressions, any locale Word
> > boundary calculation etc...
> 
> strftime with "%c" gives you the time based on locale including
> translation, ordering and everything. But even if it wasn't the case, it
> should be done in the user app and not in the widget toolkit.
> 
> ==> Thanks for your suggestion.  I can very much do with libc with out ICU 
> for date formatting, including getting locale strings.
>       ICU integration is dropped.. :)
>       okay, Why this should widget?    I have to display a Date and/or Time 
> in the single line ( as usual date/time display )
>       and able to edit it without launching a calendar  or other time edit 
> widget.  This new widget does it,
>       Displays date and allows to edit individual fields.
> 
> > ==> Get the locale specific formats, formatted date with locale specific
> > strings, context specific field limits ( ex, whats the max date value
> > for the specified month/year )
> > plus, the resource bundle should be replicated into gettext. Number
> > formatting, regex are some of the features can be utilized later.
> 
> All this logic should be done in the app and presented in widgets as
> wanted, to reason to put that logic in elm.
> 
> > ==> Idea is to make a simple date & time input widget. ( calendar widget
> > occupies more screen space, need simple widget ). Thank you for your 
> > input.
> > Do you think integrating ICU is okay if, we utilize all the above
> > mentioned features?
> 
> I still disagree because the reasons mentioned above. This shouldn't be
> a widget, and even if it was a widget, I doubt it really needs ICU to
> operate (but that's not the important part, the important part is that
> it shouldn't be a widget in my opinion).
> 
> ==> If it is just date/time display, then your point is very much agreeable.
> But this new widget provides option to edit individual fields also  without 
> launching Calendar.
> ( mainly for optimal usage of screen space and change date without too many 
> clicks )
> --
> Tom.
> ------------------------------------------------------------------------------
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> Re: [E-devel] Lib ICU Integration
> Tom Hacohen
> Sat, 17 Sep 2011 22:26:56 -0700
> 
> On 16/09/11 04:44, Govindaraju SM wrote:
> > ==> Requirement is providing Date & time input widget which should
> > change the format automatically based on current system locale,
> > also display the date field strings in the locale specific language. so,
> > at this moment ICU lib utilization is only for date & time formatting,
> > locale and resource bundle.
> > based on our experiment, performance overhead added by ICU is
> > negligible. Binary size and its RAM usage, your point is right, due to
> > extensive features supported
> > by ICU. But I see some more features can be utilized, like locale
> > specific number format, currency, regular expressions, any locale Word
> > boundary calculation etc...
> 
> strftime with "%c" gives you the time based on locale including 
> translation, ordering and everything. But even if it wasn't the case, it 
> should be done in the user app and not in the widget toolkit.
> 
> > ==> Get the locale specific formats, formatted date with locale specific
> > strings, context specific field limits ( ex, whats the max date value
> > for the specified month/year )
> > plus, the resource bundle should be replicated into gettext. Number
> > formatting, regex are some of the features can be utilized later.
> 
> All this logic should be done in the app and presented in widgets as 
> wanted, to reason to put that logic in elm.
> 
> > ==> Idea is to make a simple date & time input widget. ( calendar widget
> > occupies more screen space, need simple widget ). Thank you for your input.
> > Do you think integrating ICU is okay if, we utilize all the above
> > mentioned features?
> 
> I still disagree because the reasons mentioned above. This shouldn't be 
> a widget, and even if it was a widget, I doubt it really needs ICU to 
> operate (but that's not the important part, the important part is that 
> it shouldn't be a widget in my opinion).
> --
> Tom.
> 
> ------------------------------------------------------------------------------
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> Re: [E-devel] Lib ICU Integration
> Govindaraju SM
> Thu, 15 Sep 2011 18:46:40 -0700
> 
> Dear Tom,
> 
> -----Original Message----- 
> From: Tom Hacohen
> Sent: Wednesday, September 14, 2011 2:15 PM
> To: Enlightenment developer list
> Cc: Govindaraju SM ; Sumanth
> Subject: Re: [E-devel] Lib ICU Integration
> 
> On 14/09/11 05:39, Govindaraju SM wrote:
> > Hello All,
> >
> > We are considering lib ICU integration ( 
> > http://icu-project.org/apiref/icu4c/ ) with EFL to enhance the 
> > localization support.
> >
> > Initially, Date&  time input / display  with ucal, udat, uloc features.
> > ICU  provides API to get default system Locale ( or user specified ) 
> > specific date and time layout formats ( “ddMMyyyy hh:mm a”,  “MMddyyyy 
> > HH:mm” , “yyyyMMdd hh:mm a”  etc ),  locale specific formatted strings, 
> > context based field limit ( Feb –28,  Leap yr Feb –29 etc ).
> >
> > Pls provide your thought on this.
> >
> 
> I'm not sure it's wanted. From what I hear/have seen, ICU is fat and
> bloated; That's why I chose using the libraries I chose when
> implementing the unicode-related text features, e.g, fribidi, harfbuzz,
> liblinebreak, which are considered lighter, faster and better designed.
> 
> ==> Requirement is providing Date & time input widget which should change 
> the format automatically based on current system locale,
> also display the date field strings in the locale specific language. so, at 
> this moment ICU lib utilization is only for date & time formatting, locale 
> and resource bundle.
> based on our experiment, performance overhead added by ICU is negligible. 
> Binary size and its RAM usage, your point is right, due to extensive 
> features supported
> by ICU.   But I see some more features can be utilized, like locale specific 
> number format, currency, regular expressions, any locale Word boundary 
> calculation etc...
> 
> The real question is what do you feel you can't do with just
> locale/strftime. I'd like to see more information on what you are trying
> to achieve instead of how (ICU integration).
> 
> ==>  Get the locale specific formats, formatted  date with locale specific 
> strings,  context specific field limits ( ex, whats the max date value for 
> the specified month/year )
> plus, the resource bundle should be replicated into gettext. Number 
> formatting, regex are some of the features can be utilized later.
> 
> Furthermore, what does this "integration" include? What do you plan on
> doing?
> 
> ==> Idea is to make a simple date & time input widget.  ( calendar widget 
> occupies more screen space, need simple widget ).  Thank you for your input.
> Do you think integrating ICU is okay if, we utilize all the above mentioned 
> features?
> 
> In my opinion this is not needed at best, and should probably be
> avoided. With that being said, my opinions are based on the little
> information you provided. Please provide more information.
> 
> Thanks,
> Tom.
> -----------
> Regards,
> Govind 
> 
> ------------------------------------------------------------------------------
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> Re: [E-devel] Lib ICU Integration
> Tom Hacohen
> Tue, 13 Sep 2011 22:15:41 -0700
> 
> On 14/09/11 05:39, Govindaraju SM wrote:
> > Hello All,
> >
> > We are considering lib ICU integration
> > ( http://icu-project.org/apiref/icu4c/ ) with EFL to enhance the
> > localization support.
> >
> > Initially, Date&  time input / display  with ucal, udat, uloc features.
> > ICU  provides API to get default system Locale ( or user specified )
> > specific date and time layout formats ( “ddMMyyyy hh:mm a”,  “MMddyyyy
> > HH:mm” , “yyyyMMdd hh:mm a”  etc ),  locale specific formatted strings,
> > context based field limit ( Feb –28,  Leap yr Feb –29 etc ).
> >
> > Pls provide your thought on this.
> >
> 
> I'm not sure it's wanted. From what I hear/have seen, ICU is fat and 
> bloated; That's why I chose using the libraries I chose when 
> implementing the unicode-related text features, e.g, fribidi, harfbuzz, 
> liblinebreak, which are considered lighter, faster and better designed.
> 
> The real question is what do you feel you can't do with just 
> locale/strftime. I'd like to see more information on what you are trying 
> to achieve instead of how (ICU integration).
> 
> Furthermore, what does this "integration" include? What do you plan on 
> doing?
> 
> In my opinion this is not needed at best, and should probably be 
> avoided. With that being said, my opinions are based on the little 
> information you provided. Please provide more information.
> 
> Thanks,
> Tom.
> ------------------------------------------------------------------------------
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to