Closed Bug 175091 (NoGrippies) Opened 22 years ago Closed 22 years ago

put toolbar collapse grippies back in

Categories

(SeaMonkey :: UI Design, enhancement)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: irdial, Assigned: janv)

References

Details

(Whiteboard: [adt1])

Attachments

(1 file)

backout patch
27.50 KB, patch
janv
: review+
hewitt
: superreview+
Details | Diff | Splinter Review 
The small bar collapsers that collapse the toolbars is now missing after
upgrading to 1.2b. This is true across all themes.

*** This bug has been marked as a duplicate of 174831 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
argh.. not a dup. The toolbar ..collapsers were deliberatly removed i believe.
Will look for the bug.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
yes... they were removed as result of enhancement-bug 112534 - see discussion
there. Resolving as invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → INVALID
given that there's going to be more of these (i'm about to dupe one), I don't
think a request to put them back is INVALID. re-resolving as WONTFIX...
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
*** Bug 175282 has been marked as a duplicate of this bug. ***
reassigning to match removal bug...
Assignee: jaggernaut → varga
Component: XP Toolkit/Widgets → XP Apps: GUI Features
QA Contact: jrgm → claudius
Summary: Missing toolbar collapser after upgrade to 1.2b → toolbar collapse grippies are missing
and re-resolving as WONTFIX (making an assumption that that's right - if anyone
in authority wants to change their minds...)
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
Alias: NoGrippies
*** Bug 175773 has been marked as a duplicate of this bug. ***
*** Bug 176073 has been marked as a duplicate of this bug. ***
OK! I now know that insanity and mob rule govern the mozilla application
framework. Why would you want to break apps that third party devolpers are
making or have made. toolbar grippies are usefull. Why would you want to remove
this from the toolkit, toolbars.xml, just because the apps that mozill.org build
using them suffer from usability issues - fix those apps don't change the
toolkit. You can disable grippies, by not referencing then in xul and by styling
them, without removing the functionality and breaking third party apps by
removing this functionality from the toolkit. Is the point to drive developers
away from building apps based on mozilla? Is the stabilty of the toolkit less
important than than the few apps currently built by mozilla.org and their
usability issues? Are current and future apps to be hamstrung by a constanly
changing feature set in the toolkit? Is the idea to have developers constantly
reinventing the wheel? The arument 'if you don't like it make your own' and 'we
can't afford the xul bloat' smells - you are talking about a few lines of code.
My reading today of the toolbars.xml shows grippies are gone. I PLEAD FOR
SANITY. I PLEAD FOR STABILITY IN THE TOOLKIT.
*** Bug 176696 has been marked as a duplicate of this bug. ***
*** Bug 177942 has been marked as a duplicate of this bug. ***
*** Bug 178185 has been marked as a duplicate of this bug. ***
My proposal (I have posted it in Bug 112534 already, sorry for the noise): until
we have a nice solution, what about removing the grippies in the default theme,
but allow other themes to add them again? Alternatively, users could make them
appear again by changing the prefs.js. What about that?

I know that the grippies are regarded as superfluous by the Mozilla style guide.
Anyhow it seems that they are not that superfluous in reality, since there are a
lot of users complaining about their disappearance.
michael:
I know that I'm jumping in quite late, but I'm REOPENing this now.
If it should get WONTFIXed, I think it should/must be done by a module owner or
peer, who's deciding not to implement this RFE.

I'm doing German L10n (my builds are downloaded by a quite high number of
people) and I got a lot of comments that considered missing toolbar grippies as
a bug, and I got a bunch of people here that really liked to use the grippies.
This is what leads me to believe this should get a part of configurable toolbars
(though maybe turned off by default), and is low-hanging fruit for going in that
direction.
I think the code for the grippies should go back into the tree, and a
"visibility:collapse;" rule for them should go into the Classic and Modern
themes for now. This way, 1) people can turn them on using user-chrome.css and
2) they can be turned on by default in alternate themes.

As a long-term solution, we should be able to turn them on/off with configurable
toolbars.
Severity: normal → enhancement
Status: RESOLVED → UNCONFIRMED
OS: Windows XP → All
Hardware: PC → All
Resolution: WONTFIX → ---
that's fine - I marked it WONTFIX based on comments from the owner in the
removal bug (bug 112534) at that time.

given that the owner has now commented in that bug that the decision has been
reconsidered, it makes sense for this bug to be open.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks, I didn't read through all of that bug report...

For reference: look into bug 112534 comment #64 for reasoning why grippies are
needed.

I read through bug 112534 comment #64 and saw the following sentence "The two
novice users [...] had found the show/hide toolbar menu and played with it to no
avail."

