Closed Bug 75772 Opened 23 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: