199732 - Events spanning days are seen as multiple events (display)

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Vincent Lefevre]

User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4a) Gecko/20030315
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4a) Gecko/20030315

Events spanning days are seen as multiple events, concerning the display and the
alarm.

Reproducible: Didn't try

Steps to Reproduce:
1. Define an event from 20030328T225500 to 20030329T003500.
Actual Results:  
Two events are displayed in the calendar: one from 20030328T2255 to
20030328T2359 and the other one from 20030329T0000 to 20030329T0035 (see the
full description in the tooltip that pops up). Moreover the time that appears
the second day is 22:55, which is confusing. And I got two alarms: one for
20030328T2255 and one for 20030329T0000.

Expected Results:  
Concerning the display, the event should be from 20030328T2255 to 20030329T0035
(in the tooltips). In multiweek and month views, the event should probably not
appear at all in the second day (at least if the end time is early enough). And
of course, one should get only one alarm (for the start time, not for midnight).

Comment 1

[Mike Potter]

New contact from [e-mail] to [e-mail]
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.

Comment 2

[Ken Tanzer]

Attachment: Screenshot (see 2/5 event from 10pm -> 12:30 am)

There's an event starting 2/5 at 10pm, until 12:30 am.	The event displays on
the second day with the starting time from the first day (i.e., 10pm), which is
misinformation absent an indication it's from a previous day.  At the very
least, it needs to say "-> 12:30 am" or something like that.  Better would be a
way to indicate "10pm (Day 1)".  Just the time without the date is the worst
possibility.

I think this comment is somewhat different than the original bug report (it's a
bug, not an RFE), but similar enough that I thought I'd file it here.  Can file
separately if preferred.

(Thanks for all the effort--it's getting to be a neat program!)

Comment 3

[Wm]

confirmed as still a display bug in multiweek and month views (day and week
views are OK)

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3 +
2004080916-cal

Comment 4

[Bay Grabowski]

*** Bug 286472 has been marked as a duplicate of this bug. ***

Comment 5

[Joey Minta]

*** Bug 289707 has been marked as a duplicate of this bug. ***

Comment 6

[JOel]

Would love to see a modification to handle this bug,  it's the only thing
stopping me from implementing this software

Comment 7

[Joey Minta]

*** Bug 282315 has been marked as a duplicate of this bug. ***

Comment 8

[Barbara K Warren]

(In reply to comment #6)
> Would love to see a modification to handle this bug,  it's the only thing
> stopping me from implementing this software
> 

It would be nice to have one event spanning several days in month or other
views, or at laast to allow the time for the first day to be a partial time, the
intermediate days to indicate that the event was all day, and the last day to
again indicate a time span of 0000-end of event.  A workaround is to enter the
event three times, for the start date (start time till midnight), intermediate
days(as all day events) and end date (0000-end time).

Comment 9

[Simon Paquet [:sipaq]]

*** Bug 262943 has been marked as a duplicate of this bug. ***

Comment 10

[Joey Minta]

*** Bug 309880 has been marked as a duplicate of this bug. ***

Comment 11

[Chad]

Multi day events should stretch acros the days on the calendar instead of
showing an event on each day. It would also be nice to be able to display
different text on each day of the multi day event. I am a pilot, and I would
like to be able to show the start time of my trip, the time I get home (4 days
later) and the city I will be sleeping in on the appropriate day.

Comment 12

[Simon Paquet [:sipaq]]

*** Bug 312710 has been marked as a duplicate of this bug. ***

Comment 13

[Patrik Arlid]

I have a similar problem, but only when I'm creating an event that lasts later than 23:00, of the last day of the week (in my case a sunday). In this case the event shows on the day after (monday), but only half the widht.

Comment 14

[Joey Minta]

*** Bug 315848 has been marked as a duplicate of this bug. ***

Comment 15

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 16

[Joey Minta]

The alarm part of this is fixed.

Comment 17

[Omar Bajraszewski]

I use Sony Ericsson mobile phone and it has a very good solution.For example there's an event and it starts on 2nd of Sep at 4pm and ends on 3rd of Sep at 10am. It is shown on 2/09:

16:00->
'Event'


And on 3/09:

->10:00
'Event'

And I think it's the best idea.
BTW does the bug depend on bug 256588?
And for me this bug blocks 0,3 because events are not displayed correctly...

Comment 18

[Philipp Kewisch [:Fallen][📱📆]]

*** Bug 359404 has been marked as a duplicate of this bug. ***

Comment 19

[Markus Adrario [:Taraman]]

As a simple solution I would suggest to set the start time to "00:00" for the following days.

In calendar-month-view.xml line 78 you would have to insert something like this:

if( [actual_day].date.day > val.startDate.day || [actual_day].date.month > val.startDate.month) {
  str = "00:00";
}

unfortunately I am having trouble finding [actual_day],
beacuse the occurence does not seem to have a parentBox you can access and I didn't manage to understand the code well enough to find another way.

Maybe anyone can give me a hint on this...

Comment 20

[Markus Adrario [:Taraman]]

Attachment: patch to calendar-month-view.xml

Comment 21

[Markus Adrario [:Taraman]]

The created patch proposes a fix to the issue.
On consecutive days of an event it shows 00:00 or 12:00 AM as start time.
This seems the most practical value for the month view, because an end time or else would overload the little fields.

Comment 22

[Matthew (lilmatt) Willis]

Please attach a screenshot of your proposed fix.

Comment 23

[Markus Adrario [:Taraman]]

Attachment: The requested screenshot

Comment 24

[Joey Minta]

Comment on attachment 253694 [details] [diff] [review]
patch to calendar-month-view.xml

Some quick comments:

Most importantly, you need to ask for review from a specific person, to avoid this patch slipping through the cracks.  Matt or I would be reasonable choices here (although my schedule is rather full).

2.) You can probably get access to .parentBox to be available by switching the order of the .occurrence and .parentBox calls, just prior to where you transfered code.

3.) Be careful to fix indenting levels when moving code.

