Javascript calendar

74 views
Skip to first unread message

Emmanuel Blot

unread,
Dec 9, 2013, 5:08:33 AM12/9/13
to trac-...@googlegroups.com
Hi All,

Is there a way to disable the Trac Javascript calendar for date fields ?
It's driving me mad :-)

Thanks,
Manu

RjOllos

unread,
Dec 9, 2013, 11:30:27 AM12/9/13
to trac-...@googlegroups.com
Putting a snippet in site.js seems to work:

jQuery(document).ready(function($) {
  $(".hasDatepicker").datetimepicker("destroy");
});

What issues are you having with the datepicker?

Emmanuel Blot

unread,
Dec 9, 2013, 1:11:41 PM12/9/13
to trac-...@googlegroups.com
> Putting a snippet in site.js seems to work:
>
> jQuery(document).ready(function($) {
> $(".hasDatepicker").datetimepicker("destroy");
> });

Ok, thanks, I'll give it a try.

> What issues are you having with the datepicker?

Settings the time with the slider takes much more time than entering
the time in the text field, and whenever the text field is edited, the
datapicker can't help "fixing" the digits. The end result is that
using this widget is less effective that submitting the date/time with
a simple text field.

Having a datepicker that help entering a date/time would be nice.

However this auto-fixing, always-on feature that cannot be disabled
and understand most of the submitted values wrong is really getting on
the nerves :-) Automagic stuff always gets stupid at some point.
Helping is nice, forcing is -really- bad.

Issue #1
* Select a date field with an existing value, select the month, type
a new month value. As soon as the second digit of the month is
entered, the cursor is moved to the end of field, which is not natural
and requires more edition hits from the user to change the time.

Issue #2
* The time format on our server is configured to use the 24 hours
scheme (vs. 12 hours), but the datepicker sticks with 12 hours - I did
not get a chance to have a look and understand why. Whenever the
edited hour is >= 12, the time is automagically reverted to the 12
hour scheme - and there is not even a "pm" marker, e.g. "17" simply
becomes "05"

Issue #3
* Current time is "05:00:00". Move the cursor after "5" and hit
"backspace" to edit the hour. Datepicker wants to be smarter, replaces
the time with "12" (WTF?) and moves the cursor to the end of the text
field
* Similar issue if the day digits are selected and the user starts
typing a new day: datepicker changes the hour to something unrelated,
and moves the cursor at the end of the field... (except if the day is
invalid, in this case datapicker remains inactive and silent)
* It seems that as soon as datepicker is able to compute a valid
date, it steals the focus and starts playing on its own: type "01/01/"
-> boom, autocompletion is triggered with some default date.

I'm pretty sure I bumped into other issues, but each issue described
here is a PITA and justify, from my perspective, to get rid of this
"helper".

Moreover, whereas the following point are not issues, the make the
datepicker far less usable than most data picker available on other
websites:
* There is no way to jump to an arbitrary month or year.
* The hour/minute/second sliders are really not easy to use (my
personal feeling is that a slider is a bad idea to select a time)

Maybe it is just about a configuration issue.
The default JQuery UI with date-only selection does not trigger any of
these issues. It seems that these issues come from the addition of
time support.

Cheers,
Manu

Jun Omae

unread,
Dec 10, 2013, 12:11:52 PM12/10/13
to trac-...@googlegroups.com
On Tue, Dec 10, 2013 at 3:11 AM, Emmanuel Blot <eblo...@gmail.com> wrote:
> Issue #1
> * Select a date field with an existing value, select the month, type
> a new month value. As soon as the second digit of the month is
> entered, the cursor is moved to the end of field, which is not natural
> and requires more edition hits from the user to change the time.

I tried to keep the cursor position.

https://github.com/jun66j5/jQuery-Timepicker-Addon/commit/3fc9b003e72f7c35ab3c36e059d071317bc453ac

Replace trac/htdocs/js/jquery-ui-addons.js with the following.

https://github.com/jun66j5/jQuery-Timepicker-Addon/raw/v1.0.1_keep_cursor/jquery-ui-timepicker-addon.js

And, apply the following patch.

diff --git a/trac/web/chrome.py b/trac/web/chrome.py
index 6e82b5d..a47d24e 100644
--- a/trac/web/chrome.py
+++ b/trac/web/chrome.py
@@ -1141,8 +1141,9 @@ class Chrome(Component):
'first_week_day': get_first_week_day_jquery_ui(req),
'timepicker_separator': 'T' if is_iso8601 else ' ',
'show_timezone': is_iso8601,
+ # default timezone must be included
'timezone_list': get_timezone_list_jquery_ui() \
- if is_iso8601 else [],
+ if is_iso8601 else ['Z'],
'timezone_iso8601': is_iso8601,
})
add_script(req, 'common/js/jquery-ui-i18n.js')


