Closed Bug 347192 Opened 18 years ago Closed 16 years ago

Entries in agenda should appear in the same way again when starting Lightning again

Categories

(Calendar :: Lightning Only, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: thorsten, Assigned: moz)

References

Details

(Whiteboard: [good first bug])

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1
Build Identifier: Lightning 0.1+ (2006080207)

When I start Thunderbird (with integrated Lightning) the three topics "Today","Tomorrow" and "Soon" are always closed in the agenda at the beginning. So I cannot really see which events I will have in the next time.

I first have to click on the + sign to see my tasks/events.

Would be better if they are shown directly or the way that Lightning stores the information, which entry was opened and which was closed. So it can appear the same way when you restart Lightning.





Reproducible: Always

Steps to Reproduce:
1. Starting Lightning, the three entries Today,Tomorrow and Soon are closed
2. If I want to see my events/tasks, I have to click on the + sign first
3. When I close Lightning and restart it again, I have to do the same again.



Expected Results:  
When I click on all three entries and open it. They should also stay open after restarting Lightning.
Confirmed.  Let's have some fun with document.persist here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Lightning 0.3
Not going to make the 0.3 train.
Target Milestone: Lightning 0.3 → Lightning 0.5
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [good first bug]
Not going to make the 0.5 train.
Target Milestone: Lightning 0.5 → ---
I'd be willing to take this on for my first bug, since it's one of my pet peeves. Embarrassingly enough, I don't know how to assign it to my name.
Assignee: nobody → felixcruxca
Severity: normal → enhancement
Status: NEW → ASSIGNED
(In reply to comment #4)
> I'd be willing to take this on for my first bug, since it's one of my pet
> peeves. Embarrassingly enough, I don't know how to assign it to my name.
> 
You must have done something right, because this bug is currently assigned to you.  :-)  Seriously though, thanks for stepping up.  If you have questions on style you can either check here: http://www.mozilla.org/hacking/mozilla-style-guide.html.  Once you have a patch, attach it and don't forget to ask for review from either myself, Matt, or Joey.  If you have any questions, you can get help in #calendar on IRC.  Have fun!

Berend requested wanted-calendar0.8 on the duplicate bug 409090. -> Carrying over.
No progress on fixing this bug for more than 6 months. -> Assigning to nobody.
Assignee: felixcruxca → nobody
Status: ASSIGNED → NEW
Flags: wanted-calendar0.8?
Flags: wanted-calendar0.8? → wanted-calendar0.8-
I'd really like to see this fixed.
It is really frustrated to see that nobody is solving this problem.

I reported this problem before the release of version 0.3.

It is 1,5 years old now and I think it is really not a big problem.

Aren't customers who want to use the product in real life important for the Mozilla team ???

Many duplicates of my bug have been written by other users.

May I ask the question, if no one of the developers is using the Lightning in their reallife ?  Otherwise they would notice that problem and notice how annoying it is !
Attached patch Proposed patch (obsolete) — Splinter Review
I tried around with document.persist about two hours, but i wasn't successful. Instead, this patch saves the open/closed state of the topics in the config now. By default, only today is open, just like it is now.
Attachment #307819 - Flags: review?(Berend.Cornelius)
Robert, what problems did you have using the 'persist' attribute? Currently the 'checked' attribute of the checkbox is controlled by the value of "period.open" (see "addPeriodListItem()". This logic would have to be changed by making the 'checked' attribute persistent in the XUL file today-pane.xul. widget attributes should not be set by preferences and therefor I am afraid that I have to deny the review. But before you go on with your implementation I would like to hear Christian's opinion if we really want this feature. It would 
1) cost us start-up performance as the events for a period are always  retrieved "on demand" when the according checkbox is checked and 
2) fill up the agenda-listbox with a lot of events making it look unclearly arranged.
On the other hand I agree with you that this is something the user just expects to be.
Comment on attachment 307819 [details] [diff] [review]
Proposed patch