Comment 25

[Martin Schröder [:mschroeder]]

Maybe an image, e.g. an arrow from left to right, is more suitable than showing "0:00". It additionally shows that the event is continued from the day before.

Comment 26

[Markus Adrario [:Taraman]]

Attachment: fixed indentation in the patch

OK, hope now I got it right :-)
indentation is fixed and review requested.

Comment 27

[Matthew (lilmatt) Willis]

Comment on attachment 253760 [details] [diff] [review]
fixed indentation in the patch

Removing review request until this makes it through ui-r

Comment 28

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

I agree with martin, that you don't want to show "0:00" for a continued event, but show an arrow or something. Maybe just "..."

Comment 29

[Markus Adrario [:Taraman]]

OK, how about changing it to "-->" or "->" to keep it a simple text message?
Wuld take about a half line change in the patch...

Comment 30

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

Those hacks with text strings mimicing an image makes me not happy. They tend to never get fixed into real images. For proof, look at the '*' indicating an all-day event. So i'm not too keen on letting this in now. And drawing an image of an arrow should not be that hard :)

Comment 31

[Joey Minta]

What about showing the date the event started on?

Comment 32

[Markus Adrario [:Taraman]]

Nice ideas.
Drawing an arrow would be no problem, but putting it in the text-label ist beyond my prgramming skill (sorry).
Maybe we should make the string configurable, because everyone seems to want something else.

Comment 33

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

No, it should not be configurable. We are just creating ideas, not telling about personal preferences.
Showing the date makes sense to me.

Comment 34

[Stefan Sitter [:ssitter]]