> Issue #2
> * The time format on our server is configured to use the 24 hours
> scheme (vs. 12 hours), but the datepicker sticks with 12 hours - I did
> not get a chance to have a look and understand why. Whenever the
> edited hour is >= 12, the time is automagically reverted to the 12
> hour scheme - and there is not even a "pm" marker, e.g. "17" simply
> becomes "05"

That's so bad. However I cannot reproduce it and I don't know how to
configure to use the 24 hours scheme. Could you please provide the
configurations?


> Issue #3
> * Current time is "05:00:00". Move the cursor after "5" and hit
> "backspace" to edit the hour. Datepicker wants to be smarter, replaces
> the time with "12" (WTF?) and moves the cursor to the end of the text
> field

I think it is caused by issue #2.

Emmanuel Blot

unread,
Dec 20, 2013, 5:45:02 PM12/20/13
to trac-...@googlegroups.com
> And, apply the following patch.

Thanks, I'll give it a try.

> That's so bad. However I cannot reproduce it and I don't know how to
> configure to use the 24 hours scheme. Could you please provide the
> configurations?

The server is configured with the en_GB locale:

in trac.wsgi:
os.environ['LC_ALL'] = 'en_GB.UTF-8'

BTW, I found another time extension for JQueryUI's datepicker:
http://trentrichardson.com/examples/timepicker/

It seems to be able to deal with 24 hour format, but I have not tried
using it with Trac.

Best Regards,
Manu

RjOllos

unread,
Dec 20, 2013, 6:22:10 PM12/20/13
to trac-...@googlegroups.com
The TimePicker from Trent Richardson is actually what we are using in Trac:

Probably Jun has already looked at this as a solution to your issues, but we are currently using TimePicker (TP) version 1.1.1 on the trunk, TP version 1.0.1 on 1.0-stable and the latest released version of TP is 1.4.3. TP may get upgraded in the Trac 1.1.3 release along with the jQuery and jQuery UI upgrade:
 

Jun Omae

unread,
Dec 20, 2013, 10:25:05 PM12/20/13
to trac-...@googlegroups.com
I've filed the issue in http://trac.edgewall.org/ticket/11413.

On Sat, Dec 21, 2013 at 7:45 AM, Emmanuel Blot <eblo...@gmail.com> wrote:
>> That's so bad. However I cannot reproduce it and I don't know how to
>> configure to use the 24 hours scheme. Could you please provide the
>> configurations?
>
> The server is configured with the en_GB locale:
>
> in trac.wsgi:
> os.environ['LC_ALL'] = 'en_GB.UTF-8'

Thanks for the information. However, still cannot be reproduced
with/without Babel.

Are you using Babel? If you've installed Babel, the date/time is
parsed and displayed with your browser's language by default. In this
case, configure your language in the user's preferences page or
default language in basic settings of admin page to "English (United
Kingdom)" in preferences page.


--
Jun Omae <jun...@gmail.com> (大前 潤)

Emmanuel Blot

unread,
Dec 21, 2013, 5:49:03 AM12/21/13
to trac-...@googlegroups.com
> Are you using Babel?

No, Babel is not installed, we are only using the default english
settings, with the GB locale.

All dates are displayed in 24 hours format, except the ones that are
managed with the DatePicker.

Cheers,
Manu

Emmanuel Blot

unread,
Dec 22, 2013, 5:40:50 AM12/22/13
to trac-...@googlegroups.com
> Probably Jun has already looked at this as a solution to your issues, but we
> are currently using TimePicker (TP) version 1.1.1 on the trunk, TP version
> 1.0.1 on 1.0-stable and the latest released version of TP is 1.4.3. TP may
> get upgraded in the Trac 1.1.3 release along with the jQuery and jQuery UI
> upgrade:
> http://trac.edgewall.org/ticket/11019

Ok, thanks.

Jun Omae

unread,
Dec 24, 2013, 3:11:52 AM12/24/13
to trac-...@googlegroups.com
Hi,
Reproduced with Trac 1.1.1 without Babel. This issue is filed in
http://trac.edgewall.org/ticket/11416 and fixed.

To try to apply the following changes or upgrade using trunk on repository.

- http://trac.edgewall.org/changeset/12371
- http://trac.edgewall.org/changeset/12372

Thanks.

Emmanuel Blot

unread,
Dec 24, 2013, 4:39:04 AM12/24/13
to trac-...@googlegroups.com
Thanks a lot, I will give it a try!

Cheers,
Manu
> --
> You received this message because you are subscribed to the Google Groups "Trac Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+...@googlegroups.com.
> To post to this group, send email to trac-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/trac-users.
> For more options, visit https://groups.google.com/groups/opt_out.
Reply all
Reply to author
Forward
0 new messages