denying review due to my comment.
Attachment #307819 - Flags: review?(Berend.Cornelius) → review-
(In reply to comment #15)
> (From update of attachment 307819 [details] [diff] [review])
> denying review due to my comment.
> 

Berend,
IMO having this feature makes sense, because it is very annoying to reconfigure the state on and on again.
Actually I read that for 'persist', the element needs an id. The 'checked'
attribute however belongs to the agenda-checkbox which doesn't have an id
itself. When I tried to create a 'checked' attribute for the 'today-header' by
using setAttribute() and afterward document.persist(), I found that value isn't
saved correctly in the localstore.rdf (however, I'm new to this, so maybe I've
done something wrong). This might be due to the fact that there are two
elements with that id because the node is copied in addPeriodListItem. When I
changed the id of the copied node and did the same again, the correct value was
saved, but not loaded on the next start (probably because I changed the id
on-the-fly).

Well, I'll try again later. My idea was to create that 'checked' attribute for
the headers as well and connect it to the checkbox with 'xbl:inherits'. Then
the attribute of the header could be persistant, and the 'open' property of the
period could be filled with getAttribute().
Ah yes there could be a problem. I will attach a patch that takes care of the duplicate id (actually I wanted to have this already in https://bugzilla.mozilla.org/show_bug.cgi?id=412739 but it somehow did not make its way). Besides that there will be a problem for you:
Because of an extremely nasty bug in the Gecko -engine I could not hide/unhide the checkboxes within the richlistbox, because by doing so I could no longer travel by keyboard through the richlistbox over the hidden checkbox-richlistItem - the focus would just vanish in that special case. That's why I always had to copy them during runtime from the "richlist-item-container" when I wanted to add them to the richlistbox - have in mind that when the agenda-pane is not in "Today" mode we only display one checkbox, otherwise all three. 
So what you have to do is to take care that the checked attribute is also always set at the original checkboxes contained in "richlist-item-container" (and made persistent there) because they are the only ones that are guaranteed to survive the session whereas their copies that I created in "addPeriodListItem()" are bound to be removed somewhen.
Attached patch patch v. #2Splinter Review
patch that fixes the problem with the duplicate ids. You can incorporate this into your own patch.
(In reply to comment #18)
> So what you have to do is to take care that the checked attribute is also
> always set at the original checkboxes contained in "richlist-item-container"
> (and made persistent there) because they are the only ones that are guaranteed
> to survive the session whereas their copies that I created in
> "addPeriodListItem()" are bound to be removed somewhen.
> 

That's what I did now, and it seems to work fine. The inheritance I thought of first makes no real sense here because the 'checked' attribute has to be copied to the hidden checkbox anyway in onCheckboxChange(). So now I have to integrate your patch, test some more situations and then I can upload a new version.
Attached patch Patch v. 3Splinter Review
I'm sorry for the delay. This is a new attempt, this time making use of 'persist'. It contains Berend's patch.

By the way, when I made the hidden templates visible with DOM Inspector, I recognized that actually the checkbox itself is shared by the template item and the copy. That means that the command to synchronize the attribute of the template with the checkbox wouldn't be necessary, this could be done automatically by adding 'checked' to the list of inherited attributes for the checkbox inside 'agenda-checkbox-richlist-item'. It should work - the reason why it doesn't seems to be that the 'checked' attribute of the checkbox isn't set to 'false' but removed. But ok, it's only that one line, it's probably not worth changing the behavior of the checkboxes for that.
Attachment #307819 - Attachment is obsolete: true
Attachment #307987 - Flags: review?(Berend.Cornelius)
Assignee: nobody → robbie.pes
Status: NEW → ASSIGNED
Comment on attachment 307987 [details] [diff] [review]
Patch v. 3

This patch looks and works great. Thank you.
btw. probably you have some ambitions to take care about 
Bug 409166 – missing crop attribute in agenda checkbox. This also affects the same richlistitems.
Attachment #307987 - Flags: review?(Berend.Cornelius) → review+
I would suggest to take this for 0.8 - if this is a low risk patch.
Agreed, Berend what do you think about it (risk)?
Flags: wanted-calendar0.8- → wanted-calendar0.8+
Yes, I think we can take this. I will check it in
patch checked in on trunk, MOZILLA_1_8_BRANCH and SUNBIRD_0_8_BRANCH.

-> fixed
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 0.8
This still doesn't work for me. I have to change from "Tasks" to "Events and Tasks" every couple of days.
(In reply to comment #27)
That's not targeted in this bug. This bug is about the Agenda only.
You're right, of course. I'll file another bug, as I did not find any other bug related to that issue.
You need to log in before you can comment on or make changes to this bug.