(In reply to comment #30)
> For proof, look at the '*' indicating an all-day event.

'*' is used for tasks not events. But I know what you mean, the bug for adding special style for all day event is still open...

(In reply to comment #33)
> Showing the date makes sense to me.

I disagree here. Showing the date makes no sense for me, except that it eats valuable screen space. If I want to know the date the event takes places I can look at the view header. If I want to know what date the events starts/ends on I can look at the tooltip, unifinder, agenda or open the event dialog.
I think it would be better to just mark the event as continuing, e.g. by prefixing '>>'

Comment 35

[Markus Adrario [:Taraman]]

Attachment: suggestion for adding pictures

I had some time today and looked at the solution with pictures again and found a way to do it.
It basically adds an image to the day-item-box whichs src-property is changed in the code. If not needed, it is hidden to schow the starting time as text.
I failed in changing the pictures via stylesheets, so the src-property is set directly to the skin-directory.

This also adds the picture to the ToDos.
The pictures may need some work, because I'm not much of an artist.

Comment 36

[Matthew (lilmatt) Willis]

I'm wondering if there's an arrow already defined in Unicode that we could use for this so we don't need to have extra graphics.

Comment 37

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

This patch conflicts with the patch in bug 368982. I suggest waiting for that bug to land, because the patch here is easier to update for bitrot.

Comment 38

[Robert Harvey]

Attachment: multi-day event not contguous on display

I agree that multi-day events need to be aligned on adjacent days - This screen grab shows it going wrong.

I also agree with the suggestion that multi-day events should be able to start and end at arbitrary times.

if bug266249 were adressed to give offset co-ordinates within a day box, then it might make fixing this one easier

Comment 39

[Robert Harvey]

Attachment: same ical files displayed by google calendar

By way of example, here are the same ical files in google calendar, displayed as I would expect

Comment 40

[Pete Riley]

Very nice, Robert.  I much prefer Google's appearance that has a single, solid horizontal bar and the event title only listed once (and no arrows).  It's similar to the screenshot in bug 256588, except that Google puts the event title on the first day instead of on the middle day.

To keep each day of the multiday event on the same horizontal row (without the current zig-zag effect that you mentioned), I think that multiday events should always be listed before any other types of events/tasks.

To handle the situation where two or more multiday events overlap the same days, I suggest that the event title could always be repeated for each week, like this:

         Sunday Monday Tuesday Wednesday Thursday Friday Saturday
Week X:                        [Event 1  -----------------------]
                                                  [Event 2 -----]
Week Y: [Event 1 ------------]
        [Event 2 ----------------------]

This would make it easier to distinguish between the two events in the second week, especially if they both use the same color.

Comment 41

[Michael Benson]

When creating a multi day event each day as a separate event, it would make more sense to have the Label "span" across the days affected by the event with one label. Putting the start time at the beginning and the end time at the end of the label.  The current method works but is not ideal and makes the calender more congested looking

Comment 42

[Matthew (lilmatt) Willis]

Just so folks know why this issue continues to languish:
I this we all agree that having something similar to the above suggeston, the Google Calender screenshot, or what iCal.app does would be optimal. (One box across all the days)

Unfortunately since each event box is a child of the day box it resides in, it's a lot more complicated for us to implement that might be immediately apparent.

Comment 43

[Markus Adrario [:Taraman]]

Attachment: proposed new look

After the visual enhabcements from Bug 368982 have landed, I started working on this again...

Comment 44

[Markus Adrario [:Taraman]]

Attachment: pictures for the TODO's in month-view

these go in /m/c/base/themes/common

Comment 45

[Markus Adrario [:Taraman]]

Attachment: patch V3

- As suggested by lilmatt in #36 I searched and found an unicode arrow. I decided to stick with arrows, because I think it's a good way to tell it is continuing. As pointed out in #42 the box over multiple days is complicated, so this seems to me the best solution for the moment.
I tried to sort the multiday events, so they are aligned in neighboring boxes. But you can't just leave the first space empty in a box in the current architecture. Also the nature of the sorting function for arrays in java makes it mor than difficult to sort an item to the same position as on the day before.
Something that gets close to the alignment is to sort the multiday items before everything else. Because not long ago the All-Day Items got sorted to the top, I didn't want to change that again.

- since the missing picture for ToDo's was addressed by Michiel in #30 I added these. I hope I got the patch for that right since it was my first Time adding binary files in CVS. I set different pictures for open & completed so you can see the status in the month view.

Enjoy!

Comment 46

[Joey Minta]

Comment on attachment 260925 [details] [diff] [review]
patch V3

-          label.value = str;
+          // transferred the code for the start-time display to "calendar-month-day-box"
+          // .relayout() because for some reason "parentBox" was not accessible from 
+          // this place and this is needed to recognize item-boxes, which have a start 
+          // date in another day-box.

Don't do that.

               box.occurrence = itd.item;
               box.parentBox = this;
               itd.box = box;
+
+              <!-- transferred this code from "calendar-month-day-box-item".occurence.setter -->
+              <!-- because the date of the day-box was not accessible from there -->

The lines in the context show you why parentBox wasn't accessible, because it isn't assigned until after occurrence is assigned.  Also, don't include comments about moving code generally.  CVS blame is good enough for that.

Comment 47

[Simon Paquet [:sipaq]]

Comment on attachment 260925 [details] [diff] [review]
patch V3

Only one review is needed now. Moving UI review over to our 2nd UI reviewer, Christian, since mvl's queue is already pretty long.

Comment 48

[Simon Paquet [:sipaq]]

Comment on attachment 253760 [details] [diff] [review]
fixed indentation in the patch

With the v3 patch, this patch is now obsolete.

Comment 49

[Joey Minta]

Comment on attachment 260925 [details] [diff] [review]
patch V3

+                <!-- this line sets the starttime to midnight if the event begins the day before -->
+                if (val.startDate.day < this.date.day) { 
+                str = "\u21DB";
+                }
Use javascript style comments within methods.  Also, this seems like it will give you weird results if a multiday-event spans the start of a month.

+              if (str == "*") {
+                if (val.isCompleted)
+                  icon.setAttribute("type", "todo-completed");
+                else
+                  icon.setAttribute("type", "todo");
+
+                icon.hidden = false;
+                label.value = "";
+              } else {
+                icon.hidden = true;
+                label.value = str;
If we're never going to use the "*" we should re-factor the code so it never gets assigned.

I don't think I'm going to be able to pick out much more useful stuff until these (and the above) changes get in and I can see how the code looks then.

Looking forward to a new patch. :-)

Comment 50

[Markus Adrario [:Taraman]]

Attachment: patch V4

Comment 51

[Markus Adrario [:Taraman]]

Attachment: patch V4

OK, codemoving comments are gone.
joey, you are right about the event spanning a month. I was thinking of making a .isMultiday method for the event-class since I was working on a sort function for these and would have needed it. So I just put that line here in for simplification and forgot about it. :-(
The "*" is removed.

Comment 52

[Joey Minta]

Comment on attachment 261063 [details] [diff] [review]
patch V4

This version still doesn't address the comment I made about a way to not move the code (namely by inverting the parent-box and occurrence setters).

+                // this line sets an arrow instead of the starttime if the event begins the day before
+                if (val.startDate.day   < this.date.day ||
+                    val.startDate.month < this.date.month ||
+                    val.startDate.year  < this.date.year) { 

You want calIDateTime::compare here.

+                str = "\u21DB";
+                icon.hidden = true;
+                label.value = str;
+                }
The indenting here is squirrelly. 

+              var str = null;
+
I'm going to recommend that we initialize str to be "", so we can keep the single label.value = str; line after the if/else block.

Comment 53

[Martin Schröder [:mschroeder]]

Comment on attachment 261062 [details] [diff] [review]
patch V4

Patch was attached twice.

Comment 54

[Christian Jansen]

Markus, thanks for the patch.
I support the idea of using arrows for events which span over more than one box.

Please find my comments below:

1. The readability of the arrow should be improved.
   (I can create you a set of arrow images, if needed)
	
2. Position of the arrows:
I think it would be better to display the arrows left or right aligned.

3. The arrow should indicate direction where the event continuous.
   For Example:

        Monday    |  Tuesday
   ----------------------
   01am	          | <- Event 1
   11pm Event 1 ->| 

4. An arrow should perform as a link.
Clicking the arrow, in the first part of an event should move the view to the second part of the event. 

   For Example (Week View):

        Sunday     |  Monday
   ----------------------
   01am            |  <- Event 1
   11pm	Event 1 -> |

   In this case the next week should be displayed.

Comment 55

[Christian Jansen]

Some general thought. Just for inspiration right now.
Feel free to discuss in the mailing list.

Comment 56

[Christian Jansen]

Some general thought. Just for inspiration right now.
Feel free to discuss in the mailing list.

http://wiki.mozilla.org/Calendar:Crossing_Day_Boundaries

Comment 58

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 261063 [details] [diff] [review]
patch V4

Cancelling review since ui-review was denied. Feel free to rerequest when you have ui-review approval.

Comment 59

[Markus Adrario [:Taraman]]

To me having multiday events span over multiple days in month-view would be the best. Since this takes major work on the code, I return the assignment to nobody, because this needs mor time than I have.

An intermediate approach could be to reduce the left/right margins of multiday events to zero and implement a way to get them in the same line in each box.

Looking forward on progress on this one.

Comment 61

[Simon Paquet [:sipaq]]

It would be good to have this in 0.7.

Comment 63

[Daniel Boelzle [:dbo]]

nice to have => 0.7?

Comment 64

[Robert Harvey]

Attachment: Showing suggested variable start and end position for multi-day event

OK - old stuff, I know, but I have been entering my recent sicknote and got reminded of it.

Comment 2 raises the problem of where multi-day bars ought to start and end.  I have mocked up another prototype, based on the google graphics I am afraid, showing the variable start and end time.  Also showing My preferred way to handle the times.

I have read all the stuff about how box objects are descendents of the day boundary, but perhaps a transparent box object could be drawn within the day (to push the single events down and make room) and then the multi-day event drawing over the top?

Really I am bored witless because I have been off work.  I am very grateful for the Sunbird product, which has nearly booted Rainlendar off my desktop, despite the early versioning.

Comment 65

[Markus Adrario [:Taraman]]

hmm. thought I canceled my assignment on this one.
well, trying again...

Comment 66

[Michal Gore]

I got something like this: 
I setup from 1.11.2007 to 1.01.2008 one event
for "full day"
and its only in mondays so it one day a week
but when i setup it for ONLY mondays i get somthing like this:

week 1: all days got that event
week 2: all days got double of that events
week 3: all days got tripple of that events
week 4: all days got 4 of that events ...

Comment 67

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

helping to mass reassign from requesting blocking‑calendar0.7 to wanted‑calendar0.8.

Comment 68

[Karen Pomerantz]

Don't know if this has been mentioned elsewhere, or if it's totally relevant to this particular bug.. but anyway.
An option to specify what time a day ends (rather than always being midnight) would be nice for me.
Like a lot of people, I think of a day as ending when I go to sleep, not always midnight.
So if I put in an event, say a night out on the town, from 8:30pm Friday night, until 2am Saturday morning... I would love to have it display JUST in the Friday box, as an event from 20:30-02:30, rather than an even ton friday until midnight, and another on saturday from midnight until 2am.
When I get up saturday and look at the calendar for the day, it's really annoying to see the first 'appointment' as being my night out the previous night!

I know it sounds odd wanting your day to start a few hours after midnight, but it really would be very practical!
If I could set my 'borderline' between days to be 3 or 4am rather than midnight, then anytime I am busy slightly past midnight, I wouldn't have to falsely set my event to end at 23:59 instead!

Feel free to point me in the direction of another bug if this idea is already being looked at.

Comment 69

[Simon Paquet [:sipaq]]

Setting wanted0.8- as the main Calendar developers will not devote any time to
this in the 0.8 timeframe. Patches are, of course, always welcome.

Comment 70

[Markus Adrario [:Taraman]]

Since implementing something like in google-calendar is major work as outlined in comment 42, how about an intermediate solution on the basis of comment 54?
Since I find the current state annoying I think this would be better than to wait for a complex final solution.
I could start working on that then.

Maybe this could extend to the ideas laid down in the link in comment 56.
What do the UI-guys think of this?

Comment 71

[Steffen Röttig]

For the next release....

Please take a look to the votes.
Many Peaople are waiting for this.
And I think also. This is very important.

Comment 72

[Dietmar Kunz]

Attachment: proposed update for calendar/base/content/calendar-month-view.xml

I implemented that in the case that an event (e.g."holiday") extends over several days, the first day (08/03/24) shows "|>18:00 holiday" indicating the start time, the intermediate days show "<-> holiday" and the last shows ">| 14:00 holiday" indicating the end time. In case the event ends at midnight, the program only shows the end sign ">|" without end time since an end time of 0:00 would be misleading and 24:00 is not international.
I have drawn the complete source from cvs four days ago, built sunbird from source and tested the change on it. Before, I made a parallel implementation on the standard 0.7 release.

Comment 73

[Dietmar Kunz]

I submitted a solution which solves just the basic problem.
Maybe it's not the ultimate solution in terms of visual attractiveness but in my view it's better than the current state and the code changes are very restricted.

Comment 74

[Martin Schröder [:mschroeder]]

(In reply to comment #73)
> I submitted a solution which solves just the basic problem.

Dietmar, can you provide a patch created with "cvs diff -u8p > multievent.patch" against the CVS? It is easier to see the changes in a diff file. If you need help, you can also send me an email.

Comment 75

[Dietmar Kunz]

Attachment: The cvs diff for comment #72,73

Martin, attached I provide the diff you asked for (comment #74).
Only the first two differing sections are real, the rest was just the result of some automatc change of indentation. The first differerence section contains the real stuff, the second section is just the exchange of two statements. This is needed because box.parentBox must be set before box.occurence since the occurence setter needs the parentBox to access the start and end time.

Comment 76

[Pete Riley]

I'm glad that you're working on this, Dietmar.

One alternative to this:

|<18:00 holiday     <-> holiday     >|14:00 holiday

is this:

18:00> holiday     <-> holiday     <14:00 holiday

Of course this is just a suggestion.

Comment 77

[Dietmar Kunz]

(In reply to comment #76)

Pete's suggestion saves one character for the event text. Which of the two versions is clearer to the user may be judged by others. Implementing Pete's idea requires only a very minor code modification. I can provide this modification if needed.
By the way: If Pete's version is preferred, what should be shown if the event ends at midnight?

Comment 78

[Berend Cornelius]

Comment on attachment 312471 [details] [diff] [review]
The cvs diff for comment #72,73

On the first glance your patch looks good and works as promoted. I noticed  that it  corrupted some alignments , especially in "getDateList()" and other places, too. Please correct this.
But before I go on I think that this issue still needs a ui review that I will set to Christian if you don't mind. As I see there are currently two concepts, one proposed by Christian in comment #54 and Pete's comment #76 that you followed in this patch.

Comment 79

[Dietmar Kunz]

(In reply to comment #78)

One point concerning Christian's comment #54: If the arrow is on the right-hand side of the event text it may not be visible if the event text is longer than just a few characters. Right allignment is no solution for that since for right allignement the time won't be visible. Moreover, the functionality of the arrow is not clear to me if the event spans over more than two days.

One question to Berend: Do you want me to do something on the corrupted allignments or should I just wait?

Comment 80

[Berend Cornelius]

No, I am not insisting. We can wait for Christian's feedback just as well.

Comment 81

[Simon Paquet [:sipaq]]

[e-mail], please do not use the '+' switch on flags. Those are reserved for release drivers.

Comment 82

[Christian Jansen]

Sorry for my late response:

As far as I see the arrows are only visible in the Month view. It would be good to display the arrows in all five views Day, Week, Multi Week, Month and Today Pane.
Please replace the symbols by icons.

Comment 83

[Christian Jansen]

Comment on attachment 312471 [details] [diff] [review]
The cvs diff for comment #72,73

I'll minus this bug, due to the inconsistencies mentioned in comment #82. Please consolidate. If more convenient, the icons can be added by with a follow-up bug.

Comment 84

[Dietmar Kunz]

(In reply to comment #82)
Christian, sorry for my late response, too.
I do not understand your point. The problems arise only in month and multi-week view. Since both views are generated by the same source code, my fix solves the problem in both views. Of course, it would be nicer to have an icon instead of the arrows but from the user's point of view it would be better to have a reasonable solution now than to have an nice solution later. Therefore I would like to postpone the implementation of the icons.

Comment 85

[Berend Cornelius]

Dietmar, your patch is quite bitrotten meanwhile. Could you bring it up-to-date?
It's been quite a while ago when I was looking at the patch but I am wondering too why we should not provide this feature in the (multi)day(s) views.

Comment 86

[Dietmar Kunz]

Attachment: Diff for calendar-month-view.xml

Enclosed, the diff file for the proposed solution with respect to the current cvs.   The patch is relevant for month and multweek view. For the other views, the problem does not exist since the current presentation in o.k.

Comment 87

[Dietmar Kunz]

Attachment: source code for proposed patch

Comment 88

[Bas van den Bosch]

(In reply to comment #86)
 The patch is relevant for month and multweek view. For the other views,
> the problem does not exist since the current presentation in o.k.

So this means it only works for non-allday items? Nevertheless, imho we should take this patch (presuming it works) and fiole follow-upos for weekview and perhaps even dayview. 

Comment 89

[Dietmar Kunz]

(In reply to comment #88)

> So this means it only works for non-allday items? Nevertheless, imho we should
> take this patch (presuming it works) and fiole follow-upos for weekview and
> perhaps even dayview. 
> 
I'm affraid, I don't get your point. The problem arises only if event starts e.g. at 10:00 at one day and ends at say 11:00 two days later. Currently, the event is shown in multiweek and month view as if the event started each of the three days at 10:00. Now, it shows |< 10:00 the first day, <-> the second day, and >| 11:00 the third day. For all-day events, the current version shows just the event name without time which is perfectly o.k. In the above example, the day and week view shows the event as a time bar ranging the first day from 10:00 to midnight, the second day from midnight to midnight, and the third day from midnight to 11:00, which is o.k. as well. So, where do we need changes in day or week view?

Comment 90

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 331925 [details] [diff] [review]
Diff for calendar-month-view.xml

Instead of using the character combinations you proposed, I'd suggest to use unicode arrows until we have icons:

↤ ⇤ ⇥ ↔

They might seem a bit small, but in the application it looks fine to me. Also I'd leave a space between the arrow and the time.

Codewise, you should check out our style guide. The code itself is fine, but there are some minor nits regarding spaces.

Also, I'm unsure why you changed the order of setting box.occurrence. Could you elaborate?

r=philipp, I'll upload my review comments as a patch in a minute.

Comment 91

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 331926 [details] [diff] [review]
source code for proposed patch

We don't need more than patches in mozilla land :-)

Comment 92

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Diff for Month View - v2

Comment 93

[Philipp Kewisch [:Fallen][📱📆]]

Since this bug has had way too much traffic to be readable, I'm closing it in favor of followup bugs.

Markus, please be so kind and attach your patches to a new bug, if they are still relevant.

Bug 449908 filed to replace the arrows with images and to implement this for multiday views.

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 94

[Markus Adrario [:Taraman]]

As this patch pretty much finishes the work I started and my patches are not that much different from the one that is checked in now, there is no need to have them attached to a new bug.
The should also be pretty much bitrotten by the time... ;-)

Thx to Dietmar and Philipp to finally get this thing fixed.

Comment 95

[Dietmar Kunz]

(In reply to comment #90)
> Also, I'm unsure why you changed the order of setting box.occurrence. Could you
> elaborate?
The main changes are in the setter routine for the property "occurrence". This code is called when the property "occurrence" is set. It takes the event end date/time from the parent box. Therefore, the parent box must contain valid data when occurrence is set which implies that the parent box must be set before the occurrence setter is invoked.

Comment 96

[Baldvin Kovács]

What's the status of this? I am using Lightning 1.4, and multiday events appear simply as many one-day events. Pretty lame, compared to google calendar view... My understanding is that at least _some_ solution has been given, even if just a basic one, however, I don't find any signs of it in either mode (day, month, multiweek). Was this code created against some other branch of the mozilla calendars, after lightning was forked? Or lightning was reimplemented from scratch, and all the bugs and issues are repeated? :)

Comment 97

[Martin Schröder [:mschroeder]]

(In reply to Baldvin Kovács from comment #96)
You can see different types of arrows in front of the event's title, signaling the first or last day of the multiple day spanning event. But events have still their own event box every day in the calendar view.

The status of this is FIXED as the fields of this ticket suggest (since 2008). Further improvements are possible in future releases (and new bug tickets).

Comment 98

[Ryan Rubley]

I'm not really sure how this is fixed. Events spanning multiple days are still clearly displayed in the UI as a separate box for each day. That's basically the exact title of this bug.
The arrows that appear if the event has a start/end time aren't used for all-day events. The event title is redisplayed every single day, and when other events on single days get in the way, your multi-day event boxes stair-step around it in the view.

Comment 99

[Dietmar Kunz]

Just to keep in mind what the bug was about: If you have got an event e.g. spanning the time from Monday 10:00 to Friday 12:00, then this was displayed as if it were an event taking place each day from Monday through Friday from 10:00 to 12:00. After bug fix the event starts correctly Monday at 10:00, covers the entire Tuesday through Thursday and ends on Friday at 12:00. The arrows indicate start end end end time for the start and end days.

Comment 100

[Ryan Rubley]

So this bug was not actually that events were seen as multiple events, just that the start-time was labeled multiple times on each day? To me (who never really uses start/end times, everything is an all-day event), as long as there are multiple boxes and multiple text description labels, it is "seen as multiple events" still.

A new event Monday 10:00 to Friday 12:00 should not say "<-- 10:00 New Event" "<--> New Event" "<--> New Event" "<--> New Event" "--> 12:00 New Event", it should be fixed to at the very least say "<-- 10:00 New Event" "<-->" "<-->" "<-->" "--> 12:00" but realistically, the boxes should just visually be connected to give the appearance of one single long box.

It should be fairly trivial to only list the text label on the first box of the week (for events spanning multiple weeks), and probably pretty easy to change the graphics to make them appear to connect to the next day. The tricky part is keeping each day's box on the same row, because that probably means setting up some sort of reserved-row system all other events need to respect.

Comment 101

[Decathlon]

(In reply to Ryan Rubley from comment #100)
> So this bug was not actually that events were seen as multiple events, just
> that the start-time was labeled multiple times on each day?

I think yes. Despite the title, this bug fixes most of the requests in comment 0 and should be considered as fixed. For others request there are others bugs.

> To me (who never really uses start/end times, everything is an all-day event), as long as
> there are multiple boxes and multiple text description labels, it is "seen
> as multiple events" still.

The equivalent of this bug for all day events should be bug 449908, despite the title (see bug 449908 comment 1).

> A new event Monday 10:00 to Friday 12:00 should not say "<-- 10:00 New
> Event" "<--> New Event" "<--> New Event" "<--> New Event" "--> 12:00 New
> Event", it should be fixed to at the very least say "<-- 10:00 New Event"
> "<-->" "<-->" "<-->" "--> 12:00"

About that I didn't find an equivalent request but I think there is one. If you won't find it, maybe you can open a new bug.

> but realistically, the boxes should just
> visually be connected to give the appearance of one single long box.

This is covered by Bug 256588 and is not so easy to fix in a complete and simple way.