Spin-off from bug 351380. The datepicker (_not_ datetextpicker) in Lightning doesn't actually work at the moment. It's a cdt vs jsDate issue. Note that it is also obscured on Mac by bug 346318.
Created attachment 258678 [details] [diff] [review] rev0 - Use the same stuff as minimonth Note that I left the ltnGoToDate function in for the datetextpicker if/when it gets turned back on.
Comment on attachment 258678 [details] [diff] [review] rev0 - Use the same stuff as minimonth From a technical point of view the patch is correct, r=mickey. But I'm asking myself what we're actually trying to achieve by adding this stuff. Pressing the dropdown-button of the datetext-picker opens up a new minimonth while we already have a minimonth just above this field. I would like to ask for UI review before landing this, maybe somebody else understands what this is all about ;-)
I would expect a history of previously entered items and not a date picker.
I think the original aim here was to provide a way to enter a date, and not have to navigate to it using the minimonth. ui-r is a good idea. Let's get mvl's take on this. Christian: Other ideas for this would be welcome. :)
That looks pretty cool, Christian.
Thanks. The design for the mini month is not final. It should only give an impression how it could look like with an edit field integrated.
Basically, what I had in mind was more of a list of options instead of a plain text-field. At least, I didn't even know that it's possible to enter text like 'next friday' or something like that into the field until I saw the corresponding code. I suspect that most users don't get into the details of looking into the code how some specific feature actually works ;-) Wouldn't it be much better to have some sort of list with available options the user can choose from? Or is there some hidden clue that I didn't get up to now?
Nope. No clue. You had to know it could handle "tomorrow". That said, I'm not sure how typing in "Friday" is easier or faster than simply clicking on it in the above minimonth. My opinion is that the only reason for the datepicker would be to make it easy and fast to type in and go to a date. Otherwise you have to use the minimonth to navigate, which could be slow when you have to go backwards or forwards in time quite a bit. (Click on year, scroll to 1974, click on 1974, click on month, scroll to September, click on September, click on the 13th) I think the datetextpicker is more suited to text entry since it's a textbox and doesn't confusingly popup a version of the very thing above it when you click on it. So I'm going to check the patch in so the datepicker works, since it doesn't now, and that's just bad. As I said before, I'd like to know mvl's ui opinion on this, and that it should be handled in the spinoff bug 374080.
Patch checked in on MOZILLA_1_8_BRANCH and trunk. -> FIXED Please continue the discussion in bug 374080.
Verified with Lightning/0.5pre (2007032003) and Thunderbird/184.108.40.206 (20070221)
Created attachment 270147 [details] [diff] [review] ltnMinimonthPick() to not change view without (real) date change Maybe this could be opened as another bug, but I mention it here because of the change to "onchange" event for ltnDateTextPicker. This event is triggered on every focus-left, even if no change has been done. Reproduce (on TB 220.127.116.11 + Ltn 0.5 final, WinXP SP2): - open Inbox - click into ltnDateTextPicker (maybe copy the displayed date?) - leave focus, i.e. by clicking into the message pane - wait a few seconds --> view is changing to Calendar view by ltnMinimonthPick() I created a quick&dirty hack to check whether the dates in ltnDateTextPicker and ltnMinimonth are different, if the "onchange" comes from ltnDateTextPicker. Well, I think there could be a much better solution, but I converted the dates to strings, because the initial setting (today) contains the time as well... Sven.
Comment on attachment 270147 [details] [diff] [review] ltnMinimonthPick() to not change view without (real) date change Sven, please open a new bug and attach your patch there. This bug is already FIXED and VERIFIED.