Closed
Bug 37922
Opened 25 years ago
Closed 2 years ago
Address book Buttons should be context dependent
Categories
(Thunderbird :: Address Book, defect)
Thunderbird
Address Book
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: bugzilla, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: helpwanted, polish)
Attachments
(1 file)
24.88 KB,
patch
|
standard8
:
review-
|
Details | Diff | Splinter Review |
The buttons in the toolbar of the addressbook should be context dependend. Meaning that: the "New Msg" should only be avaiable when you highlight a entry. the "Edit" should only be avaiable when you highlight a entry.
I think nbaca's working on this (checking) for menus as well.
QA Contact: lchiang → nbaca
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Comment 2•25 years ago
|
||
nbaca is this a dup?
Comment 3•25 years ago
|
||
moving to future milestone.
Updated•24 years ago
|
Target Milestone: M18 → Future
Reporter | ||
Comment 5•24 years ago
|
||
This is still an issue. Just delete an addressbook and the focus is nowhere.
OS: Windows 98 → All
Hardware: PC → All
Reporter | ||
Comment 7•23 years ago
|
||
is there another bug about this or is this the "original" bug?
Comment 10•23 years ago
|
||
I think the New Msg button should be enabled at all times. I don't think it should require an entry to be highlighted. I agree that the Edit menu should be enabled to an entry is highlighted.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•20 years ago
|
Assignee: sspitzer → mail
Comment 12•20 years ago
|
||
This is my take on what we should do. On the address book toolbar we have the following buttons, which are enabled as follows (currently): New Card - Enabled all the time (note if LDAP is selected defaults to add to PAB) New List - Enabled all the time (ditto) Properties - Enabled all the time (i think this is a bug in itself though) Compose - Enabled all the time (no card or blank email = blank addressing widget) IM - Enabled all the time Delete - Enabled only when a deletable card/list/address book is selected. I think these ones should be changed as follows, leaving the rest the same: Properties - Enabled only when one card/list/address book is selected (intended functionality I believe) IM - Enabled only when the selected card has a screen name attached to it. The edit menu will always be enabled, but the relevant items will be disabled appropriately. Comments? If not I'll come up with a patch in the next couple of days.
Updated•20 years ago
|
Assignee: mail → bugzilla
Updated•19 years ago
|
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
Target Milestone: Future → ---
Comment 13•19 years ago
|
||
I've not got time to work on this at the moment
Comment 15•18 years ago
|
||
(In reply to comment #12) > This is my take on what we should do. On the address book toolbar we have the > following buttons, which are enabled as follows (currently): Ok, slight revision (due to bug 358333 and further thoughts. This is what I think we should now do: New Card - disabled if AB is readonly, otherwise enabled. New List - as per bug 358333 Properties - Enabled only when one card/list/address book is selected (note if we fix the AB card not to be modal bug, then this may be when more than one card is selected) Compose - Enabled all the time (no card or blank email = blank addressing widget) IM - Enabled only when the selected card has a screen name attached to it Delete - Enabled only when a deletable card/list/address book is selected.
Updated•18 years ago
|
Assignee: nobody → ptomli.bugzilla
Status: ASSIGNED → NEW
Comment 16•18 years ago
|
||
Seems to solve all the issues as per comment 15. Might be slightly intrusive on the goEdit[Card|List]Dialog side of things. The card version was needed to update cmd_newim, and I thought consistency was probably better. The only callers were changed to suit. Solves bug 132435 and bug 257369 for added juicy-ness, and checked for nitty-ness of m/^\+.*\t/ and m/^\+.*\s+$/
Attachment #246262 -
Flags: review?(bugzilla)
Comment 17•18 years ago
|
||
Comment on attachment 246262 [details] [diff] [review] as per comment 15 + //FIXME: for some reason, mailnews/ gets CommandUpdate_AddressBook invoked + // when the results pane selection changes, while mail/ doesn't. I + // can't figure out why yet, so fix me. @ptomli for bug 37922 + // I think it's something to do with not using resultsPaneOverlay + CommandUpdate_AddressBook(); + This could be because of the differences between these: http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/resources/content/abResultsPaneOverlay.xul#53 http://lxr.mozilla.org/seamonkey/source/mail/components/addrbook/content/addressbook.xul#618 +function onEditCardDialogAccepted() +{ + goUpdateCommand('cmd_newim'); + UpdateCardView(); +} Why not just do it in UpdateCardView? I know that's probably not quite as ideal - Ideally we'd have a nice callback from the nsIAbView telling us something had changed. Unfortunately it doesn't at the moment :-(
Comment 18•18 years ago
|
||
(In reply to comment #17) > This could be because of the differences between these: > http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/resources/content/abResultsPaneOverlay.xul#53 > http://lxr.mozilla.org/seamonkey/source/mail/components/addrbook/content/addressbook.xul#618 > Yes, hence my note below my initial confusion. I left the FIXME in the hopes you'd enlighten me on the preferred practice when meeting this kind of juncture. I can either: i. mimic the mailnews/ version by firing the same event in mail/ ii. accept the differences and remove the FIXME > Why not just do it in UpdateCardView? I know that's probably not quite as ideal UpdateCardView has a happy, clean and well defined task to do. Updating cmd_newim doesn't really have anything to do with refreshing the details pane of a card, except they sometimes occur as a result of the same event[s]. I don't think the calling overhead is significant enough here to warrant some premature optimisation. The other part of me is not wanting an included file (abCommon) to be invoking functions defined in the including file (addressbook, etc), but I think that change is outside the scope of this bug.
Comment 19•18 years ago
|
||
(In reply to comment #18) > (In reply to comment #17) > > This could be because of the differences between these: > > http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/resources/content/abResultsPaneOverlay.xul#53 > > http://lxr.mozilla.org/seamonkey/source/mail/components/addrbook/content/addressbook.xul#618 > > > > Yes, hence my note below my initial confusion. I left the FIXME in the hopes > you'd enlighten me on the preferred practice when meeting this kind of > juncture. > > I can either: > i. mimic the mailnews/ version by firing the same event in mail/ > ii. accept the differences and remove the FIXME I think do the first. It may also explain why TB address book starts up with all buttons (apart from compose) disabled, whereas SM comes up with PAB selected and most buttons enabled (I prefer the SM way). > > > Why not just do it in UpdateCardView? I know that's probably not quite as ideal > > UpdateCardView has a happy, clean and well defined task to do. Updating > cmd_newim doesn't really have anything to do with refreshing the details pane > of a card, except they sometimes occur as a result of the same event[s]. > > I don't think the calling overhead is significant enough here to warrant some > premature optimisation. Ok, that's fine. Another strange effect with this patch: 1) With AB or card selected, note appearance of buttons. 2) Now do a quick search. 3) Clear quick search Result: All buttons disabled. Expected: I think we should still allow New Card & List, but disable properties etc as the focus is on the quick search box (or clear button) but the address book is still selected.
Comment 20•18 years ago
|
||
Comment on attachment 246262 [details] [diff] [review] as per comment 15 see comment 19
Attachment #246262 -
Flags: review?(bugzilla) → review-
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 21•16 years ago
|
||
seems awfully close. Paul, are you still up for this?
Flags: wanted-thunderbird3?
Keywords: polish
Comment 22•16 years ago
|
||
I can still reproduce in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090613 SeaMonkey/2.0b1pre - Build ID: 20090613000642 Reassigning to default for lack of an answer to comment #21
Assignee: ptomli.bugzilla → nobody
Updated•7 years ago
|
Severity: normal → minor
Priority: P3 → --
Product: MailNews Core → Thunderbird
Summary: UI: Buttons should be context dependend → Address book Buttons should be context dependent
Comment 23•2 years ago
|
||
Design is different in version 102
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
Updated•2 years ago
|
Flags: wanted-thunderbird3?
You need to log in
before you can comment on or make changes to this bug.
Description
•