Closed
Bug 400279
Opened 17 years ago
Closed 17 years ago
Category colors should be displayed next to the event boxes
Categories
(Calendar :: Calendar Frontend, enhancement)
Calendar
Calendar Frontend
Tracking
(Not tracked)
VERIFIED
FIXED
0.8
People
(Reporter: michael.buettner, Assigned: michael.buettner)
Details
(Whiteboard: [roadmap 0.8])
Attachments
(5 files, 3 obsolete files)
36.80 KB,
image/jpeg
|
Details | |
36.83 KB,
image/jpeg
|
Details | |
1.63 KB,
application/octet-stream
|
Details | |
90.65 KB,
image/png
|
Details | |
31.18 KB,
patch
|
michael.buettner
:
review+
michael.buettner
:
ui-review+
|
Details | Diff | Splinter Review |
According to the proposal at [1] categories should be displayed as a colored area next to the event boxes. Currently, the categories are getting displayed as a simple border around the boxes. [1] http://wiki.mozilla.org/Calendar:Improved_Events_and_Tasks
Assignee | ||
Comment 1•17 years ago
|
||
Screenshot to showcase category colors in the multiday view.
Assignee | ||
Comment 2•17 years ago
|
||
Screenshot to showcase category colors in the month view.
Assignee | ||
Comment 3•17 years ago
|
||
This zip-file contains the gradient image that is used to modulate the background color. It's just a 8-bit grayscale image that includes a vertical gradient with a highlight border on the left side.
Assignee | ||
Comment 4•17 years ago
|
||
This patch contains the necessary bits and pieces to make the views look like in the previously posted screen-shots.
Attachment #285371 -
Flags: review?(Berend.Cornelius)
Assignee | ||
Updated•17 years ago
|
Whiteboard: [roadmap 0.8]
Comment 5•17 years ago
|
||
>+ <xul:vbox anonid="category-box" hidden="true" class="calendar-item"> >+ <xul:hbox flex="1"> >+ <xul:image class="calendar-category-box-gradient" height="1px"/> >+ </xul:hbox> >+ <xul:hbox height="1"/> >+ </xul:vbox> This should be moved to an own binding as it has been copied twice (once slightly modified). > // we make assumptions about our position in the tree here; > // specifically, this should get us to a <calendar-event-box> > var evbox = this.parentNode.parentNode.parentNode.parentNode. >- parentNode.parentNode.parentNode; >+ parentNode.parentNode.parentNode.parentNode; Moving up x layers in the DOM hierarchy and expecting to find a calendar-event-box there seems to be very careless to me, especially when the evbox is outside the current binding. As you were touching this implementation I think we should change this now: I suggest to walk up the DOM hierarchy in a loop until parentNode.localName == "calendar-event-box". I would consider calUtils.js as an appropriate location for such a utility function. I wonder whether it would not be better to assign the calendar-event-box via property or method from the client and only hold a fallback. > .calendar-event-box-container[parentorient="vertical"] { >- margin: 2px; >+ margin: 1px; > } > > .calendar-event-box-container[parentorient="horizontal"] { >- margin: 2px; >+ margin: 1px; > } > > .event-frame { >- margin: 2px; >+ margin: 1px; > } Why do we need three different rules here? When I started testing the code I ran into an issue: Deleting a category in the category-preference tab-page the color of the event item. Yet the category-box is not removed which is quite disturbing e.g. when you select such an event afterwards -> the category-box is still displayed but not with the highlighted background-color like the rest of the event item. In the old implementation such a behavior did not occur because only the border-style of the event item was modified. Maybe it would be useful to set up a "onsyncfrompreference" handler. Besides these issues the patch works as advertised but I am afraid I have to deny the patch review at this state.
Comment 6•17 years ago
|
||
Comment on attachment 285371 [details] [diff] [review] patch v1 >diff -a -x CVS -U 8 -pN -rN mozilla_ref/calendar/base/content/calendar-month-view.xml mozilla/calendar/base/content/calendar-month-view.xml >--- mozilla_ref/calendar/base/content/calendar-month-view.xml Fri Oct 5 12:24:27 2007 >+++ mozilla/calendar/base/content/calendar-month-view.xml Thu Oct 18 15:18:17 2007 >@@ -80,16 +80,22 @@ > wrap="true"/> > <xul:spacer flex="1"/> > </xul:vbox> > </xul:hbox> > <xul:image anonid="gradient" > class="calendar-event-box-gradient event-frame" > hidden="true" height="1px"/> > </xul:stack> >+ <xul:vbox anonid="category-box" hidden="true" class="calendar-item"> >+ <xul:hbox flex="1"> >+ <xul:image class="calendar-category-box-gradient" height="1px"/> >+ </xul:hbox> >+ <xul:hbox height="1"/> >+ </xul:vbox> > </xul:box> > <xul:image class="calendar-event-box-shadow-right"/> > </xul:hbox> > <xul:box orient="horizontal"> > <xul:image class="calendar-event-box-shadow-edge-left"/> > <xul:image class="calendar-event-box-shadow-bottom" flex="1"/> > <xul:image class="calendar-event-box-shadow-edge-right"/> > </xul:box> >diff -a -x CVS -U 8 -pN -rN mozilla_ref/calendar/base/content/calendar-multiday-view.xml mozilla/calendar/base/content/calendar-multiday-view.xml >--- mozilla_ref/calendar/base/content/calendar-multiday-view.xml Mon Oct 15 17:52:58 2007 >+++ mozilla/calendar/base/content/calendar-multiday-view.xml Thu Oct 18 15:20:07 2007 >@@ -232,17 +232,17 @@ > event.stopPropagation(); > var whichside = this.getAttribute("whichside"); > if (!whichside) > return; > > // we make assumptions about our position in the tree here; > // specifically, this should get us to a <calendar-event-box> > var evbox = this.parentNode.parentNode.parentNode.parentNode. >- parentNode.parentNode.parentNode; >+ parentNode.parentNode.parentNode.parentNode; > > // still select it (since we'll stopPropagation()) > evbox.calendarView.setSelectedItems(1, > [event.ctrlKey ? evbox.mOccurrence.parentItem : evbox.mOccurrence]); > > // then start dragging it > evbox.parentColumn.startSweepingToModifyEvent(evbox, evbox.mOccurrence, whichside, event.screenX, event.screenY); > ]]></handler> >@@ -1819,46 +1819,54 @@ > <xul:image anonid="shadow-edge-left" > class="calendar-event-box-shadow-edge-left"/> > </xul:box> > <xul:box xbl:inherits="orient,width,height" flex="1"> > <xul:image anonid="shadow-left-if-vertical" > class="calendar-event-box-shadow-left" > hidden="true"/> > <xul:box anonid="event-container" xbl:inherits="orient" flex="1"> >- <xul:box class="calendar-event-selection" >- flex="1" >- xbl:inherits="orient"> >- <xul:stack anonid="eventbox" >- align="stretch" >- class="calendar-event-box-container" >- flex="1" >- xbl:inherits="context,parentorient=orient"> >- <xul:vbox class="calendar-event-details"> >- <xul:description anonid="event-name" class="calendar-event-details-core" flex="1"/> >- <xul:textbox anonid="event-name-textbox" >- class="plain calendar-event-details-core" >- flex="1" >- hidden="true" >- style="background: transparent !important;" >- wrap="true"/> >- </xul:vbox> >- <xul:image class="calendar-event-box-gradient"/> >- <xul:box xbl:inherits="orient" flex="1"> >- <xul:calendar-event-gripbar anonid="gripbar1" >- class="calendar-event-box-grippy-top" >- whichside="start" >- xbl:inherits="parentorient=orient"/> >- <xul:spacer flex="1"/> >- <xul:calendar-event-gripbar anonid="gripbar2" >- class="calendar-event-box-grippy-bottom" >- whichside="end" >- xbl:inherits="parentorient=orient"/> >- </xul:box> >- </xul:stack> >+ <xul:box orient="horizontal" flex="1"> >+ <xul:box class="calendar-event-selection" xbl:inherits="orient" flex="1"> >+ <xul:stack anonid="eventbox" >+ align="stretch" >+ class="calendar-event-box-container" >+ flex="1" >+ xbl:inherits="context,parentorient=orient"> >+ <xul:hbox class="calendar-event-details"> >+ <xul:vbox flex="1"> >+ <xul:description anonid="event-name" class="calendar-event-details-core" flex="1"/> >+ <xul:textbox anonid="event-name-textbox" >+ class="plain calendar-event-details-core" >+ flex="1" >+ hidden="true" >+ style="background: transparent !important;" >+ wrap="true"/> >+ </xul:vbox> >+ </xul:hbox> >+ <xul:image class="calendar-event-box-gradient"/> >+ <xul:box xbl:inherits="orient" flex="1"> >+ <xul:calendar-event-gripbar anonid="gripbar1" >+ class="calendar-event-box-grippy-top" >+ whichside="start" >+ xbl:inherits="parentorient=orient"/> >+ <xul:spacer flex="1"/> >+ <xul:calendar-event-gripbar anonid="gripbar2" >+ class="calendar-event-box-grippy-bottom" >+ whichside="end" >+ xbl:inherits="parentorient=orient"/> >+ </xul:box> >+ </xul:stack> >+ </xul:box> >+ <xul:vbox anonid="category-box" hidden="true" class="calendar-item"> >+ <xul:hbox flex="1"> >+ <xul:image class="calendar-category-box-gradient"/> >+ </xul:hbox> >+ <xul:hbox height="1"/> >+ </xul:vbox> > </xul:box> > </xul:box> > <xul:image anonid="shadow-bottom" > class="calendar-event-box-shadow-bottom"/> > </xul:box> > <xul:box xbl:inherits="orient"> > <xul:image anonid="shadow-edge-left-if-vertical" > class="calendar-event-box-shadow-edge-left" >diff -a -x CVS -U 8 -pN -rN mozilla_ref/calendar/base/content/calendar-view-core.xml mozilla/calendar/base/content/calendar-view-core.xml >--- mozilla_ref/calendar/base/content/calendar-view-core.xml Fri Oct 5 12:24:27 2007 >+++ mozilla/calendar/base/content/calendar-view-core.xml Thu Oct 18 15:21:11 2007 >@@ -67,16 +67,22 @@ > style="background: transparent !important;" > wrap="true"/> > <xul:spacer flex="1"/> > </xul:vbox> > <xul:image anonid="gradient" > class="calendar-event-box-gradient event-frame" > hidden="true" height="1px"/> > </xul:stack> >+ <xul:vbox anonid="category-box" hidden="true" class="calendar-item"> >+ <xul:hbox flex="1"> >+ <xul:image class="calendar-category-box-gradient" height="1px"/> >+ </xul:hbox> >+ <xul:hbox height="1"/> >+ </xul:vbox> > <xul:image class="calendar-event-box-shadow-right"/> > </xul:hbox> > <xul:hbox> > <xul:image class="calendar-event-box-shadow-edge-left"/> > <xul:image class="calendar-event-box-shadow-bottom" flex="1"/> > <xul:image class="calendar-event-box-shadow-edge-right"/> > </xul:hbox> > </xul:vbox> >@@ -184,17 +190,27 @@ > for (var i = 0; i < categoriesList.length; i++ ) { > // Remove illegal chars. > categoriesList[i] = categoriesList[i].replace(' ','_'); > categoriesList[i] = categoriesList[i].toLowerCase(); > } > categoriesSelectorList = categoriesList.join(" "); > } > >- container.setAttribute("item-category", categoriesSelectorList); >+ var box = document.getAnonymousElementByAttribute(this, >+ "anonid", >+ "category-box"); >+ if (box) { >+ box.setAttribute("item-category", categoriesSelectorList); >+ if (categoriesSelectorList.length > 0) { >+ box.removeAttribute("hidden"); >+ } else { >+ box.setAttribute("hidden","true"); >+ } >+ } > ]]></body> > </method> > > <method name="startEditing"> > <body><![CDATA[ > this.editingTimer = null; > this.mOriginalTextLabel = this.mOccurrence.title; > >diff -a -x CVS -U 8 -pN -rN mozilla_ref/calendar/base/content/calendar-views.js mozilla/calendar/base/content/calendar-views.js >--- mozilla_ref/calendar/base/content/calendar-views.js Mon Sep 17 17:57:07 2007 >+++ mozilla/calendar/base/content/calendar-views.js Thu Oct 18 12:30:58 2007 >@@ -377,17 +377,17 @@ function updateStyleSheetForObject(aObje > } else { > // This is a category, where we set the border. Also note that we > // use the ~= selector, since there could be multiple categories > name = aObject.replace(' ','_'); > selectorPrefix = "item-category~="; > ruleUpdaterFunc = function categoryRuleFunc(aRule, aIndex) { > var color = getPrefSafe("calendar.category.color."+aObject, null); > if (color) { >- aRule.style.border = color + " solid 2px"; >+ aRule.style.backgroundColor = color; > } else { > aSheet.deleteRule(aIndex); > } > }; > } > > var selector = '.calendar-item[' + selectorPrefix + '"' + name + '"]'; > >diff -a -x CVS -U 8 -pN -rN mozilla_ref/calendar/base/jar.mn mozilla/calendar/base/jar.mn >--- mozilla_ref/calendar/base/jar.mn Thu Sep 20 18:29:27 2007 >+++ mozilla/calendar/base/jar.mn Wed Oct 17 14:14:27 2007 >@@ -83,16 +83,17 @@ calendar.jar: > #expand skin/classic/calendar/toolbar-small.png (themes/__THEME__/toolbar-small.png) > #expand skin/classic/calendar/mode-switch-icons.png (themes/__THEME__/mode-switch-icons.png) > #expand skin/classic/calendar/calendar-management.css (themes/__THEME__/calendar-management.css) > skin/classic/calendar/event-grippy-bottom.png (themes/common/event-grippy-bottom.png) > skin/classic/calendar/event-grippy-left.png (themes/common/event-grippy-left.png) > skin/classic/calendar/event-grippy-right.png (themes/common/event-grippy-right.png) > skin/classic/calendar/event-grippy-top.png (themes/common/event-grippy-top.png) > skin/classic/calendar/gradient-overlay.png (themes/common/gradient-overlay.png) >+ skin/classic/calendar/category-overlay.png (themes/common/category-overlay.png) > skin/classic/calendar/shadow-bottom.png (themes/common/shadow-bottom.png) > skin/classic/calendar/shadow-edge-left.png (themes/common/shadow-edge-left.png) > skin/classic/calendar/shadow-edge-right.png (themes/common/shadow-edge-right.png) > skin/classic/calendar/shadow-left.png (themes/common/shadow-left.png) > skin/classic/calendar/shadow-right.png (themes/common/shadow-right.png) > skin/classic/calendar/day-box-item-image.png (themes/common/day-box-item-image.png) > skin/classic/calendar/mini-day-nav-buttons.png (themes/common/mini-day-nav-buttons.png) > skin/classic/calendar/mini-day-background.png (themes/common/mini-day-background.png) >diff -a -x CVS -U 8 -pN -rN mozilla_ref/calendar/base/themes/pinstripe/calendar-views.css mozilla/calendar/base/themes/pinstripe/calendar-views.css >--- mozilla_ref/calendar/base/themes/pinstripe/calendar-views.css Sun Aug 26 17:59:52 2007 >+++ mozilla/calendar/base/themes/pinstripe/calendar-views.css Thu Oct 18 12:34:28 2007 >@@ -158,25 +158,25 @@ calendar-header-container[weekend="true" > } > > .calendar-event-box-container { > padding: 0; > overflow: hidden; > } > > .calendar-event-box-container[parentorient="vertical"] { >- margin: 2px; >+ margin: 1px; > } > > .calendar-event-box-container[parentorient="horizontal"] { >- margin: 2px; >+ margin: 1px; > } > > .event-frame { >- margin: 2px; >+ margin: 1px; > } > > .calendar-event-details { > padding-left: 2px; > } > > .calendar-event-details-core { > width: 0px; >@@ -412,16 +412,20 @@ box[dropbox="true"] { > height: 1.2em; > margin: 1px; > padding: 0px 1px 0px 1px; > opacity: 0.5; > } > > .calendar-event-box-gradient { > list-style-image: url("chrome://calendar/skin/gradient-overlay.png"); >+} >+ >+.calendar-category-box-gradient { >+ list-style-image: url("chrome://calendar/skin/category-overlay.png"); > } > > .calendar-event-box-shadow-right { > list-style-image: url("chrome://calendar/skin/shadow-right.png"); > } > > .calendar-event-box-shadow-left { > list-style-image: url("chrome://calendar/skin/shadow-left.png"); >diff -a -x CVS -U 8 -pN -rN mozilla_ref/calendar/base/themes/winstripe/calendar-views.css mozilla/calendar/base/themes/winstripe/calendar-views.css >--- mozilla_ref/calendar/base/themes/winstripe/calendar-views.css Sun Aug 26 18:00:03 2007 >+++ mozilla/calendar/base/themes/winstripe/calendar-views.css Thu Oct 18 12:34:32 2007 >@@ -158,25 +158,25 @@ calendar-header-container[weekend="true" > } > > .calendar-event-box-container { > padding: 0; > overflow: hidden; > } > > .calendar-event-box-container[parentorient="vertical"] { >- margin: 2px; >+ margin: 1px; > } > > .calendar-event-box-container[parentorient="horizontal"] { >- margin: 2px; >+ margin: 1px; > } > > .event-frame { >- margin: 2px; >+ margin: 1px; > } > > .calendar-event-details { > padding-left: 2px; > } > > .calendar-event-details-core { > width: 0px; >@@ -412,16 +412,20 @@ box[dropbox="true"] { > height: 1.2em; > margin: 1px; > padding: 0px 1px 0px 1px; > opacity: 0.5; > } > > .calendar-event-box-gradient { > list-style-image: url("chrome://calendar/skin/gradient-overlay.png"); >+} >+ >+.calendar-category-box-gradient { >+ list-style-image: url("chrome://calendar/skin/category-overlay.png"); > } > > .calendar-event-box-shadow-right { > list-style-image: url("chrome://calendar/skin/shadow-right.png"); > } > > .calendar-event-box-shadow-left { > list-style-image: url("chrome://calendar/skin/shadow-left.png");
Attachment #285371 -
Flags: review-
Updated•17 years ago
|
Attachment #285371 -
Flags: review?(Berend.Cornelius) → review-
Assignee | ||
Comment 7•17 years ago
|
||
Updated version that incorporates the previous comments. > This should be moved to an own binding as it has been copied twice. Nicely spotted. I introduced it as calendar-view-core#calendar-category-box. I hope that we don't run into performance problems one day, but I admit that it makes sense to avoid redundant code unless there's a good reason for doing otherwise. > Moving up x layers in the DOM hierarchy and expecting to find a > calendar-event-box there seems to be very careless to me, especially when the > evbox is outside the current binding. First of all, you're right. This particular piece of code has always been a thorn in my side, but I always flinched from touching it. Admittedly, again, we need to improve this part. But moving upwards the hierarchy until we hit some element is always bad, regardless of the way we iterate the nodes. It's much better to use events the way they are intended to be used. The 'mousedown' handler of the event box has all the necessary bits and pieces to invoke the drag operation, but it doesn't know on which side the user has clicked. I'm now injecting this information into the event and let it further bubble upwards in the hierarchy until it gets catched by the appropriate handler. > Why do we need three different rules here? Each of them is necessary. 'calendar-event-box-container' needs to be mentioned twice for each orientation and 'event-frame' is something completely different. I didn't change anything here. > Deleting a category in the category-preference tab-page the color of the event > item. Yet the category-box is not removed... Basically this is outside the scope of this patch, as it introduces the colored stripes next to the event boxes but isn't here to address the remaining problems that the categories certainly have. Admittedly, the views should be refreshed if the categories have changed. I added this particular feature, but didn't touch anything else. Propagating changes from the categories to the events need to be addressed somewhere else. Please note, that this is still a field where we are still trying to fill the void.
Attachment #285371 -
Attachment is obsolete: true
Attachment #286261 -
Flags: ui-review?(christian.jansen)
Attachment #286261 -
Flags: review?(Berend.Cornelius)
Comment 8•17 years ago
|
||
I have a partial implementation of the attached screenshot lying around. I don't really like the code yet, but I do like the UI. It doesn't have this border between the main box and the category box.
Comment 9•17 years ago
|
||
(In reply to comment #8) > Created an attachment (id=286262) [details] > alternative screenshot > > I have a partial implementation of the attached screenshot lying around. I > don't really like the code yet, but I do like the UI. It doesn't have this > border between the main box and the category box. > I like your proposal. But I think we need to make sure that it works for color combinations like blue & red, etc. @ Mickey: What do you think about MVLs proposal?
Comment 10•17 years ago
|
||
(In reply to comment #7) > > Deleting a category in the category-preference tab-page the color of the event > item. Yet the category-box is not removed... > Basically this is outside the scope of this patch, as it introduces the colored > stripes next to the event boxes but isn't here to address the remaining > problems that the categories certainly have. Admittedly, the views should be > refreshed if the categories have changed. I added this particular feature, but > didn't touch anything else. Propagating changes from the categories to the > events need to be addressed somewhere else. Please note, that this is still a > field where we are still trying to fill the void. > At first I disagreed with you, because you introduced a regression that had not yet occured before: Beforehand the css -style attribute that denoted the catogory (the border color of the event) was completely removed, so no information about the category remained, whereas after your patch the information about the category was only partly removed. Then I had a talk with Daniel and Christian about the behavior of categories in calendar: Basically we have defined preferenced categories that are displayed by a distinguished color. On the other hand we have categories defined in events that are not necessarily part of this preference list. These categories currently have no assigned color and are not displayed in the calendar view (but they turn up in the respective calendar event dialog listbox). Christian suggested to display these categories with a reserved color (white -as there is no other close color to this) also within the calendar view. If this suggestion is accepted we could handle this in a follow-up bug and take your solution as it is. One particular unweariness remains: When the user removes a category from the preferences he is currently left uncertain whether this will also remove the categories from the events. As this is not the case he should be informed about this with a messagebox (like Outlook) or - as I would prefer - with a label at the bottom of the tabpage. The wording of this message (or warning) could be something like: "Removing a category will not affect any categories priorily defined in the calendar events".
Assignee | ||
Comment 11•17 years ago
|
||
> At first I disagreed with you, because you introduced a regression that had not
> yet occured before
The patch as it currently stands does not cause any regression, you most probably got me wrong.
Comment 12•17 years ago
|
||
Comment on attachment 286261 [details] [diff] [review] patch v2 >+ // refresh view if categories seem to have changed >+ if (pref.indexOf("calendar.category.color") == 0) { >+ if (!this.calView.startDay || !this.calView.endDay) { >+ // Don't refresh if we're not initialized >+ return; >+ } >+ // Refresh the view to recreate the event boxes >+ this.calView.goToDay(this.calView.selectedDay); >+ } >+ Wouldn't this logic be better placed once in "calendar-decorated-base-view" binding instead of using it in several derived bindings? >- event.stopPropagation(); >- var whichside = this.getAttribute("whichside"); >- if (!whichside) >- return; >- >- // we make assumptions about our position in the tree here; >- // specifically, this should get us to a <calendar-event-box> >- var evbox = this.parentNode.parentNode.parentNode.parentNode. >- parentNode.parentNode.parentNode; >- >- // still select it (since we'll stopPropagation()) >- evbox.calendarView.setSelectedItems(1, >- [event.ctrlKey ? evbox.mOccurrence.parentItem : evbox.mOccurrence]); >- >- // then start dragging it >- evbox.parentColumn.startSweepingToModifyEvent(evbox, evbox.mOccurrence, whichside, event.screenX, event.screenY); >+ // store the attribute 'whichside' in the event object >+ // but *don't* call stopPropagation(). as soon as the >+ // enclosing event box will receive the event it will >+ // make use of this information in order to invoke the >+ // appropriate action. >+ event.whichside = this.getAttribute("whichside"); very bright idea! > > .calendar-event-box-container[parentorient="vertical"] { >- margin: 2px; >+ margin: 1px; > } > > .calendar-event-box-container[parentorient="horizontal"] { >- margin: 2px; >+ margin: 1px; > } > > .event-frame { >- margin: 2px; >+ margin: 1px; > } As we discussed at least one rule is redundant. This patch works as advertised -> r+
Attachment #286261 -
Flags: review?(Berend.Cornelius) → review+
Assignee | ||
Comment 13•17 years ago
|
||
(In reply to comment #9) > I like your proposal. But I think we need to make sure that it works for color > combinations like blue & red, etc. > @ Mickey: What do you think about MVLs proposal? At first glance I thought that getting rid of the right border in case we display the category box looks better. But judging both screenshots again, I think full borders around both boxes looks better. This patch reduces the border from 2px to 1px which makes the boxes more filigree, so I think we should take the first proposal.
Assignee | ||
Comment 14•17 years ago
|
||
(In reply to comment #12) > Wouldn't this logic be better placed once in "calendar-decorated-base-view" > binding instead of using it in several derived bindings? I think we should move the separate pref-observer implementations to calendar-decorated-base and override particular bits and pieces in the derived bindings. But I don't want to incorporate this into this patch but would prefer to address this issue in a spin-off bug.
Assignee | ||
Comment 15•17 years ago
|
||
Unbitrotten version of the patch including latest review comments.
Attachment #286261 -
Attachment is obsolete: true
Attachment #286559 -
Flags: ui-review?(christian.jansen)
Attachment #286559 -
Flags: review+
Attachment #286261 -
Flags: ui-review?(christian.jansen)
Comment 16•17 years ago
|
||
UI Review: - I like th 1px event border +1 for that. - Generally I would appreciate, if we reintroduce the category list. IMO it makes not too much sense to introduce categories without a default list. - Regarding the appearance of category boxes we should go with MVL's suggestion. After playing around a little bit it seams too be the better solution. - Event selection: The selection should span over the event & the category - Category type is not displayed in Event Summary dialog Bugs: It is not possible to adjust the length of an event by click-drag. I'm not sure if the following bug is caused by this patch. - Create an Event - Click somewhere in the UI - Try to resize the event Category not displayed - Create an event - Apply a self defined category (eg. Birthday) - Double click the event - Category "Birthday" is not selected in Category DropDown
Updated•17 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•17 years ago
|
Flags: wanted-calendar0.8?
Assignee | ||
Comment 17•17 years ago
|
||
(In reply to comment #16) > - Category type is not displayed in Event Summary dialog Christian, would you please be so kind and update the event summary dialog specification, [1]? Just to clarify where the new element should be placed and how it should look like? [1] http://wiki.mozilla.org/Calendar:SMB_Event_Summary
Updated•17 years ago
|
Flags: wanted-calendar0.8? → wanted-calendar0.8+
Assignee | ||
Comment 18•17 years ago
|
||
This is an updated version of the patch which is going to be checked in. > Generally I would appreciate, if we reintroduce the category list. I filed this as spin-off bug 402534. > Regarding the appearance of category boxes we should go with MVL's suggestion. I consolidated the implementation of the different event boxes (all-day, month view & week view) in order to end up with the css-class calendar-event-box-container always denoting the stack that encloses the content of the event boxes. Events with a category also get an attribute 'has-category'. That way we can style event boxes depending on whether or not they have a category assigned. I removed the right border in case an event has a category assigned. > The selection should span over the event & the category Done. > Category type is not displayed in Event Summary dialog Done. > It is not possible to adjust the length of an event by click-drag. This was a regression from bug 288496 and has been fixed by bug 401905. I also tried this patch on mac and it works like a charm. > Category not displayed Done. Carried over r+ & ui-r+.
Attachment #286559 -
Attachment is obsolete: true
Attachment #287419 -
Flags: ui-review+
Attachment #287419 -
Flags: review+
Attachment #286559 -
Flags: ui-review?(christian.jansen)
Assignee | ||
Updated•17 years ago
|
Attachment #286559 -
Flags: ui-review+
Assignee | ||
Comment 19•17 years ago
|
||
patch checked in on trunk and MOZILLA_1_8_BRANCH -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 20•17 years ago
|
||
(In reply to comment #14) > (In reply to comment #12) > > Wouldn't this logic be better placed once in "calendar-decorated-base-view" > > binding instead of using it in several derived bindings? > I think we should move the separate pref-observer implementations to > calendar-decorated-base and override particular bits and pieces in the derived > bindings. I filed bug 402569 in order to address this issue.
Updated•17 years ago
|
Target Milestone: --- → 0.8
Comment 21•17 years ago
|
||
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10pre) Gecko/20071105 Calendar/0.8pre and Lightning 2007110510
Status: RESOLVED → VERIFIED
Comment 22•17 years ago
|
||
The following CSS no longer works in my UserChrome.css: [item-category="Appointment"] { color: red !important; background-color: transparent !important; } Maybe this is because the 'item-category' attribute was removed from calendar-view-core.xml?: - container.setAttribute("item-category", categoriesSelectorList); In any case, is it possible for you to restore the attribute in the code so that I can reference it in my userchrome file, or is there a different solution that I can use? The reason is because 95% of my events are on a single calendar, so it's much more useful for me to color the entire event boxes based on category colors instead of calendar colors.
You need to log in
before you can comment on or make changes to this bug.
Description
•