Closed Bug 468420 Opened 13 years ago Closed 13 years ago

Consolidation of the navigation bar


(Calendar :: Calendar Frontend, defect)

Not set


(Not tracked)



(Reporter: berend.cornelius09, Assigned: berend.cornelius09)



(6 files, 2 obsolete files)

The implementation of the new navigation bar has been done within  Bug 454933 -  [calendar integration] move month, day, week mode buttons into calendar view
but as I mentioned already in bug 454933 comment #4 the way this bar is embedded within the views is kind of suboptimal: Historically we had different navigation bars for each view which lead us to the concept of the decorated views that again embed the different calendar-views. The current navigation bar however is basically the same over all views except for the description of the displayed range. In this context it is kind of suboptimal to have the tab-buttons implemented separately for each view - there must be only one tabbox control with the tab-buttons above all views. I noticed a certain focus flaw which probably also derives from this redundancy.
So I suggest to make the navigation bar singular over all calendar-views. The final consequence of this would be to make the decorated view obsolete and merge the methods of "calIDecoratedView.idl" into "calIcalendarView.idl" and into the navigation-bar and to replace the existing view-deck control by a tabbox control.
Attached patch patch v. #1 (obsolete) — Splinter Review
first steps - that should not harm too much - to achieve of what I tried to explain in the bug description.
Assignee: nobody → Berend.Cornelius
Attached patch patch v. #2 (obsolete) — Splinter Review
detected and resloved a bug that was not displayed by the error console.
Attachment #351870 - Attachment is obsolete: true
I think this issue is too big to put it into one patch, so I deliver a first one that majorly moves the navigationbar out of the decorated-view-panes, so that becomes a singleton. Alongside I removed some no longer needed functions in messenger-overlay-sidebar.js - hope that's ok.
Attachment #351872 - Attachment is obsolete: true
Attachment #355973 - Flags: review?(philipp)
Comment on attachment 355973 [details] [diff] [review]
[checked in] patch v. #3

>diff --git a/calendar/base/content/calendar-common-sets.xul b/calendar/base/content/calendar-common-sets.xul
>+    <vbox id="calendar-view-box" context="calendar-view-context-menu">
Sorry I didn't say anything earlier, but I don't think common-sets is the right file for this. That file was thought for things like: popupset, commandset, stringbundlesets, broadcastersets, ...

I'd rather see a new file, maybe calendar-view-overlay.xul or maybe also calendar-views.xul 

>+++ b/calendar/lightning/content/messenger-overlay-sidebar.xul
>+          <vbox id="calendar-view-box"/>
Please add a comment that this is needed since it will be overlayed by the calendar core code.

>diff --git a/calendar/sunbird/base/content/calendar.xul b/calendar/sunbird/base/content/calendar.xul
>+    <vbox id="calendar-view-box" flex="1"/>
Same here.

Attachment #355973 - Flags: review?(philipp) → review+
pushed to commm-central:

When giving this patch a final test after the checkin I detected bug:
The Unifinder overlays itself between the navigation-bar and the calendar views as can be seen when the Unifinder is opened (check Menu item View/Find Events). But it should appear above the navigation-bar. I will deliver a second patch to resolve this.
This should fix it. I also removed some deprecated sources from calendar-common-sets.xul.
Attachment #356490 - Flags: review?(philipp)
Attachment #355973 - Attachment description: patch v. #3 → [checked in] patch v. #3
OS: Linux → All
Hardware: x86 → All
Target Milestone: --- → 1.0
Comment on attachment 356490 [details] [diff] [review]
[checked in] patch v. #4

Attachment #356490 - Flags: review?(philipp) → review+
patch v. #4 pushed to comm-central:

issue remains open
Attachment #356490 - Attachment description: patch v. #4 → [checked in] patch v. #4
With this patch I moved the navigationbar into the new file calendar-views.xul. I don't see a need for a binding in this case anymore and this way we have all the code around the calendar-views in one place.
Attachment #356732 - Flags: review?(philipp)
Attachment #356732 - Flags: review?(philipp) → review+
Comment on attachment 356732 [details] [diff] [review]
[checked in] patch v. #5

>+                    navigationBar.setDateRange(this.rangeStartDate, this.rangeEndDate, aToolTipTexts);
Since we don't have any namespaces in chrome js files, I think we should either name this calNavigationBar or create a namespace object cal and then have the bar be called cal.navigationBar

>+++ b/calendar/base/content/calendar-views.js
>+ *   Berend Cornelius <> *
Remove extra star at end of line.

