Closed Bug 363981 Opened 18 years ago Closed 15 years ago

Add support for adding toolbars in thunderbird

Categories

(Thunderbird :: Mail Window Front End, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: mscott, Assigned: mkmelin)

References

Details

Attachments

(2 files, 1 obsolete file)

In firefox, you can create new toolbars when you run out of room on your primary toolbar. Now that quick search and mail views are toolbar buttons, and no longer get their own search bar box, some users in Thunderbird may want to add additional toolbars.

I wonder if we can add support for adding additional toolbars to thunderbird.
This would indeed be very useful...
OS: Windows XP → All
Hardware: PC → All
Do you want them for 2.0? They're actually the current holdup for unforking customization for 3.0, because Fx and Sb have forked menu code for them for View - Toolbars that I need to move into an overlay in toolkit, but unforking from three things won't be any more difficult than unforking from two.
Hmm, I'd be interested in it for 2.0 if it doesn't involve any string changes and the changes (if any) in \toolkit\ were small enough that we could get the triage team to approve them on the branch. mail\ changes are easier to take :).

Given the removal of the search toolbar, extra toolbars would be pretty useful. 
I'd love to get this for 2 but if it doesn't happen, I don't want to lose track of this so putting it into the tb3 bucket.
Target Milestone: --- → Thunderbird 3
Hi,

I wrote this functionality up as an extension while the code [ported straight from Firefox works] is fixed up. You can find the extension at http://unsignedbyte.com/tbaddtoolbar.html . 

Cheers
We should set the blocking thunderbird3 flag instead of target milestone.
Flags: blocking-thunderbird3?
Target Milestone: Thunderbird 3 → ---
Version: 2.0 → Trunk
Assignee: mscott → nobody
Severity: normal → enhancement
Let's plus this for 3, I think it would be pretty usable and probably not impossible to port from ff.

Phil, are you planning to do this? Comment 2 kind of sounds like your interested in takin' in on:)
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
Priority: -- → P2
Keeping wanted‑thunderbird3+, will try to get to this myself. Though if anyone is interesting in taking it, feel free to do it.

FWIW, first implemented in ff bug 171101. Bug 234373 implemented it for calendar.
Assignee: nobody → mkmelin+mozilla
Priority: P2 → P3
Target Milestone: --- → Thunderbird 3.0b2
Summary: Add support for adding toolbars → Add support for adding toolbars in thunderbird
In case its content might be useful for this solution, see also

'TB Custom Toolbar' extension in Thunderbird Add-ons at

https://addons.mozilla.org/en-US/thunderbird/addon/5240

I would imagine my extension would be of limited help, as it is just the code copied from Firefox; that code being slightly buggy the extension is as well.
I don't know why customizeToolbarSheet is in browser... and I think I spot a lot of unnecessary customizeToolbar.dtd inclusions in the mail/ code. 

Anyway, we should unfork our copy of customizeToolbar.xul, which seems to be pretty straight forward now.
Status: NEW → ASSIGNED
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
Attached patch proposed fix (obsolete) — Splinter Review
Get rid of some more code that we're much better off not maintaining our copy of. 