Perhaps we should always restore the toolbar to uncollapsed state when
re-enabling it from the show/hide menu item. This way, if they click the item
once, they might see something disappearing (perhaps not recognizing that it was
the collapsed grippy) - on a second click (to undo whatever was disappearing
there) they'll get the full un-collapsed toolbar again.

The menubar grippy should be hidden on default themes anyway but still be able
to work on alternate themes, like we had it before the remove.
Put them back!!!
I was really disappointed to learn that the grippes were deliberately removed,
especially after I went through the trouble of rebuilding 1.2.1 on my Debian
woody as it was not available yet. OK, we have too many config options already;
granted, novice users may find them confusing; but I definitely find them useful
and I am missing them. Please put them back.

I understand that adding a comment here is not the best way to voice my opinion,
but I don't have the time to follow Mozilla newsgroups so it's the best that I
can do.
How do I vote against this?
IMO, not much point in voting, or discussing this further - it's been discussed
to death, both sides of the argument have been made lots of times.

but if it makes you feel better, then if you want to vote for them back, vote
for this bug. if you want to vote for leaving them out, vote for bug 112534
which was to remove them.
Summary: toolbar collapse grippies are missing → put toolbar collapse grippies back in
Okay, I'm dumb crooked-hand headless user, which is always confused by closing
whole Mozilla by pressing Ctrl-Q.
Will this bug (Ctrl-Q) be fixed, such as grippies? 
is there a way to hide de MENU bar?
that's why I used grippies before...
When something happens that can only be explained by pleading insanity, you have
to wonder if something more sinister is afoot! Could it be that the Empire
(Microsoft, for the metaphorically challenged) has placed moles at key positions
within the Mozilla project? 

I hope the backgrounds of those responsible for this horrible misdeed are
checked throughly for possible "under the table" remuneration from Mr. Gates.

And BTW, this is DEFINITELY A BUG since the ability to remove the MENU was
destroyed by the removal of the WONDERFUL grippies!
Thank you for your really VALUABLE comment.
If bug 15144 ever gets fixed grippies should be pointless.
Please stop spamming us with comments that say that you are for or against
resolving this issue - especially if you got no good explanations to tell.
If you comment here, tell us ways to come to a good solution, or, even much
better, attach patches for fixing the issue. Thanks.

mrmazda:
Bug 15144 is orthogonal to that issue. On my 800x600 Notebook, I like to have
the menu bar + the two default toolbars (navigation + personal) for most of the
time, but sometimes I need a bit more space, and I really loved to collapse all
three (including menubar) with grippies for viewing just that one page, and
expand all of them quite fast again afterwards. And yes, even if e.g. collapsing
only menubar or personal toolbar didn't save much, collapsiong both helps much more.
Anyways, I'd need grippies even if toolbars were configurable, but you should be
able to include/exclude them with exactly that mechanism as well - see my
comment #15 for my proposal, extended by the proposal of comment #17.
The best solution might be make grippies optional feature which could be turned
on or off via preferences.

I would suggest to change summary to "Add pref to turn on/off toolbar collapse
grippies" and add helpwanted keyword.
a pref would be a bad idea - there are already far too many prefs. the users
that are confused by the grippies, or confused by the lack of them, will not go
looking for searching the maze that is the prefs dialog looking for a checkbox.
theme authors will be able to turn them on and off, users that know about
editing userChrome can also do so. if there's going to be any kind of visible
user option, it should come as part of toolbar customisation.

(apologies for further spam...)
rather than another pref (in the prefs dialog(ue)s), a suggestion:

View | Show/Hide > [Toolbar] Grippies
Toolbar grippies can collapse menu bar, that's why them don't have to be placed
in menu.
Anyway, if some users misses 40x40 "back" button, when grippies are placed in
left part of tab, maybe there's a sense to place them onright? (I cannot imagine
user, who misses "Back" button in that case) 
Why not assign a hot key similar to F11 that would maximize viewable area in the
window?  F12 would seem to be a good choice.  This would serve the purpose and
would be more convenient than the grippies were.  Just press F12 to make the
menu bar, tool bar, and status bar disappear.  Press Escape or F12 again to make
them reappear, or close and reopen the window.
#29:
| a pref would be a bad idea - there are already far too many prefs.
| the users that are confused by the grippies, or confused by the
| lack of them, will not go looking for searching the maze that is
| the prefs dialog looking for a checkbox.