>+let navigationBar = {
I'd prefer the syntax:

let navigationBar = {
  onLoad: function loadNavigationBar() { ... }

in case you prefer to go with calNavigationBar or otherwise:

var cal = cal || {};
cal.navigationBar = {
  onLoad: function loadNavigationBar() { ... }

>+++ b/calendar/base/content/calendar-views.xul
>+<?xml-stylesheet type="text/css" href="chrome://global/skin/global.css"?>
Why do you need global skin here? calendar-views.xul isn't an extra dialog and global.css should be included through the opening dialog.

>+<!DOCTYPE overlay[
>+    <!ENTITY % dtd4 SYSTEM "chrome://calendar/locale/calendar.dtd" > %dtd4;
> ]>
<!DOCTYPE overlay SYSTEM "chrome://calendar/locale/calendar.dtd" >

>+        <hbox id="nav-control">
We might want to prefix with calendar- since other extensions might think of the same name?

>+       <deck flex="1"
>             id="view-deck"
>             persist="selectedIndex"
>             ondraggesture="nsDragAndDrop.startDrag(event, calendarViewDNDObserver);"
If I saw this right the view-deck is now in calendar-views.xul, which itself is an overlay. Please make sure that anything that overlays the view-deck (i.e the views themselves) overlay calendar-views.xul directly and not the window.

r=philipp with comments considered.
addressed the comments of philipp and pushed patch v. #5 to comm-central:

I think I will need another patch to complete this issue.
Attachment #356732 - Attachment description: patch v. #5 → [checked in] patch v. #5
I checked patch v5, the cop attribute in the navigation bar is gone now.
Oh, I mean 'crop attribute'
Attached image navbar text
The patch attached is quite big and I apologize for that. Within it I removed the calendar-decorated-base binding which involved quite a lot of consolidation work. When i then tested the patch afterwards I found there were several weird things in relation with the preference observation that I then fixed and consolidated, too.

What remains to be done?
- The bindings "calendar-decorated-month-view" and "calendar-decorated-multiday-base-view" are not needed anymore and can be merged into the bindings "calendar-multiday-view" and "calendar-month-view".
- the tabbox element, that was to replace the "view-deck" element is not yet implemented
- The use of the view properties "[start|end]Date, query[start|end], range[start|end], [start|end]day is confusing and should be overworked. Some of them can certainly be removed.
- I find, that all the "calendar-decorated-...-view" bindings should be renamed to "calendar-[day|week|multi-week|month]-view" as in fact we don't have any decorated views in their original meaning anymore. As the bindings are not very large anymore we can move them to a new single file base/content/calendar-views.xml

I did not want to make my patch even bigger than it is already now so I would like to deal with these leave these issues for another bug that I will set up then if it's Ok. I consequently suggest to close this bug after this patch has been pushed to comm-central.
Attachment #357671 - Flags: review?(philipp)
Comment on attachment 357671 [details] [diff] [review]
[checked in] patch v. #6

>+      <field name="mPrefObserver"><![CDATA[
>+      ({ calView: this,
>+         observe: function calViewPrefChange(subj, topic, pref) {
>+             this.calView.handlePreference(subj, topic, pref);
>+             return;
>+         }
>+      })
Why does this need to be an extra field? Can't we just add an observe method to the views directly?

>+      <property name="rotated">
>+        <getter><![CDATA[
>+            return (this.orient == 'horizontal');
>+        ]]></getter>
>+        <setter><![CDATA[
>+            this.orient = (val ? 'horizontal' : 'vertical');
>+            return val;
>+        ]]></setter>
>+      </property>
You could compact these:

<property onget="return (this.orient == 'horizontal')"
          onset="return (this.orient = (val ? 'horizontal' : 'vertical'))"/>

>+      <!-- A preference handler which is called by the preference observer.
>+           Can be overriden in derived bindings. -->
Typo: overridden

>+               case "":
>+                   break;
Please add a comment here, á la "Break here to ensure the view is refreshed".

>     <binding id="calendar-decorated-multiday-base-view"
>+             extends="chrome://calendar/content/calendar-multiday-view.xml#calendar-multiday-view">
The decorated view now extends the multiday view? This seems kind of strange to me. Do we even need the extra layer of decoration now?

>   <binding id="calendar-month-view" extends="chrome://calendar/content/calendar-base-view.xml#calendar-base-view">
>+    <content style="overflow: auto;" flex="1" xbl:inherits="context,item-context">
Can't we move this style to a css file? Also, did you test if xbl:inherits also works on the content node itself?

The rest looks good, r=philipp with comments considered.
Good work!
Attachment #357671 - Flags: review?(philipp) → review+
patch pushed to comm-central

Some remarks about comment #16:

>The decorated view now extends the multiday view? This seems kind of strange to
>me. Do we even need the extra layer of decoration now?

See my comment #15 where I said I would like to do this in a follow-up bug.

>Can't we move this style to a css file? Also, did you test if xbl:inherits also
>works on the content node itself?

I was aware of this when I implemented it but I left it as it is because
1) I already suggested to remove the decorated bindings.
2) Is there a way to set up a css selector bound to a "calendar-month-view" that is now the parent class of two other classes?
I will change it in a follow-up issue.

>Why does this need to be an extra field? Can't we just add an observe method to
>the views directly?
I somehow did not manage to set up an implementation that was easier than mine.

I would like to set this bug to "fixed", so that Andreas, who will be on holiday from Wednesday on, can test this for regressions.
I will set up a follow up issue then
Closed: 13 years ago
Resolution: --- → FIXED
Berend, out of interest, does this massive consolidation also have a positive/negative performance impact?
This issue resolves quite some no longer necessary indirections, so the performance impact should be positive. I can see no negative impact, yet have not measured this. But my primary intention for this issue was to make the code easier to maintain.
I checked patch v. #6 -> outcome:

- bug 'comment #12' isn't fixed.

- 'View/Current view/workweek days only' is defect.
Attached patch patch #7Splinter Review
This patch fixes the issue mentioned in comment #12 with the missing crop attribute and also the one in comment #20.  Bug 474601 -  "Start the week on " option doesn't affect Month and Multiweek Views should be fixed with this patch, too. Was just a stupid orthographical mistake
Attachment #358366 - Flags: review?(philipp)
Resolution: FIXED → ---
Attachment #357671 - Attachment description: patch v. #6 → [checked in] patch v. #6
Attachment #358366 - Flags: review?(philipp) → review+
patch pushed to comm-central:

issue is fixed with respect to comment #15 and comment #16 for which I will file follow - up bugs.
As far as I can see 
Bug 474601 -  Start the week on option doesn't affect Month and Multiweek Views
Bug 473547 -  'Start the week on' functionality is broken in multiweek/month view

are fixed with is patch, too.
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Checked in lightning and sunbird build 20090125 -> VERIFIED.
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.