377753 - Look and Feel of minimonths should be adapted

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Berend Cornelius]

According to the specification in http://wiki.mozilla.org/Calendar:Calendar_View#Month_View the minimonths should be adapted. In a first step this will be applied only to the minimonths within the recurrence dialog. In a later step these implementations will be consolidated with the other minimonth inplementations.

Comment 1

[Christian Jansen]

Berend, I don't want to stop you, but the stuff on that page is just a bunch of ideas which might have to be finalized or completely revised. It is no spec.

Comment 2

[Peter Weilbacher]

When you are working on the minimonths, I think you should also change them to use platform fonts. Currently, their font is hardcoded as Arial (see calendar/resources/skin/classic/datetimepickers/minimonth.css).

Or should I make this a new bug?

Comment 3

[ovidiu]

see also
http://groups.google.com/group/mozilla.dev.apps.calendar/browse_thread/thread/e8682f57f93ffb34/d0b36263b8eaf8f5?#d0b36263b8eaf8f5

Comment 4

[Simon Paquet [:sipaq]]

Not going to happen for 0.8.

Comment 5

[Berend Cornelius]

I consolidated all the sourcecode about the minimonth and adapted the look and feel according to Christian's proposal:
My consolidate brought us the following additional files:
 calendar/base/themes/pinstripe/widgets/minimonth.css
 calendar/base/themes/winstripe/widgets/minimonth.css
 calendar/base/content/widgets/minimonth.xml
 calendar/base/themes/common/widgets/nav-buttons.png

On the other hand I could remove the following files:
 calendar/base/themes/common/mini-day-nav-buttons.png

 calendar/sunbird/themes/winstripe/sunbird/datetimepickers/minimonth.css
 calendar/sunbird/themes/winstripe/sunbird/datetimepickersleft-arrow-hover.png 
 calendar/sunbird/themes/winstripe/sunbird/datetimepickersleft-arrow.png 
 calendar/sunbird/themes/winstripe/sunbird/datetimepickersright-arrow.png 
 calendar/sunbird/themes/winstripe/sunbird/datetimepickersright-arrow-hover.png
 calendar/sunbird/themes/winstripe/sunbird/datetimepickers

 calendar/sunbird/themes/pinstripe/sunbird/datetimepickers/minimonth.css
 calendar/sunbird/themes/pinstripe/sunbird/datetimepickersleft-arrow-hover.png 
 calendar/sunbird/themes/pinstripe/sunbird/datetimepickersleft-arrow.png 
 calendar/sunbird/themes/pinstripe/sunbird/datetimepickersright-arrow.png 
 calendar/sunbird/themes/pinstripe/sunbird/datetimepickersright-arrow-hover.png
 calendar/sunbird/themes/pinstripe/sunbird/datetimepickers

 resources/content/datetimepickers/minimonth.css
 resources/content/datetimepickers/minimonth.xml

 resources/skin/classic/datetimepickers/minimonth.css
 resources/skin/classic/datetimepickers/left-arrow.gif  
 resources/skin/classic/datetimepickers/left-arrow-hover.gif
 resources/skin/classic/datetimepickers/right-arrow.gif
 resources/skin/classic/datetimepickers/right-arrow-hover.gif

Christian wanted me to not further make the minimonth flexible in width. I applied this change also in Sunbird. 
I tried to make thee minimonths keyboard-accessible by using toolbarbuttons in the minimonth header. However I am not quite through with this but want to file a follow-up bug for it. 
When minimonths are readonly as in the recurrence-preview binding I use simple labels instead.
One new functionality is the Today-button in the minimonth header with which it is possible to switch to today now.
Before I am asking for review I would like Andreas (and anybody else) to test it as this has really become a big patch.

Comment 6

[Berend Cornelius]

Attachment: patch v. #1

First version of the new minimonth

Comment 7

[Berend Cornelius]

Attachment: Screenshot of the new minimonth

Comment 8

[Steffen Röttig]

What is the target now?
http://wiki.mozilla.org/Calendar:Calendar_View#Month_View described in Comment #1
or this one
http://wiki.mozilla.org/Calendar:Improving_the_Calendar_Views#Calendar

???

Comment 9

[Steffen Röttig]

okay ... the screenshot is the answer.
sorry.

Comment 10

[Berend Cornelius]

Attachment: image for the navigation buttons of the minimonth-header

The is the image to be displayed on the navigation buttons ("<o>") in the minimonth header. Please copy into calendar/base/common/widget folder

Comment 11

[Bas van den Bosch]

If you use the minimonth and navigation-buttons, is the dropdown underneath the minimonth still needed? 

Comment 12

[Michiel van Leeuwen (email: mvl+moz@)]

The dropdown is for easy typing a date. That's usually faster, if you know the date. The dropdown itself is not needed here, indeed. A single textbox would do. Less double options -> less confusion -> better.
It might not need to be in the position it currently is. A popup of some sort might work.

Comment 13

[Berend Cornelius]

Attachment: patch v. #2 - unbitrotted

Comment 14

[Christian Jansen]

Comment on attachment 316177 [details] [diff] [review]
patch v. #2 - unbitrotted

Works good. Thanks for the patch. The only nit we should fix in a spin-off bug is the alignment for the "read only" version.

Comment 15

[Berend Cornelius]

Comment on attachment 316177 [details] [diff] [review]
patch v. #2 - unbitrotted

Now as Christian has approved the UI you can review the source code.
In reply to comment #14:
To align the header in the readonly mode is not quite that easy because the both labels -month and year - consume as much space as the longest possible value (string) requires.I could of course left-align the month label but then we would have a not so nice gap between the month and the year label.

Comment 16

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 316177 [details] [diff] [review]
patch v. #2 - unbitrotted


>+          try {
>+              var pref = Components.classes["@mozilla.org/preferences-service;1"]
>+                          .getService(Components.interfaces.nsIPrefBranch);
>+              this.weekStart = pref.getIntPref("calendar.week.start");
>+          } catch (e) {
>+              this.weekStart = 0;
>+          }
getPrefSafe("calendar.week.start", 0);

>+      <!--Attention - duplicate!!!!-->
???
>+      <method name="fireEvent">
>+        <parameter name="aEventName"/>
>+        <body><![CDATA[
>+            var event = document.createEvent('Events');
>+            event.initEvent(aEventName, true, true);
>+            this.dispatchEvent(event);
>+        ]]></body>
>+      </method>



>+.minimonth-year-name {
>+  min-width: 4em;
>+  font-weight: bold;
>+  padding: 0px;
>+  -moz-user-focus: normal;
>+}
>+
>+.minimonth-year-name-readonly {
>+  min-width: 4em;
>+  font-weight: bold;
>+  -moz-padding-start: 4px;
>+}
...
>+         <xul:deck>
>+           <xul:text anonid="yearcell" class="minimonth-year-name-readonly"/>
>+           <xul:text class="minimonth-year-name-readonly"/>
>+         </xul:deck>
Why do we need two xul:text for this? wouldn't one xul:text with xbl:inherits="readonly" and rules with [readonly="true"] suffice?


r=philipp with comments fixed.

Comment 17

[Berend Cornelius]

Worked in philipp's comments and checked in patch on trunk and MOZILLA_1_8_BRANCH
-> fixed

Comment 18

[Andreas Treumann]

Checked in lightning build 2008062218 and sunbird 20080622 -> VERIFIED