Then how about a "hidden" pref (without UI) for those desperate enough to want
the grippies back?
Flags: blocking1.3b+
I don't find here the reason, those strange acting nighty powers behind Mozilla
based their weird decision on to remove those wonderful Grippies. They were
working perfectly for me, they were very useful and I want them back the way
they were.
Comment #32 From Bill Moore:
Nice idea but a completely different thing. If you want that, file a different
bug. Thanks for your attantion.
Hiding menu bar, tool bar, and status bar at once is not usable. The advantage
of grippies is that you can hide all garbage, that is garbage at due time (and
will not be garbage after minute).
Example: I don't need menu, navigation and bookmarks page, but I need
"Top/Up/First/Prev... etc." bar or any additional bars, such as "Preferences
bar" from mozdev.org. On some intranet pages I don't need "Preferences bar".
Using F12 to hide all toolbars doesn't help in this case. 
bugzilla@r123.de, don't set flags if you don't know how to use them.
Flags: blocking1.3b+
*** Bug 186987 has been marked as a duplicate of this bug. ***
I like the grippies, I wouldn't mind if they were a preference that was off by
default, but I don't want them removed altogether. 
I like the grippies, I wouldn't mind if they were a preference that was off by
default, but I don't want them removed altogether. 
Nav triage team: nsbeta1+/adt1
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]
Attached patch backout patch — — Splinter Review 

    
    

    
  
Ok, so this is just a backout of 3 patches which were checked in. (bug 112534).
http://bugzilla.mozilla.org/attachment.cgi?id=101717&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=101540&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=101665&action=view

There were only some minor changes in the meantime.

Status: NEW → ASSIGNED

    
    

    
  
Comment on attachment 111932 [details] [diff] [review]
backout patch

caillon says r=caillon

        Attachment #111932 -
        Flags: review+

    
    

    
  
Comment on attachment 111932 [details] [diff] [review]
backout patch

I'll oblige Jan and give this sr=hewitt, but I want to say for the record that
I disagree strongly with this.

Toolbar grippies are a cumbersome solution to a not-so-pressing issue, and we
were right to take them out in the first place.

        Attachment #111932 -
        Flags: superreview+

    
    

    
  
fixed

Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED

    
    

    
  
All right, but what will it be? Were toolbar grippies put back exactly as they
were before (i.e. to the left), or are they on the right side now (according to
Additional Comment #31 and fixing the problem which once leaded to removing
grippies)? Please tell us Jan, since there are some users not eager to start
downloading nighty build right now, just to find it for themselves.

    
    

    
  
I downloaded the nightly, the grippies are on the left side, like before.
Actually, they're also there in fullscreen-mode (F11) which wasn't before, was it?

    
    

    
  
I just backed out the patch to remove them.
Everything should look as before.

    
    

    
  
Um.. This caused startup to slow down by 5% on mecca, luna, and comet.  I can't
believe that the grippies require that much time to do, so I have to suspect
that something else that you changed was changed incorrectly.  Whatever it was,
please fix it; I have filed bug 189713 on the regression.

    
    

    
  
Why on earth was this checked in given that the superreviewer said he disagreed
strongly with this?

An sr= is invalid if the superreviewer disagrees with it, since that's what sr
is for: checking that the superreviewers agree with it.

This should be backed out.

    
    

    
  
So Joe Hewitt, the last XPFE module owner is opposed and Jag, the current XPFE
module owner hasn't put his stamp of approval on this. Not only does that but
it's a serious perf regression. 

Jan, Please revert these changes until you have both module owner approval and
permission from drivers to introduce a 5% perf regression (or can eliminate the
perf regression). 

    
    

    
  
I have posted a comment (number 101) on related bug 112534 by mistake, having
intended the comment for this bug. Since the comment is long and because i don't
want to get accused of spamming, i'll refrain from reposting it here. You may
read my comments concerning making grippy retention a theme-specific issue
rather than a toolkit issue on bug 112534. 

(Sorry. I am shrinking into a corner in shame.)

    
    

    
  
Leston: if you want to quickly maximise your browser area, hit F11. If we want
users to be able to reduce the number of toolbars, then we should be looking at
doing what Phoenix have done. (It should be simple to move the code over.)

    
    

    
  
Hixie:
Full screen mode is NOT the same as having toolbar grippies / "collapsers" /
whatever you want to call them.
I never saw full screen having a menubar, or fullscreen having only the personal
toolbar (yes I sometime liked the grippies to do exactly that).

Additionally, full screen doesn't work correctly on my favourite platform.
Anyway, full screen doesn't have the system's task bar on screen, so I also
can't use its functions (which I need quit often) as well.

I don't want to rant about full screen mode here, it's useful some times as
well, and good to have it. It's still not the same as toolbar grippies though,
it's a completely different topic IMO.

    
    

    
  
Regarding MailNews: there is just no such thing as Full Screen Mode in MailNews!
So the grippies are *very* useful there.


    
    

    
  
