157199 - [META] toolbar customisation and separation tracking bug [customize]

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Mike Lee]

Meta bug to track the development of toolbar customisation as outlined by mpt's
spec http://bugzilla.mozilla.org/attachment.cgi?id=65067&action=view

Comment 1

[Sören 'Chucker' Kuklau (gone)]

What should this depend on? Suggesting bug 15144, bug 48820, bug 48926, bug
49543, bug 89350, Bug 126321 (which is a weird one).

Comment 2

[Jason Bassford]

If this is a duplicate, please indicate original bug.

Marking the dependencies I'm aware of.  (I left out 126321 since it seems
redundant.)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Fixing summary to make this findable or something like that.  Let's eradicate
this "seperate" abomination from the web, please.

Comment 4

[Sören 'Chucker' Kuklau (gone)]

I'd like clarification about the state of marlon's spec (or marlOn's review of
mpt's spec, or whatever way you'd like to put it) and whether it should /
shouldn't / may / may not influence the further progress of the issues tracked
by this bug. This seems to block any progress on bug 15144, and /that/ seems to
block progress on bug 48926 and bug 49543.

Comment 5

[Sören 'Chucker' Kuklau (gone)]

The component change was by mistake.

Comment 6

[Bernard Alleysson]

Don't forget bug 97023

Comment 7

[Sören 'Chucker' Kuklau (gone)]

bug 97023 is neither about customisation nor about separation. Jason already
added quite a lot of dependencies, I think.

...which I'll comment on:

bug 64678 - as far as I understood mpt, the component bar should die as well
after having fulfilled the spec. Thus, I believe bug 64678 is an invalid (with
an explanation why, of course) and *no* dependency.

bug 78532 is solely about mailnews. I'm not sure if this bug includes mailnews
(though the summary does not exclude it) or is only about Navigator.

Comment 8

[Jason Bassford]

> the component bar should die as well after having
> fulfilled the spec. Thus, I believe bug 64678 is an invalid 

If you want to remove bug 64678 I won't object.  In fact I'll remove it myself.
 I was following a trail of dependencies and sub-dependencies and may not have
done enough checking in my selection of all bugs.  Feel free to suggest others
that were too-inclusive (and/or some I missed altogether).

> bug 78532 is solely about mailnews. I'm not sure if this bug
> includes mailnews

This bug, I think, should include all toolbars and all buttons across all
applications.

> bug 97023 is neither about customisation nor about separation

Agreed.  Creating a new toolbar (or button) has no direct impact on this bug -
which is about handling such objects in general, not about them in their
specific substantiation.

Comment 9

[Sören 'Chucker' Kuklau (gone)]

Re: Additional Comment #8 From Jason Bassford  2002-07-12 18:16 -------
> > the component bar should die as well after having
> > fulfilled the spec. Thus, I believe bug 64678 is an invalid 

> If you want to remove bug 64678 I won't object.  In fact I'll remove it myself.
> I was following a trail of dependencies and sub-dependencies and may not have
> done enough checking in my selection of all bugs.  Feel free to suggest others
> that were too-inclusive (and/or some I missed altogether).

I think the list is sufficient for the moment. Rather than adding any dependency
that has the slightest relationship to this, we should concentrate on the most
important dependencies first - namely bug 15144 and bug 49543.

> > bug 78532 is solely about mailnews. I'm not sure if this bug
> > includes mailnews

> This bug, I think, should include all toolbars and all buttons across all
> applications.

Okay.

Comment 10

[Jason Bassford]

Taking time to look more closely at dependencies and removing those that really
should not have been originally listed.  (My fault for quickly doing up the list
without sufficient checking.)  Only those directly related to dynamically
customizing toolbars / icons (individual real time choice) should be here - not
necessarily those to do with usability.  Changing the appearance of a particular
button, adding a button that does a certain thing (outside of dynamic
assignment), or changing the overall UI don't really belong.

I notice that bug 115118 was added.  I'm taking it out again since this is a bug
that would affect the UI regardless of what was done in terms of adding buttons,
moving toolbars, etc.  It has no bearing on any of that requested functionality.
 It may have some bearing on bug 54943, but not on this tracking bug per se.

I would like to request that whenever a bug dependency is added / removed from
this point forward, that a comment is made listing its description and, perhaps,
the reasoning behind the change.  That way it makes it easier to track what's
going on here.  As such, I'll list the bugs I've taken off of the dependency
list (more than half actually):

bug 20306 - Can't open more than 2 windows with navigator button in component bar
bug 33684 - add "Up" navigation command
bug 52036 - Classic 'Go' and 'Search' buttons ugly appearance.
bug 71138 - Add Bookmark button
bug 84718 - [RFE] Add Find button to toolbar
bug 89005 - [RFE] Browser needs an "Up" navigation button
bug 89350 - Home button should appear on main Toolbar
bug 91504 - Implement Complete and Correct Classic Theme on Mac
bug 104125 - [RFE] Need one-click button for new browser window
bug 115118 - RFE: dynamically expanding/contracting URL bar for low res users
bug 154772 - [RFE] Tooltip for address bar should show complete current URL