I didn't find any "new" problems while testing, but customization does easily put some in the error console...
Attachment #352914 - Flags: review?(philringnalda)
(In reply to comment #13)
> Anyway, we should unfork our copy of customizeToolbar.xul, which seems to be
> pretty straight forward now.

It does seem straight forward, but I'm pretty sure from discussions I've had, that there is something that we can do that toolkit doesn't allow.
I'd be curious what that is, the cvs log for it basically just shows cleanup and keeping up with firefox.
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/mail/base/content/customizeToolbar.xul&rev=HEAD&mark=1.15
Bug 359656/Bug 358994. Just saying "screw whoever it was who wanted a Cancel button, the best that anything in toolkit which Firefox doesn't want can hope for is to be constantly broken, anyway" is an interesting approach to fixing them, I'll admit.
I'll sleep well at night with the cancel button gone :)
Especially given the cost of keeping up with a file that we're not supposed to be forking, and getting support for adding toolbars for free.
Even if we'd think there should be a cancel button, there's so many firefox users used to living without one that inconsistency doesn't gain us much.
> there's so many firefox users used to living without one

That's not really an argument, they just don't know better, probably. :-P
You can get "used" to everything, crappy or not.
(In reply to comment #17)
> "best that anything in toolkit which Firefox doesn't want can hope
> for is to be constantly broken, anyway"

Is anyone actually saying that? Is there opposition to adding the cancel button to the toolkit (perhaps with an easy way to disable it when it's unwanted) that I'm missing?
Yep. Sometimes things do change over the course of a couple of years, but at the time I was trying to unfork, Cancel was absolutely refused for Firefox (in #foxymonkies, not in the bug), so unless and until someone figures out a way to automatically test customization, anyone working on customization code would have to count on our meager few testers (between two and three, for m-c trunk right now, probably) to tell them that they broke Cancel without knowing it.
OK. That's not opposition to taking it in Toolkit though, that's opposition to taking it in Firefox, and Firefox refusing to take on the testing burden for a feature it doesn't want seems pretty reasonable to me.

You seem to be implying that a "Cancel" button implemented in Toolkit but not used by Firefox is likely to be broken all the time, but I don't really see why that would be the case. Toolbar customization code doesn't change all that often, and a test for it could be written easily enough (perhaps by copying from one of the existing tests, e.g. http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/browser_customize.js or the one that's yet to land in bug 422590).
Hmm. How easy is it to implement the "Cancel Button" UI/functionality in an overlay of the toolkit customizeToolbar*.xul? I'm planning to file a bug to request some hooks in the toolkit code that SeaMonkey can use to extend the functionality via callbacks and overlays.
I didn't try making an overlay, yet. 

But anyway, I do think "firefox does it" *is* a argument. Especially when the platform doesn't have a cancel buttons in the preferences (like on linux) I don't think a cancel is warranted. In the end, the "damage" is always very limited, as you even have a button there to get the defaults back.
Without all the spelling mistakes;)
Attachment #352914 - Flags: review?(philringnalda) → review-
Comment on attachment 352914 [details] [diff] [review]
proposed fix

Our customizeToolbarSheet.xul will need a addNewToolbar button, too. Just copy-paste it from browser/, and I'll make sure it works.
Blocks: 455098
through transitivity of blocking, blocks.
Flags: blocking-thunderbird3- → blocking-thunderbird3+
Attached patch proposed fix, v2Splinter Review
Attachment #352914 - Attachment is obsolete: true
Attachment #358704 - Flags: review?(philringnalda)
Whiteboard: [has patch for review]
Attachment #358704 - Flags: review?(philringnalda) → review+
Comment on attachment 358704 [details] [diff] [review]
proposed fix, v2

r=me with a couple of additions.

We need

+++ b/mail/base/content/customizeToolbarSheet.xul
     <hbox align="center" pack="end">
       <button label="&saveChanges.label;"
+              id="donebutton"
               oncommand="finishToolbarCustomization();"
               default="true"
               icon="close"/>
     </hbox>

to make the Mac sheet work with the bug 403942 hack which is still hanging around, and the

+++ mail/components/compose/content/MsgComposeCommands.js	9 Jun 2008 21:12:59 -0000
   // initialize the customizeDone method on the customizeable toolbar
   var toolbox = document.getElementById("compose-toolbox");
-  toolbox.customizeDone = MailToolboxCustomizeDone;
+  toolbox.customizeDone = function(aEvent) { MailToolboxCustomizeDone(aEvent, "CustomizeComposeToolbar"); };

which somehow got lost between the third and fourth patches in bug 363461.
Thx Phil, appreciate it!

(I also fixed the button icon name  (bug 424363) - but I assume that doesn't really do much on mac anyways.
changeset:   1761:20e6eff6a02b
http://hg.mozilla.org/comm-central/rev/20e6eff6a02b

->FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [has patch for review]
You need to log in before you can comment on or make changes to this bug.