Note that the code contains some awful JS for instance it predates
document.getAnonymousElementByAttribute

    
    

    
  
Where are the instructions for hiding both the controls the grippies switch
on/off and the grippies themselves, so as to maximize viewport without using F11?

    
    

    
  
reopening so we don't lose this discussion.  Either solve it here or move to
another bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
this should really be decided one way or the other before 1.3beta... are
grippies staying or going? have drivers decided to accept the 5% perf hit? this
really should be a hard decision to make... </rant></spam>
Flags: blocking1.3b?

    
    

    
  
it's not 5%
Ts: 1-2%
Txul: 2-3%


    
    

    
  
The grippies should be removed because they are poor UI, not just because they
slow the application down by 1%.

    
    

    
  
I had refrained from adding to the discussion here, but this getting too much!

For Hixie and everyone who thinks its a bad idea to have the grippies,

It's obvious from a number of people here that there are quite a few people who
think that the grippies are a good UI - Usable and convenient.  It has nothing
to do with moving toolbars.  It has to do with a *quick* and intuitive way of
collapsing/reopening toolbars on demand.

I used it extensively with the Personal toolbar and especially the Prefbar.  I
no longer have the Prefbar on my machine after the grippies were removed and
I'll get them back as soon as the grippies are restored.

I know this is not your position, but for crying out loud listen to folks who
are outnumbering you by about 4 to 1.  (Bug 112534 to remove the grippies has 12
votes to the 44 votes to restore them)

Regards
Milind

    
    

    
  
*** Bug 190263 has been marked as a duplicate of this bug. ***

    
    

    
  
Smart voters move their votes from fixed bugs to open bugs, which means a
current vote count on a fixed bug proves little.

    
    

    
  
What it proves is that the folks that want it out, can't abide by any proven feature in Communicator to be in Mozilla or N7. They can't 
admit that it had some good (UI) qualities. (We are not talking about standards compatibility here - we are talking about UI features 
UI features only allow us to interact with the underlying items that "are" standards compliant. IF W3C have standards on UI icon sizes 
and shapes that's going way to far). The location bar for mail and news is another example; but, that's getting off on another subject.  
If it was in to Start with why mess with a good thing. As the old saying goes "If It Aint' Broke, Don't fix it"! all the grippy icons saved 
was about an 1/8 of an inch on each menu bar. If you need more room decrease the size of the icons make them the same size as 
the ones in Communicator. Besides saving room the file sizes of the icons would be smaller. Or have the icons that would be off 
screen to drop down on a second line in the menubars automatically.


    
    

    
  
testing 4 patches for varga on mecca, here:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Testerbox
this breaks down the regession into different parts.  I'll let varga
summarize when this is done.

    
    

    
  
.
Assignee: varga → shliang
Status: REOPENED → NEW

    
    

    
  
I want those too!

    
    

    
  
jan, didn't you fix this already?
Assignee: shliang → varga

    
    

    
  
yeah, toolbar grippies are back in
this was reopened because of perf regression, but actually the perf regression
is discussed in bug 189713


    
  
Flags: blocking1.3b? → blocking1.3b-

    
    

    
  
marking as fixed, perf problems are discussed in the bug 189713
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED

    
    

    
  
vrfy'ing fixed with recent (2003.02.18) comm trunk builds.
Status: RESOLVED → VERIFIED

    
    

    
  
i know this has been "settled" but it still strikes me that this should be said
concerning concerning a bulk of the arguments at hand pre-dating the real
conversation over the performance hit.

i doubt i've ever once used the full capability of grippies, but it will take a
lot to convince me that a five (?) pixel diameter on a toolbar to empower the
user to stash away toolbars that are useless 90% of the time to a single row of
comparible heighth, but still provide the instantaneous ability to recover the
toolbars without initializing four to six menu popups (and four to six more to
re-stash), is bas ui design. the fact that the "stashed" toolbars were unlabeled
had always struck me as an inconvenience.

in no case do i appreciate the fact that this bit of user interface, which has
been degraded to a more Emacs-like approach of popping up the menu bar a few
million times to get the job done, has been officially labeled as "confusing
toolbar grippies" for a reason of removal.

i feel that the professionalism involved in the original removal of grippies is
solely to blame for every bit of flame here, and strongly advise all responsible
to mind statements made towards generally acceptable implementation.

furthermore i'd be interested in querying as to how difficult it would be to
separate the user interface from mozilla. there would be much to benefit from if
replaceable packages resembling the themes could be used to choose ui features.
though i've not a clue what trying to do so would entail in code form.

 -- Tyln Sylverwind
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: