Open Bug 340025 Opened 14 years ago Updated 10 years ago

sort out context menu architecture for the views

Categories

(Calendar :: Calendar Views, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: jminta, Unassigned)

References

()

Details

(Keywords: uiwanted)

We currently have been implementing context menus in a rather ad-hoc way, partly due to the need to migrate from old views in Sunbird.  Currently, we set a context (and sometimes item-context) attribute on the views, which is read and the forwarded on to the item-boxes that the view creates.  The downside of this is that the views need to be re-drawn when the context element is set.  Right now, this is a problem for extension authors, because it's not easy to force this to happen, given the box-reuse that's going on.  Possible solutions include:
-some magic with xbl inheritence
-specifying the context menus in the xbl
-fun with javascript watch()
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
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 [1]. 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.
>
> [1] 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.
Flags: wanted-calendar0.9?
Flags: wanted-calendar0.9? → wanted-calendar0.9+
Duplicate of this bug: 334133
Duplicate of this bug: 390325
Duplicate of this bug: 402083
No longer blocks: 369934
Flags: wanted-calendar0.9+ → wanted-calendar1.0+
No longer blocks: 409701
Duplicate of this bug: 485448
Duplicate of this bug: 491557
Duplicate of this bug: 452234
You need to log in before you can comment on or make changes to this bug.