Open Bug 340025 Opened 15 years ago Updated 11 years ago
sort out context menu architecture for the views
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
We need some UI decision as to which items should belong into the context menu. This should also depend on unifying the calendar sets, which would mean that we can also unify the context menus.
Component: Internal Components → Calendar Views
Depends on: 390508
QA Contact: base → views
Hardware: PC → All
A good staring point could be: http://wiki.mozilla.org/Calendar:Mail_View_Integration#Event_List_Box & http://wiki.mozilla.org/Calendar:Mail_View_Integration#Task_Tree
It would also be nice for events/tasks to have a "Copy to calendar >" menu item in the context menus (bug 390325).
Hi. I'd like to mention an accesskey problem in the Lightning calendar view context menu, happening in 0.7RC2: the item "Novo evento..." ("New event...") has accesskey "I", despite the calendar.dtd entities point otherwise: 189 <!ENTITY calendar.context.newevent.label "Novo evento…"> 190 <!ENTITY calendar.context.newevent.accesskey "N"> http://mxr.mozilla.org/l10n-mozilla1.8/source/pt-BR/calendar/chrome/calendar/calendar.dtd#189 (Or it should be menuOverlay.dtd, but I found no accesskey for this item there) Thanks
Also, the Lightning context menu item "Go to today", in Lightning pt-BR, has an accesskey different from what is defined in calendar.dtd: http://mxr.mozilla.org/l10n-mozilla1.8/source/pt-BR/calendar/chrome/calendar/calendar.dtd#213 213 <!ENTITY calendar.context.gototoday.label "Ir para hoje"> 214 <!ENTITY calendar.context.button.label "Painel hoje" > 215 <!ENTITY calendar.context.gototoday.accesskey "h"> Despite the accesskey is defined as "h", the actual accesskey shows as "T", what is in fact defined in the en-US version: http://mxr.mozilla.org/mozilla1.8/source/calendar/locales/en-US/chrome/calendar/calendar.dtd#212 212 <!ENTITY calendar.context.gototoday.label "Go to Today"> 213 <!ENTITY calendar.context.button.label "Today Pane" > 214 <!ENTITY calendar.context.gototoday.accesskey "T"> That is, for some exoteric reason, Lightning is using the en-US accesskey in the pt-BR version. Regards
(In reply to bug 374464 comment 6) Stephan Sitter wrote: > I'd say comments about the entire context menu rework should be > posted to the corresponding Bug 340025. If would delete that post if I could. Christian Jansen wrote: > I've made no decision, but I've created proposal . I think > this is a good base for a general discussion on how we want to > structure the context menus. As always feedback and comments > are welcome. > >  http://wiki.mozilla.org/Calendar:Context_Menu_Specification I'm happy to offer my opinions. :) 1) Overall, very nice. I like the proposed ability to send emails to the organizer/attendees. 2) Perhaps it's a little too complicated? I think that "Make Standard Event" and "Make Allday Event" could be removed. Besides, if I right click on an allday event and click "Make Standard Event", how am I going to enter the Start and End times unless I open the event dialog? So I might as well open the event dialog in the first place. So I don't think that the context menu should distinguish between allday events and standard events. 3) I do think that it's a good idea to distinguish between recurring and non-recurring items. What does "Stop Recurrence" mean, delete all future occurrences? Maybe it should say "Delete future occurrences". Then there should probably also be "Delete this occurrence" and "Delete all occurrences". I know that that would be messy but I think that if there will be one of the special cases, then there should be all three. Perhaps the context menu could just say "Delete" and then (for recurring items) a menu opens with the three special cases. That would look nicer but it would be slower for the user to make a choice. 4) Of course the "Edit" menu item is very similar to the "Delete" item in (3). 5) Note that tasks can recur too. I don't think that the chart indicates this. 6) I think that the "Private" menu item is unnecessary. It seems to me that this is something that I set only once, when I create the event, and would never need to change the privacy state (under normal circumstances). Anyway, if you keep this, I think that there are three choices (Public / Time & Date Only / Private). 7) Regarding the "Status" of the item (Tentative/Confirmed/Cancelled), this is not in your chart. I admit that I've never used this Status feature in any calendar program, but if the user has to manually set this status for events, perhaps there should be a way to do it in the context menu? Does only the meeting organizer set this status? If so then maybe the Status menu item could appear only if the user is the organizer of the event that he right clicked. That would be a very context-sensitive menu. :) 8) There's the "Calendar" item (with example subitems: Private, Work, etc.). I assume that this will allow us to copy the item to other calendars. I'm very happy to have this feature. Regarding the name of the menu item ("Calendar"), Thunderbird has two menu items: "Copy to >" and "Move to >". Perhaps Lightning/Sunbird could 'steal' this idea. I think that when the user hovers the mouse over "Copy to >" and the submenu opens, that it will be obvious to the user that this is his list of calendars. In addition to the ability to copy items among calendars, I think that it would also be useful to move items. 9) "Duplicate". I would use this (especially if it preserved more information than using Ctrl-C/Ctrl-V). I'm thinking that this would not have to be a separate menu item if it could be integrated into the "Copy to" menu (and to duplicate the item, we would copy it to the same calendar name). The hard part, perhaps, is how do you indicate in the Copy To submenu the item's original calendar? 10) I'm wondering if there should be a way in the context menu of an event to create a task based on the event (and vice versa). Also, there could be a way to compose a new email (based on the event/task) that can be sent to anyone (for events that are not meetings and thus don't have a list of attendees). I'm not sure if I would ever use these features, but I just wanted to mention this. Maybe this is for a future bug.
I'm not sure "Duplicate" is very intuitive. Assuming that would be the "Copy" part, what would you do for "Paste". Normal Copy/Paste would be something everyone gets at once.
You need to log in before you can comment on or make changes to this bug.