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)
Calendar
Lightning Only
Tracking
(Not tracked)
RESOLVED
FIXED
0.8
People
(Reporter: thorsten, Assigned: moz)
References
Details
(Whiteboard: [good first bug])
Attachments
(2 files, 1 obsolete file)
3.14 KB,
patch
|
Details | Diff | Splinter Review | |
5.38 KB,
patch
|
berend.cornelius09
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•18 years ago
|
||
Confirmed. Let's have some fun with document.persist here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•18 years ago
|
Target Milestone: --- → Lightning 0.3
Comment 2•18 years ago
|
||
Not going to make the 0.3 train.
Target Milestone: Lightning 0.3 → Lightning 0.5
Updated•18 years ago
|
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [good first bug]
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.
Updated•17 years ago
|
Assignee: nobody → felixcruxca
(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!
Comment 10•17 years ago
|
||
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?
Updated•16 years ago
|
Flags: wanted-calendar0.8? → wanted-calendar0.8-
Comment 11•16 years ago
|
||
I'd really like to see this fixed.
Reporter | ||
Comment 12•16 years ago
|
||
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 !
Assignee | ||
Comment 13•16 years ago
|
||
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)
Comment 14•16 years ago
|
||
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 15•16 years ago
|
||
Comment on attachment 307819 [details] [diff] [review] Proposed patch denying review due to my comment.
Attachment #307819 -
Flags: review?(Berend.Cornelius) → review-
Comment 16•16 years ago
|
||
(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.
Assignee | ||
Comment 17•16 years ago
|
||
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().
Comment 18•16 years ago
|
||
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.
Comment 19•16 years ago
|
||
patch that fixes the problem with the duplicate ids. You can incorporate this into your own patch.
Assignee | ||
Comment 20•16 years ago
|
||
(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.
Assignee | ||
Comment 21•16 years ago
|
||
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)
Updated•16 years ago
|
Assignee: nobody → robbie.pes
Comment 22•16 years ago
|
||
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+
Comment 23•16 years ago
|
||
I would suggest to take this for 0.8 - if this is a low risk patch.
Comment 24•16 years ago
|
||
Agreed, Berend what do you think about it (risk)?
Flags: wanted-calendar0.8- → wanted-calendar0.8+
Comment 25•16 years ago
|
||
Yes, I think we can take this. I will check it in
Updated•16 years ago
|
Keywords: checkin-needed
Comment 26•16 years ago
|
||
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
Comment 27•16 years ago
|
||
This still doesn't work for me. I have to change from "Tasks" to "Events and Tasks" every couple of days.
Comment 28•16 years ago
|
||
(In reply to comment #27) That's not targeted in this bug. This bug is about the Agenda only.
Comment 29•16 years ago
|
||
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.
Description
•