The above, while impacting toolbar UI, are not, I believe, directly related to
implementing MPT's spec (although his spec, once implemented, will certainly
allow for some of them to happen with or without the bugs themselves being
specifically resolved: addition/removal of buttons, bug 15144, will, for
instance, solve bug 89350).

My apologies for any SPAM this is causing.  I should have taken more time with
the depencies originally.

Comment 11

[Jason Bassford]

> It may have some bearing on bug 54943

Make that bug 49543. <sigh>

Marking this bug as blocking newly created bug 157415 - Add "Reset Toolbars"
once customization is in place.

Comment 12

[Jason Bassford]

Attachment: MPT's toolbar cusomization spec - basis for this bug.

Attaching MPT's toolbar customization spec to this bug.

Comment 13

[Jason Bassford]

Attachment: Screenshot of fix for bug 49543.

Comment 14

[Jason Bassford]

This bug should see attachments of patches and screenshots of fixes for its
dependent bugs.  Suggesting a standard naming convention for readability sake:

Screenshot of fix for bug X.
Patch for bug X.

This helps track development of all sub patches.  Also to be attached here could
be a "meta patch", incorporating the patches from all of the dependent bugs.

Comment 15

[Jason Bassford]

Attachment: Screenshot of fix for bug 48926.

Comment 16

[[e-mail]]

I'm not quite sure if there's any point copying attachment 91339 [details] [diff] [review] to bug 49543 as
Bugzilla will have linkified appropriate URLs into this comment.

Comment 17

[[e-mail]]

You might want to edit the attachment in which case the link is
http://bugzilla.mozilla.org/attachment.cgi?id=91339&action=edit

Comment 18

[Jason Bassford]

Attachment: Patch for bug 49543.

Comment 19

[Robert Kaiser]

I think it's EVIL to attch non-reviewed patches to any other bug in a tracking
bug. This only gives us a list of patches that nobody needs here.

If we have patches that are OK and working for a big bunch of dependencies, and
we merge them to a patch that can easily apply all the chages, then it might be
OK to attach it here.

Making double attchments to bug X and tracking bug Y is very BAD though, and
doesn't help anything but bloat on the Bugzilla database.

Comment 20

[Jason Bassford]

The only way to make toolbar customization visible, and link all of the
sub-components together properly, is to do it this way.  It creates a single
source to which anybody interested in MPT's spec can go and track progress. 
This whole issue deserves more attention than it's getting.

Comment 21

[Jason Bassford]

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

Comment 22

[Sören 'Chucker' Kuklau (gone)]

The general consensus appears to be that attachments should not be added at all
to this tracking bug. I can find at least one exception: Screenshots showing a
(more or less) complete implementation of at least two of the bugs tracked here
should be posted in this bug, as they are not directly related to *one* of the bugs.

Comment 23

[Jason Bassford]

Added bug 158144 - Resizable toolbars. - to dependency list.

Comment 24

[Jason Bassford]

Correction (apologies): bug 158544 added.

Comment 25

[Matthew T (active 1999-2002)]

This bug report is (1) a duplicate of
<http://bugzilla.mozilla.org/showdependencytree.cgi?id=49543>, and (2) *not* a
blocker for bug 157415 (`Reset Toolbars' will be useful once pretty much *any*
toolbar customization is implemented).

Please just bookmark the above link, instead of spamming people with an extra
tracker bug. Thanks.

Comment 26

[Jason Bassford]

This is not a duplicate of that.  Adding a specific button has nothing to do
with this bug (bug 71138 as listed has nothing directly to do with bugs that
allow for dynamic configurability.)  This is a tracking bug, that is not.

> *not* a blocker for bug 157415 

Yes it is.  Reinstating.  There is *currently* no real reason for it to be
solved.   But once the other pieces fall into place, then it will have a
purpose.  What you're saying is that you can go to the store and by baby diapers
at a point after you've started buying other items in preparation for its
delivery.  But it really makes more sense that "buying diapers" depends on the
actual event itself (delivery) more than anything else.  Hence, once all of the
other elements are configurable (splitting toolbars AND horizontally
configurable toolbars) then we'll want to resize them.  I know of know way of
making a bug dependent on 2 other bugs being fixed *at the same time* , so
making it dependent on this tracking bug is more appropriate.

Comment 27

[fondacio]

Shouldn't bug 161032 be added to the dependency list of this bug? And if that
one is fixed, won't many of the bugs that are being tracked by this one become
obsolete?

Comment 28

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 29

[Garth Wallace]

This is a tracking bug, so it's no wonder there haven't been any comments. Some of the dependencies have had recent activity, so I'm setting this back to NEW.

Comment 30

[Gina Odom]

Attachment: same problem

Thanks from stetuteadan1982.