Closed Bug 75772 Opened 24 years ago Closed 23 years ago

[RFE] Hide/show toolbars button in title bar

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: hsivonen, Assigned: mozilla)

References

(
URL
)

Details

(Keywords: platform-parity)

Attachments

(2 files, 4 obsolete files)

XUL, CSS and JS diffs - global chrome/toolbar
13.22 KB, patch
Details | Diff | Splinter Review
C++, header, and IDL changes for Mac OS X toolbar widget support
6.61 KB, patch
Details | Diff | Splinter Review
On Mac OS X, Finder and Mail have a hide/show toolbar button in the window title bar on the right. The same kind of hide/show toolbars button would be a logical addition to Mozilla's browser window title bar. (Currently there is no way to quickly toggle the visibility of all toolbars at one.)
What do other macheads/ui people think?
could be cool (but only for OSX). how do we tell the OS to put that button into the toolbar?
"...button into the toolbar?" doh, I meant titlebar.
wouldn't this be a dup of bug 22056? [or, maybe dependent on it?]
No, this bug and bug 22056 are completely unrelated. Putting buttons for non-windowing operations in the window title bar is generally a bad idea -- but hey, that's Mac OS X. Doing this will make us more consistent with other OS X apps, and it won't make us any *less* usable (unlike some other platform-consistency bugs I could mention).
URL: http://developer.apple.com/techpubs/m...
Keywords: pp
Hoping Dan ``the window man'' Matejka can provide some insight on how to go about doing this.
I'm a Windows freak. -> danm, unless some machead wants to take this.
Assignee: blakeross → danm
The new IE preview has this. (OmniWeb has this, too.)
for those of us who don't have os x, some pictures are in order. http://www.apple.com/macosx/tour/finder.html includes http://www.apple.com/macosx/tour/images/window_customize.gif which has the widget everyone is talking about. i'm still searching for the api.
URL: http://developer.apple.com/techpubs/m... → http://www.apple.com/macosx/tour/imag...
we can only make carbon calls building the way we are (CFM binary).
Well, there's got to be a way. Finder and IE are both Carbon, and they're doing it. - Adam
The Quartz Primer document has some sample wrapper code for accessing the Core Graphics API from a CFM Carbon app. I wonder if the window server could be instructed to put the button there that way.
Target Milestone: --- → mozilla1.0
QA Contact: sairuh → claudius
Im all for it FYI
I'll take this bug (since I now have it working in my tree)...
Status: NEW → ASSIGNED
--> rjc
Assignee: danm → rjc
Status: ASSIGNED → NEW
Anyone want to try out these changes? I've added an "ontoolbar" event (which is generated under Mac OS X when the window's "toolbar" widget is clicked on). The code path is modeled after how the "onclose" event works, BTW... widget code sends the event through the DOM to be handled by JavaScript registered on the <window> element. I added "ontoolbar" handlers to most of the windows in the product: browser, editor, messenger, mail compose, addressbook, bookmarks, history, etc.
Status: NEW → ASSIGNED
Note: its a shame that the various toolbars in the product aren't better architected, it would be nice to have better support for this sort of thing... for example, instead of specific JS for each window, having generic XBL for this would be nice. (If anyone wants to go down that path, I say "go for it".)
Note: On Mac, add the new .cpp file into the content.mcp project [not content.cpp] :)
cc: hyatt for comments on the future of XUL toolbars?
Attachment #54949 - Attachment description: "ontoolbar" event changes in Content/DOM/Layout → "ontoolbar" event changes in Content/DOM/Layout & Widget(Mac)
I don't see the need for adding a builtin DOM event like this. We now have support for custom DOM events, and I don't think the huge quantities of code to add this event (just so that it can be supported using the onfoo syntax) are necessary. For an example of how to create a custom DOM event, see SetTitle over in nsHTMLDocument. I fire a DOMTitleChanged event there. It only takes 3-4 lines of code now to fire an event name of your choice. This patch can basically be way way smaller.
Looking further, I don't even understand the need for a custom DOM event. You could just add a single function to nsWebShellWindow/nsXULWindow that fields the NS_TOOLBAR event and toggles the toolbars' visibility.
You can toggle the toolbars' visibility just by setting an attribute on the <window> element. We already have to do this to support toolbars=no via window.open.
David: that doesn't work for showing/hiding the sidebar, right?
Hmmm... David says it does. I'll give it a try. :)
So, I made David's suggested changes... they work, not requiring any of the DOM changes that I previously made. However, sore points: Some CSS weirdnesses: mail window toolbar doesn't display text under toolbar icons, splitters are sometimes hidden, etc. All major windows with toolbars need tweaks. As long as all the toolbars are hidden due to the window's toolbar windoid, the user can't get any of the toolbars back until the toolbar windoid is clicked again. By that, I mean that any of the options under the "View" menu such as "Show Navigation Toolbar" won't do anything. Also, the menu items will be "checked" as they were previously before being all hidden. Basically, doing it this way disconnects the "View->Toolbar" menu items from the UI when the window's toolbar windoid is clicked... until the window is clicked again to undo the damage.
Would it work to do a getElementById for the required View->Toolbar menu items and invoke the commands associated with any that were visible so as to toggle them to invisible. You'd have to deal with tristate menus toolbars like the SiteNavigation bar. If this works then the menu UI would at least be consistent, though obviously you can't avoid that when you turn the toolbars back on you would turn them *all* on, not just the ones that were previously showing. hrm. I think that last point would annoy people a lot. Perhaps you *do* have to keep which ones were showing somewhere so you can restore them...
Actually, I had a better idea. Why not ignore Show/Hide toolbars and instead collapse them. You know, like when you click the grippy at the end of the toolbar so it becomes a thin line? You'd only then have to do it to those toolbars which are visible, and the user has 2 highly accessible ways of undoing it (click the grippy on a case by case basis or click the window toolbar widget to restore all). It stores its own state too because the toolbars you need to restore are those that are collapsed. If you find a mixed case where some are collapsed and some are not, the simplest thing to do is probably first click -> collapses everything which isn't collapsed second click -> uncollapses everything Or you could reverse that... Thoughts?
Adding dependancy on bug # 75742
Depends on: 75742
UL, CSS and JS diffs - make chrome/toolbar styles and handling uniform across the app
Attachment #54947 - Attachment is obsolete: true
Attachment #54949 - Attachment is obsolete: true
Attachment #54950 - Attachment is obsolete: true
Attachment #54951 - Attachment is obsolete: true
C++, header, and IDL changes for Mac OS X toolbar widget support
These last two patches build upon what David recommended. Basically, make all the "chromeclass" styles uniformly global across the app. Reviews needed, especially from Hyatt due to changes to the locked-down CSS files (navigator.css items moved to global xul.css)
why two separate calls to ::ChangeWindowAttributes()? Seems redundant.
Pink: indeed, looks like I forgot to delete the first call when I moved it (to where the second one is)
Robert, I need to know what you decided as far as breaking the View-->Show/Hide menu (this will save you getting several bugs). For my .02 I love this feature but there is no sense copying a feature if we're just going to emulate it poorly. I looked at the way the finder handles it and saw that it is smooth but probably mostly because there is only one toolbar so show/hide can follow each other w/o trouble in that case. That gave me an idea. Add a new menuitem View-->Show/Hide-->"All toolbars" This item could be the first menuitem in the list. This menuitem would always be active. The trick is after you've clicked the freaky button(you call it a 'windoid') to hide the toolbars this menuitem would be the _only_ active one in the show/hide menu. Selecting it would bring back your toolbars and activate the other items. This sol'n gives you only one thing to hook up that can track 1-to-1 with the freaky button state and we can ignore the case of getting into a weird some on/ some off situation. AND it's a cross platform sol'n - no platform would suffer from having an all on/off menuitem even if they didn't have the corresponding freaky button.
Claudius: the View-->Show/Hide menus are already broken in some cases and need to be fixed up by their respective component owners anyway, so it isn't a big concern.
Was my idea of collapsing the toolbars instead so off base? I still think it solves all of the concerns and no one seems to have poked any holes in it...
Has anyone revealed the latest changes based upon David's comments? <sigh> I guess not. His method requires virtually no code bloat.
revealed=reviewed, of course
robert: while I am far from the arbitor of good coding practices, that is soooooo not an excuse to knowingly break it further. Especially if, as I believe(sez me who does not write code) there is a workable alternate sol'n. lordpixel: first off your sol'n doesn't really get rid of the toolbars. Leaving a little collapsed bar would just annoy me. It just a 90% sol'n. Secondly, uncollapsing all of the toolbars when that's not how I left them before I clicked the freaky button is wrong and confusing and bad and other negative adjectives and the only way around that is adding a fair bit of code that nobody wants to do. Thirdly, without the behavior being hooked up to the View menu (as it should be) the menu will still appear broken to jane user, and we'll have to always explain "no, that's just how it works". Those are my thoughts. Of course I'm biased but I thought Show/Hide-->All Toolbars was a pretty eff'n sweet idea :-) AND it gives the benefit to all platforms.
Claudius: don't give me any crap, or I'll come over to your cube.
ok rjc is not evil (he really did come over to my cube). I'll withdraw my objections and we'll work together to file bugs on 'other people' when this fix gets in. At some point I'll also write the rfe for the Show/Hide All Toolbars. It should be noted that I still think I'm right. It's just that rjc isn't so wrong anymore.
.
sr=hyatt
verbal r=ben
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
There are still problems with this implementation as of the 10/27/01 trunk build. Many top level windows which do not have toolbars like the 'View Source' and 'Page Info' windows.
Just a quick note on the JS diffs (for next time, perhaps?) Some of the code uses the "all" window style. In this case you don't need to explicitly add "status" or "toolbar" styles.
Note: the "all" style only applies to window.openDialog, not window.open Does anyone know why the JS console opens without scrollbars, you need to resize the window to make them appear? (Or window.openDialog("chrome://global/content/console.xul", "_blank", "chrome,all,dialog=no") also works.)
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: