Closed
Bug 49543
Opened 24 years ago
Closed 16 years ago
Separate Toolbar from Address Bar [urlbar]
Categories
(SeaMonkey :: UI Design, enhancement)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mpt, Assigned: jag+mozilla)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [geekweb-fixed])
Attachments
(4 files, 15 obsolete files)
(deleted),
image/gif
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
At the moment, the Command Toolbar (featuring Back, Forward, Reload, and Stop
buttons) and the Location Toolbar (featuring location field and `Search' button)
are combined into a single `Navigation Toolbar'. This limits users' ability to
customize the interface to suit them:
* they may want browsing controls and other buttons (like `Print' and `Text
Size', for example), without needing to see the location;
* they may need to see long URLs, and be frustrated that the location field is
constricted by the presence of the browsing controls in the same line;
* they may prefer their browsing controls on the right, rather than the left, of
the Location Bar.
Therefore, the Command Toolbar and the Location Toolbar should be split into two
separate toolbars. These could be horizontally aligned to achieve the current
layout, or realigned to achieve any of the layouts described above.
Reporter | ||
Comment 4•24 years ago
|
||
Blocking bug 64073 at Håkan's request -- the separation of these bits of chrome
will affect what the location field/URL field/address field is called.
Comment 5•24 years ago
|
||
There are several other prefs that use the text "location bar", and it doesn't
look like this bug is going to be fixed right away. I think it would be better
to fix bug 64073 now and then go back later and change all of the prefs if the
location bar ends up being called something else.
Comment 7•24 years ago
|
||
Chaning the qa contact on these bugs to me. MPT will be moving to the
owner of this component shortly. I would like to thank him for all his hard
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
Reporter | ||
Comment 9•24 years ago
|
||
Every day this bug drives me nuts a little more. --> XP Apps: GUI.
Assignee: mpt → blakeross
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
Updated•24 years ago
|
QA Contact: sairuh → claudius
Comment 11•23 years ago
|
||
Comment 12•23 years ago
|
||
I would like a review on the chrome changes in this patch.
Comment 13•23 years ago
|
||
I thought you said this didn't work in Modern?
Comment 14•23 years ago
|
||
Neil, I applied your patch and fixed some problems with it. I am still hacking
on it to make it all work in modern.
FYI, having "Home" and "Search" in the toolbar (rather than Personal Toolbar)
will be included with this fix (hopefully).
Assignee: ben → hwaara
Comment 15•23 years ago
|
||
Comment on attachment 48289 [details] [diff] [review]
First go at a patch. Works best in Classic :-)
obsoleted. neil and I will be working on a better patch.
Attachment #48289 -
Attachment is obsolete: true
Updated•23 years ago
|
Summary: Separate Toolbar from Address Bar → Separate Toolbar from Address Bar [urlbar]
Comment 17•23 years ago
|
||
Comment 18•23 years ago
|
||
Comment 19•23 years ago
|
||
Updated•23 years ago
|
Attachment #51213 -
Attachment is obsolete: true
Comment 20•23 years ago
|
||
Neil, can you attach a screenshot of how it is supposed to look?
Comment 21•23 years ago
|
||
Comment 22•23 years ago
|
||
The tooltip says 'Location Toolbar'. Shouldn't that be 'Location Bar'? IIRC
this is what it was in previous versions of Netscape.
Comment 23•23 years ago
|
||
I just copied the tooltip from all the other tooltips in Mozilla.
Comment 24•23 years ago
|
||
I don't want to be the buh man - I really like the additional horizontal space
for the location bar. But isn't that an incredible waste of space?
The empty space in the Toolbar really invites people to overload it and destroy
the lean design again.
Worst thing is that the user has no option to get back to the old (current)
layout. Shouldn't we wait with this until we allow users to place toolbars next
to each other? (That was my most favorite feature in MSIE4, back then.)
Comment 25•23 years ago
|
||
Ben Bucksch wrote:
> I don't want to be the buh man - I really like the additional horizontal space
> for the location bar. But isn't that an incredible waste of space?
On 800x600 it's a useable amount of space. IMHO the current URL is too short.
> The empty space in the Toolbar really invites people to overload it and destroy
> the lean design again.
Silly me - the search button on the right of the URL was turned off.
Comment 26•23 years ago
|
||
Comment 27•23 years ago
|
||
<rant>
When did MPT say that 'Location' should be changed to 'Address'? I don't see
any comment to that effect in this bug. And why's it have to be changed
anyway? 'Address' is just so IE-like. We may as well start
calling 'Bookmarks' 'Favorites' and refer to mail/news 'threads'
as 'conversations'.
</rant>
I know absolutely nothing about coding (rather concerning as I'm doing a
Computer Science degree) but I had a look at the patch and noticed the
following line:
+<!ENTITY personalToolbar.tooltip "Bookmakrs Bar">
As I said, I know nothing about coding but surely that spelling can't be right.
And when did it stop being the 'Personal Toolbar' anyway?
Comment 28•23 years ago
|
||
this bug depends on a toolbar UI customization spec (that i am working
on) before it can be implemented. there are also some significant
changes to Modern that will be made in the future to accomodate this bug,
as well as accomodate other facets of toolbar customization. since we
cannot implement the feature without also breaking modern, or breaking
the current UI, i suggest we time this feature with the broader toolbar
changes that are coming up. The changes coming up are both
customization UI and Modern chrome changes.
Comment 29•23 years ago
|
||
This should be fun!
Comment 30•23 years ago
|
||
This is a drastic change to the toolbar layout, and as such, it should not
happen before Mozilla 1.0.
Comment 31•23 years ago
|
||
I agree with Marlon that a change like this shouldn't be made until we have the
customization features necessary to allow the user to choose. Neil, what do you
think?
Comment 32•23 years ago
|
||
Blake, I just wrote a patch, you should be asking mpt.
Reporter | ||
Comment 33•23 years ago
|
||
Blake, Marlon is mistaken in stating that this bug depends on toolbar
customization; in fact the reverse is true, because you can't customize the
Toolbar if (as is the case now) there is no Toolbar with space available to
customize. Every previous version of Mozilla (1.x through 4.x) had toolbar
buttons and the address field in different bars, without horizontal toolbar
alignment not being customizable; and that is also the case even in the latest
versions of iCab and MSIE for Mac (to name two). Marlon also appears to be
incorrect in claiming that the patch breaks Modern, as attachment 51851 [details] shows
Modern working just fine with the patch applied. Finally, I think it's
unreasonable for him to claim that this bug is dependent on his own sekret
toolbar customization, when he hasn't CCed himself to the relevant bug (let
alone assigned it to himself or shown any signs of working on it), and when the
fix for this bug is a major improvement in itself.
Hyatt, behind lack of speed, I regard this bug as Mozilla's second biggest
usability problem overall (not to mention being the only obvious bug blocking
use of Mozilla at the Internet cafe). Obviously you have a large,
high-resolution screen (I've seen photos:-), so that the extreme shortness of
the address field isn't as aggravating for you as it is for many other advanced
users. And people like you and I (and most other Mozilla contributors) have no
problem fossicking our way through menus, know how to press Enter after typing
an URL, and don't rely on prominent access to things like Home and Search in the
main Toolbar (rather than the `Personal' Toolbar which we might have turned
off). But for millions of people this is not the case; they prefer to avoid
menus if possible, and the lack of basic features such as Home and History in
the toolbar is very annoying. I hesitate to say that any lightly-modified
distribution of Mozilla 1.0 (such as the equivalent Netscape release) would not
be a credible mass-market browser without this bug fixed; but it would be doomed
to the same niche audience of extremely technically-inclined users that it has
now. And that isn't really what I'm here to achieve.
Comment 34•23 years ago
|
||
This patch is basically the same as the previous one. I updated it so that
it can be applied cleanly to the current trunk. There is one minor bug fix
(a missing single quote mark).
I also posted a patch for bug 89350 (basically based on this patch). It
simply adds a home button to the nav toolbar.
The discussions on this bug and bug 89350 are quite inconclusive, so
I'm not sure which bug should depend on which (as far as I can see,
there are at least four bugs involved: 15144, 48926, 49543, and 89350).
Frankly, I don't really care whether the address bar is separated from
the nav bar, or whether the toolbars are customizable. But personally
I do think a home button on the nav toolbar is really great (especially
since I want to get rid of the personal toolbar because of bug 107926).
But, of course, I'm not a UI expert, so...
Comment 35•23 years ago
|
||
I, for one, would very much like to see this applied to Mozilla soon. This has
to be one of my biggest pet peaves. At work, my monitor is set to 1024*768
which is OK for this current toolbar setup because it displays nicely (good
resolution). However, at home, I do not have the latest and greatest monitor.
Any resolution over 800*600 just shows up poorly, so without getting rid of the
go, search, and print buttons(and I would really like to keep at least the go
and print around), I cannot make use of a higher resolution to get a longer
adressbar. And I don't feel like I need to upgrade any hardware to acomplish
this task, as every other browser is just fine in this area. I feel bad for all
the people that work in 640*480 because the adressbar is just rather jokey in
that res.
I know this is an enhancement, however, it really shouldn't have to be. This
should've been the way this was designed from the get-go, but it's a little late
for should haves and could haves. If this patch works, and works well, I
believe this should go in sooner, rather than later (yes, I've heard the talk
about this special toolbar custimization stuff but...). Let's apply it to the
trunk and see how it behaves. If no problems, fine. Then work can continue
normally for all the other "enhancements" to this area. If problems arise, then
at least these things can be worked out/on so that when Moz is ready to make
it's big release, this will be working properly. Why wait until 0.9.9 or later
to land these and then deal with any issues that may pop up. Seems like more
headache to do that.
Don't get me wrong, I like Mozilla and use it often. However I would probably
use it more often if this "enhancement" was in place.
Just my opinion(s). Oh yes, and if these toolbars become separated, PLEASE (as
also in this bug) add "Home" to the Nav Bar. Thanks.
Comment 36•23 years ago
|
||
Please put the home button in the navigation toolbar. If you seperate the
location entry box into another toolbar please make it an option. I would love
the current setup plus the single addition of the home button to the navigation
toolbar. Screen size is precious on a 1024x768 laptop. I do not wish to
squander it with the personal toolbar.
I don't use booksmarks in any browser. I use my own scripted home page with a
google search box and much more. I use the home button extensively in my daily
browsing to return to this scripted home page. The great quality of the mozilla
mail and news client (IMAP support is very well done) has me switching over to
mozilla 100% but the extremely annoying home button location is a major hindrance.
Comment 37•23 years ago
|
||
You are a very special case. For almost all other users, bookmarks are much more
important than Home. If you created a scripted homepage, then you can hack your
Mozilla to have the home button.
Comment 38•23 years ago
|
||
what do you think about bug 115118?
Comment 39•23 years ago
|
||
Cymen, pressing Alt+Home (or equivalent on non-Windows platforms) will take you
home.
Comment 40•23 years ago
|
||
[q]You are a very special case. For almost all other users, bookmarks are much
more important than Home. If you created a scripted homepage, then you can hack
your Mozilla to have the home button.[/q]
My scripted home page might make me a special case but I only mentioned that to
give an example of why the home button is important to me. Many other people
have argued to have the home button on the navigator toolbar. All the other
browsers have it, why not at *least* make it an option on Mozilla? A number of
arguements for the inclusion of the home button on the navigator toolbar have
been made yet every time the response is that "you are special", "this isn't
needed", "I don't use the home button so you don't need it", yadda yadda yadda.
Why is there such opposition to this relatively simple inclusion?
<i>what do you think about bug 115118?</i>
Personally I'm not a big fan of floating anything (I'm assuming your note is in
reply to mine). I like small, well-crafted, fixed in place (non-floating) user
interfaces. Internet Explorer does exceedingly well at providing such an
interface - you can use minimal buttons that hide the text display to conserve
on screen usage. The end user gets to decide what buttons they want on their
toolbar, the button size, whether they have text labels or not, etc. I can live
with Mozillas larger buttons but I can't live without my home button.
[q]Cymen, pressing Alt+Home (or equivalent on non-Windows platforms) will take
you home.[/q]
Thanks for pointing out an easy solution but I was aware of this already (it is
alt-home on linux too). This doesn't get around the fact that a button would be
much more useful. In my case switching between desktops and laptops makes
remembering the alt-home finger judo a bit hard (and I do touch type).
[q]If you created a scripted homepage, then you can hack your Mozilla to have
the home button[/q]
I agree. If I didn't think this wasn't an issue that affected more than a few
users I wouldn't be here bitching. But I think that the home button is a common
feature in web browsing that users have come to expect to have in their browser.
I'll get off my ass and figure out how to get my home button in Mozilla. But
all those users that can't figure out how to do that will simply remove Mozilla
from their machines and go back to using some other shoddy browser. I can't see
a rational arguement to exclude the home button. So many uses are obvious...
The corporate intranet home page, the scripted netscape.com home page, the
internet cafe, etc. So what I'm left wondering is whether the exclusion of a
home button is going to continue to be standard procedure or if the marlon
bishops work is going to make it an easy choice (even though he too seems to be
opposed to the home button).
I love Mozilla but please reconsider the exclusion of the home button from the
navigation toolbar.
Comment 41•23 years ago
|
||
Can we move the Home button- and other tangential discussions to other places,
like separate bugs or a newsgroup? I will respond there, then.
Comment 42•23 years ago
|
||
For the Home button, it's Bug 89350 "Home button should appear on main Toolbar"
Comment 43•23 years ago
|
||
Adding myself to CC, and at the same time,
nominating for mozilla1.0 target milestone.
http://mpt.phrasewise.com/stories/storyReader$35
There is a patch for this, what is keeping it back ?
Comment 44•23 years ago
|
||
I think we need a little more polish on the visual look here. Does the patch
still make things look like the screenshot in the bug? If so, the URL bar is
ugly and needs to be fixed up.
Comment 45•23 years ago
|
||
not just a little more polish. A LOT. modern needs it's "modular Modern"
update. and the Toolbar Customization UI spec needs to get implemented, of which
this is a dependency.
Comment 46•23 years ago
|
||
What dependencies are you talking about Marlon; "modular Modern update",
"Toolbar customization", "Toolbar Customization UI spec" -- there is a patch,
that works fine, it just needs some cleanup. Then we can check it in and this
will work. There is no real dependancy on the stuff you mention.
I think it's bad practice to keep adding pseudo-dependencies to most-wanted bugs
like this one, unless there are real, very important reasons.
Comment 47•23 years ago
|
||
Get the affected parties (module owners, or peers if no owner) to r= the patch,
then get an sr=. I just glanced at the patch and spotted a typo (Bookmakrs)
that should be fixed first.
/be
Comment 48•23 years ago
|
||
Where would one find the Toolbar Customization UI spec?
Reporter | ||
Comment 49•23 years ago
|
||
Yeah, I apologize, I added bug 48926 to the wrong field by mistake. As I said
in comment 33, we can't have a customizable or horizontally rearrangable
toolbar until we have a toolbar with space available to customize or rearrange
-- i.e., until this bug is fixed. See 4.x, 3.x, 2.x, 1.x, Opera, and iCab for
examples of browsers which have their toolbar and address bar separate without
having a customizable toolbar.
I've sent Neil and Håkan the list of things which need fixing for the patch to
be review-worthy (one of which is the typo Brendan mentioned).
Comment 50•23 years ago
|
||
1) The images required to make things "re-arrangeable", such as the URL field,
are part of an update that has yet to be applied to modern - "modular modern"
2) this bug is about customizing toolbars - the ui for separating toolbars, part
of "toolbar customization ui", is presently in draft specificaton phase. which
is also presently not identified as a priority - which means it's not going to
be implemented very soon. there's a large amount of design work that has been
completed, but hasn't yet been published or finalized.
Comment 51•23 years ago
|
||
This bug is not about customizing toolbars. This bug is about separating the
location field into its own toolbar. Doing so is IMO a requirement *before* we
can proceed with toolbar customization.
I think this bug is also primarily concerned with what the default setting
should be, regardless of whether customization is implemented or not. There
have been numerous (again IMO) compelling arguments made for separating the
location bar, and it seems like this would be a worthwhile thing to do even
without implementing toolbar customization.
Comment 53•23 years ago
|
||
Attachment #51214 -
Attachment is obsolete: true
Attachment #51847 -
Attachment is obsolete: true
Attachment #51851 -
Attachment is obsolete: true
Attachment #52494 -
Attachment is obsolete: true
Attachment #58335 -
Attachment is obsolete: true
Comment 54•23 years ago
|
||
You need this image in themes/modern/navigator/icons to test the patch.
Comment 55•23 years ago
|
||
Fixes a number of problems with the old patches, and a bunch of nits from mpt.
Testing appreciated.
There is one glitch in Classic and one Modern, that I think should be addressed
when this patch is checked in:
1. The Modern "Print" button-icon - we need a new "round" image for this - it
looks a little disaligned on the Toolbar right now.
2. The Classic "Home" button's icon - it should be a little bigger than it is.
Comment 56•23 years ago
|
||
Mozilla calls uris locations, not addresses.
Comment 57•23 years ago
|
||
IMO we should go in the other direction and get new back/forward/reload/stop
buttons that actually match the icon style of the other apps. And we should put
text back underneath the buttons. :)
Comment 58•23 years ago
|
||
> Mozilla calls uris locations, not addresses.
There's been a gradual shift from 'Location' to 'Address' in the UI. Pull up the
context menu for a link and note how 'Copy Link Location' has become 'Copy Link
Address'. Then recall how the traditional Netscape hand cursor was replaced with
the system default (read: IE cursor) on Windows. Coincidence? I think not.
There's obviously a conspiracy within the Mozilla community to secretly change
Mozilla into IE. We'll be calling them 'Favorites' next.
Seriously now, I believe the decision was made by MPT who gave some reasons that
I seem to remember made reasonable sense. I think there was a newsgroup
discussion as well but I may have just been dreaming (yes, I dream about Moz
sometimes).
Comment 59•23 years ago
|
||
No, there's no agreement or reasonable consensus in favor of changing location
to address when the referent is a hyperlink. There have been "accidents", or
were they "sneak attacks?" Please stop.
Blake, didn't you undo your unintentional change to Copy link location?
/be
Comment 60•23 years ago
|
||
While I appreciate the hard work going into this patch, I see no comments
anywhere indicating that this patch will continue to allow the current behaviour
of using the space at the top of my browser window optimally.
I'm not a typical user, I'll be the first to admit: I have thousands of
horizontal pixels to play with, but only a few hundred horizontal ones. My
typical browser window is 1600x600 pixels. I already have a menu bar, a
navigation bar, a personal toolbar, a link toolbar, a tab bar and status bar.
Please _please_ don't add yet another horizontal bar unless you are going to
make it possible to place that horizontal bar into the newly created gap. If you
need to add horizontal room for other people, make it possible to remove the
"Stop" and "Print" buttons and the throbber -- I never use those. But please
don't make my browser window even shorter.
BTW I also don't understand why the Home button needs to be moved. It's a link,
it belongs with all the other links on my personal toolbar. Again, if you are
going to move it, please make it possible to leave the current UI as is.
Comment 61•23 years ago
|
||
This is a first step in the direction of customizable toolbars, but you can't
get everything you want at once. Please, this is one of many patches (hopefully)
that will gradually improve the toolbar support we have. This bug is for
splitting the toolbar, not for making them customizable. That's bug 15144.
Regarding "Address": I thought this had been agreed upon in other bugs and in
the newsgroups? If there is a strong demand to change back to the old "Location"
and "URL" semantics, I can do that as well.
Reporter | ||
Comment 62•23 years ago
|
||
I agree with Dave that Modern should use standalone icons inside visible
rectangular buttons, since that would make their apparent target area much
larger (especially for the Back and Forward menus), and it would allow you to
use the shapes of the icons to distinguish them (it's hard to do that now
because the circles are more vivid than the icons themselves). But that can be
done after this patch lands ...
Håkan, you can find full-size Home icons for Classic in all states here:
<http://mozilla.org/docs/refList/user-interface/visual/buttons/winimage.html>
<http://mozilla.org/docs/refList/user-interface/visual/buttons/macimage.html>
Comment 63•23 years ago
|
||
Håkan: Like in real estate, it is "Location, Location, Location".
Comment 64•23 years ago
|
||
New home.gif for the Classic theme
Comment 65•23 years ago
|
||
New home-active.gif
Comment 66•23 years ago
|
||
New home-hover.gif
Comment 67•23 years ago
|
||
New patch. Changes: fix home button in Classic, and change "Address Bar" to
"Location Bar" as discussed.
Attachment #64764 -
Attachment is obsolete: true
Comment 68•23 years ago
|
||
Comment on attachment 64826 [details]
home-hover.gif
Hmm... shouldn't we be using -moz-image-region on these images these days?
Comment 69•23 years ago
|
||
While we're discussing wording... the Personal Toolbar now seems be the
Bookmarks Bar. Which is it to be? Personally I like Bookmarks Bar better.
Comment 70•23 years ago
|
||
Let's not go around changing terminology while implementing this patch. That's
just going to make it even more contentious than it already is. Please retain
current terminology, i.e., "Location" as well as "Personal Toolbar". Those
sorts of wording changes should be the subject of separate bugs.
Comment 71•23 years ago
|
||
hwaara: This might be "one of many patches (hopefully) that will gradually
improve the toolbar support we have", but if one of the steps along the way
reduces our usability or increases the pixel footprint of our chrome, then
there is the distinct chance that it will end up in a released product in that
state, not to mention it will be used by people using nightlies and cvs tip.
IMHO this kind of work should happen on a branch until it is ready to be
committed all at once. The immediate benefits of splitting the toolbars are,
in my opinion, completely outweighed by the disadvantages of an extra 20
pixels of chrome footprint.
This is especially important if the work is only "hopefully" going to be done,
as you put it.
Comment 72•23 years ago
|
||
I completely agree with Ian about creating a branch. I don't want my toolbars
changing daily, as I have to use the nightlies to get work done. I also don't
want more toolbar than content space, so if this goes in without anyway to
revert to the current design, I'll have to hunt you down. mmmmmkay.
Comment 73•23 years ago
|
||
Hmmm. Perhaps we need to implement toolbar customization first, including the
fixing of the buttons in Navigator, the implementation of modes
(text/pictures/etc.), and the ability to put all of the toolbar objects on any
toolbar.
Comment 74•23 years ago
|
||
hmmm, if there's one idea i like, it is that one.
Comment 75•23 years ago
|
||
marlon bishop wrote:
> hmmm, if there's one idea i like, it is that one.
So where's the spec?
Comment 76•23 years ago
|
||
Please, this 'enhancement' has been hanging around for what? Almost a year and
a half? IMO, the separated location bar should've been separated from the
beginning, just like every other browser, previous version of Netscape, etc. On
the browser UI side, it's probably my most major annoyance. I'm trying to save
space myself too - wasted space. I've never really used the personal toolbar
from 4.x and don't now. The only reason it's up is for the silly home button
that's not on the Nav bar. I'd gladly hide the personal toolbar for a separated
location bar and home button. Of course I'd have still have the same amount of
toolbars, however, they would all be functional and not just sitting there
looking pretty. I do understand those that want the option (if separated) to
revert back to everything on the Nav bar, and don't disagree with them. I just
think that since there is actually a working patch now that looks good, I don't
see waiting another 6 months or year to implement it. Gotta start somewhere.
Just my .02
Reporter | ||
Comment 77•23 years ago
|
||
Comment 78•23 years ago
|
||
If I may make a comment on the spec. It's great except for one thing:
Don't lose the grippies. MSIE (and many other Windows programs) use them for
rearranging toolbars. In fact, one of the first things I tried with Mozilla
(after reading about the 'great customization' it offers) was to drag the
toolbars via the grippies. If Moz has the ability to move toolbars, then the
grippies should stay. If toolbars are immoble, then the grippies should go.
my $0.02
Comment 79•23 years ago
|
||
mpt: I agree with djk. Moving toolbars needs more discoverability. Either a
menu item (like in Gnome), or grippies, or a tooltip... just _something_ to
inform power users that moving toolbars is possible.
marlon: Rumours are that you have also written a spec. Could you please
publish it so that it can be compared to mpt's?
marlon and mpt: It is a pity you did not work on these specs together (either
in pixeljockeys, n.p.m.ui, or, at a pinch, by e-mail). Mozilla's QA people
work as a team, Mozilla's engineers work as a team, Mozilla's evangelists work
as a team. Yet repeatedly we end up with two conflicting views for UI specs
with the parties not cooperating.
staff@mozilla.org: Do we have a process in place yet for resolving the
conflicts that are bound to happen as soon as someone tries to implement one
of these specs? We've been waiting for YEARS now for some sort of UI process
to be determined. It would be very unfortunate if this continued lack of
process resulted in the different parties doing their own UI instead of
contributing and working together on one UI.
Comment 80•23 years ago
|
||
Slightly different in that it doesn't change existing ids, and thus leaves more
things alone. I'm also not sure about removing the prefs for the existing
buttons before we have something to replace them with.
Comment 81•23 years ago
|
||
> Slightly different in that it doesn't change existing ids, and thus leaves more
> things alone.
Hmm, doesn't leave the wording alone... (comment 70).
Comment 83•23 years ago
|
||
Are we any closer to seeing this "enhancement" fixed? Or any closer to seeing
the toolbar customization spec implemented? Moz 1.0 is getting closer and
closer and it would be a BIG disappointment to not have this functionality by
then, or at least this bug working.
Comment 84•23 years ago
|
||
Okay everyone seems to be thinking about using this as a stepping stone to bug
15144. Aint we forgeting something? The major problem I see is if this doesn't
get fixed by 1.0 every skins made will be based on current layout and they won't
be very happy. If we don't fix this by 1.0 it shouldn't be fixed until 2.0 or
something, the benefit of stable api (that apply to skin makers too) in 1.0
would be meaningless if they have to make a new skin for mozilla 1.1
Just get the essentual infrastructure in place, and then in bug 15144 spec out
the customisation standard (shortcut button size etc).
The usability issues are already discussed by mpt and others and everyone seem
to agree with the reasoning behind it, so I wont go into that.
Comment 85•23 years ago
|
||
Is this going to happen pre-1.0? I agree with Mr. Lee that it will be annoying
to skin makers to have their skin set for 1.0 then have this obsoleted. This
irks skinmakers and is why we don't have any skins but classic and modern at
the moment, as you probably know.
Comment 86•23 years ago
|
||
The history icon in that is a little IE-esque... but otherwise it looks nice. :-)
Comment 87•23 years ago
|
||
I agree. Other than the history icon, all look fine.
Comment 88•23 years ago
|
||
The history icon looks more like a Pac-Man than anything else. I had to take a
look at the spec to figure out that it is the history icon.
It's completely unintelligible.
Also, why is there a print button? mpt's spec doesn't mention one.
Comment 89•23 years ago
|
||
Did Netscape 4 have a History icon somewhere? If so, what did it look like?
(Opera doesn't seem to have a History icon anywhere).
I took a brief look at the toolbar icons on Tasman (IE 5.x for Mac OS) and liked
them. Had no time to take a screenshot though.
Comment 90•23 years ago
|
||
NN4.x hasn't any icon or button for history.
Comment 91•23 years ago
|
||
I would like a skin with a big back-button on the left side and a big one on the
right. Really. If I'm correct, this isn't possible with the current
toolbar-structure. Or am I asking too much?
Comment 92•23 years ago
|
||
*** Bug 134781 has been marked as a duplicate of this bug. ***
Comment 93•23 years ago
|
||
adding self to cc list
Comment 94•23 years ago
|
||
Ian, please do not spam bug reports with "cc'ing myself". While adding yourself
to cc list doesn't send mail to most of us (this feature can be activate through
bugzilla personal prefs), your comment IS sent while doesn't offer any useful
info to this bug.
Comment 95•23 years ago
|
||
<completely offtopic>
> Ian, please do not spam bug reports with "cc'ing myself".
He had to. Due to a bug in Bugzilla, you have to add a comment when adding
yourself to the CC list on several bugs at one time. That bug has already been
fixed, bugzilla.mozilla.org just hasn't updated it's Bugzilla installation yet.
</completely offtopic>
Comment 96•23 years ago
|
||
For a NS4.x-style history icon, see
http://home.netscape.com/browsers/future/aurora.html
Comment 97•23 years ago
|
||
Or just see <http://www.blakeross.com/images/mb.jpg> ;-)
Comment 98•23 years ago
|
||
Sorry to add useless comments, but will this make it for 1.0? This is my biggest
pet peeve besides bug 79992, and 1.0 is really close.
Comment 99•23 years ago
|
||
http://bugzilla.mozilla.org/attachment.cgi?id=65067&action=view#rearrange
Related bugs:
bug 7696 - Floating Toolbars
bug 47418 - Dockable/Undockable/Closable sidebars
bug 45532 - Context menu for toolbars
bug 48926 - Horizontally adjacent toolbars
By reading that toolbar spec, it appears that this bug should depend on all of
the aforementioned.
Comment 100•23 years ago
|
||
Toolbars should still be collapsable even if there is a toolbox. For the whole
toolbox row to collapse, all the toolbars on the same row would have to be
collapsed.
Comment 101•23 years ago
|
||
Obviously, we're not going to see the implementation of the new toolbar spec in
version 1.0. But we can't wait until 2.0! This _is_ a very important feature,
and I'm surprised it wasn't implemented when first creating the toolbar.
This is the bible:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=65067
Go for it!!
Comment 102•22 years ago
|
||
Re: Comment #88 From Christian Biesinger 2002-03-17 01:45
> The history icon looks more like a Pac-Man than anything else.
Suggesting a variation of this icon
http://images.google.com/images?q=tbn:0MysHGE50k8C:www.essentialmac.com/images/icon_myst.gif
as base for a new history icon.
> Also, why is there a print button? mpt's spec doesn't mention one.
mpt mentioned several off-by-default toolbar buttons though, including a print
button:
<mpt> Oh yes, there are lots of buttons that would be off by default
<mpt> Print, Save, Zoom, Encoding, Style, Preferences, New Window ...
These, of course, also need icons.
Comment 103•22 years ago
|
||
*** Bug 153135 has been marked as a duplicate of this bug. ***
Comment 104•22 years ago
|
||
I loved the spec (attachment 65067 [details]), mpt :)
However, I do agree with Hixie and djk in comment #78 and #79.
Come on people, something must be done here. This is a 'basic' feature that
people expect to exist. It was one of the first things I tried when I installed
Mozilla..
I agree with Hixie in comment #79, Mozilla and Netscapes UI 'teams' really need
to work together. Lets face it, Mozilla's UI is bad. My mother wouldn't
understand 20% of it, and as someone else said, she would _not_ find out how to
send emails, which is a severe issue. I think there is an conflict of interrest
here.. but there should not be at all! The interrest of both UI 'teams' is
ofcourse to make the UI easily understandable.
I would have to say that I find mpt's spec very good. Not just this one, but all
the things he has said while I have been hanging around here.. He does not only
say /how/ it should be (like Netscapes UI group), but also states (and
clarifies) /why/ it should be implemented as he has designed it.
I'm sorry if that offended some of you, but that's the impression I've got at
this time.
What about adapting Apple's design procedures ? I think it goes something like:
'If the code touches /any/ UI code _at all_, it has to be clarified with the UI
group before checkin.'. That means that all UI code for Mozilla would have to be
clarified by the 'Mozilla UI' module-people first.
'Mozilla UI' needs to be created as a module, see http://www.mozilla.org/owners.html
I don't think it will help any, but the following keywords should be added to
this bug:
access - because I want to customize the toolbars to my special needs.
helpwanted - because something has to happen here.
highrisk - because it touches many parts of the code, and introduces lots of new
code. will cause some bugs.
intl - because people will need to update their translations.
qawanted - because we need some QA here to sort things out (that means,
cooperation between Netscape and Mozilla UI people).
relnote - this feature is _very_ important for (I would like to say /all/) many
people, and could be a reason for them to upgrade.
ui - that's what it's all about :)
And while you're at it, remove the mozilla1.0 keyword.. Someone told me Mozilla
1.0 had shipped ;)
Well.. that's just my 2 NKR.
Comment 105•22 years ago
|
||
I agree, the Navigator UI needs to be changed ASAP. The problem is that toolbar
customization is something many people want landed before this bug is put into
high gear. Plus, the chevron thing for the menu overflows is needed to make the
changes successful. Also mpt and others have yet to have seen a good icon set
for the toolbar. Check this out:
http://groups.google.com/groups?selm=3D029DF6.E3C15D9%40myrealbox.com
BTW: someone with the access should update the keywords and get this thing on
the radar for a not so distance release (probably not 1.1).
Comment 106•22 years ago
|
||
Check out these icons (linked from mpt's site):
http://www20.brinkster.com/rochette/moztoolbar/
They look nice both in classic and modern. Check them out.
Comment 107•22 years ago
|
||
Is it possible for someone with access to update the keywords on this, and
change the priority and/or severity? C'mon, this is important!! We are already
passed mozilla 1.0, this needs to be updated immediately!
Can anyone else provide a status update on this? Is implementation planned
soon? Or is this just floating around in space??
Comment 108•22 years ago
|
||
------- Additional Comment #107 From Mike Palumbo 2002-07-09 09:18 -------
> Is it possible for someone with access to update the keywords on this,
mozilla1.0 should be removed, indeed. I think mozilla2.0 or perhaps 1.5 is a
more likely target.
> and change the priority and/or severity?
Not seeing anything wrong with them.
> C'mon, this is important!! We are already
> passed mozilla 1.0, this needs to be updated immediately!
Not seeing any urgency in updating the information. Additionally, I myself don't
have the privileges to do that.
> Can anyone else provide a status update on this?
I'm working on an own implementation in my spare time, but it seems like a long
and boring task. I also can't do all stuff mentioned in the spec, including
customization. What I can do is rearrange the chrome etc. to create a better
default chrome. I'm several steps further than
http://bugzilla.mozilla.org/attachment.cgi?id=51851&action=view and the other
screenshot: Other buttons such as "History" and "Mail" have been added, and the
components bar has been removed (in all components available in default builds;
that excludes calendar etc.). But the whole thing still looks incomplete for me,
and as said, customization is still not really possible.
> Is implementation planned soon? Or is this just floating around in space??
Call me pessimistic, but I think this won't be resolved before at least late
2002. There's several patches in this bug, and while I haven't tested them,
others apparently haven't either (at least not thoroughly, as there is no
*reviewed* patch), so I'm feeling lack of interest by the developers.
Comment 109•22 years ago
|
||
> and change the priority and/or severity
This /is/ an enhancement request (albeit an important one), so severity is
correct. Priority, like target milestone, is for the assignee only.
Keywords: mozilla1.0
Comment 110•22 years ago
|
||
>This /is/ an enhancement request (albeit an important one), so severity is
correct.
I guess it all depends on your viewpoint. I personally don't see this as an
enhancement, but as a major usability impediment that is blocking several bugs.
I can't tell you how many people have asked how to put the location toolbar on
its own line, like they are used to having it under IE or Opera. To me, this is
a major *problem*, not just an enhancement, and it is holding Mozilla back
*severly*.
Perhaps I just see this as much more important than other people do??
Comment 111•22 years ago
|
||
Mike, please take your questions to the newsgroups. With every comment we make,
we are spamming a CC list of 65 people (sorry).
Comment 112•22 years ago
|
||
Well, maybe if someone actually allowed this "enhancement" (BUG) to be fixed,
than nobody would get spammed.
Comment 113•22 years ago
|
||
>But the whole thing still looks incomplete for me, and as said, customization
is still not really possible.
Would you mind posting what you have complete, so that we can look at it? Or at
least a screenshot anyway? <g>
As for customization, read the spec that mpt posted, under the "Implementation
Plan" section:
"1. The Toolbar and Address Bar should be split, and the Personal Toolbar
renamed to the Bookmarks Bar. This step can and should be done before other
changes to toolbar structure or customization, as it provides a significant
usability improvement in itself."
It doesn't matter if we can't completely customize the toolbars yet, we should
at least split up the address bar from the rest of the toolbar. It's an
important start to getting some real usability in the Moz toolbars.
>Mike, please take your questions to the newsgroups.
Wasn't really any questions, but I will say that I am hesitant to take anything
to the newsgroups; as soon as I do that, it's one step closer to this bug
falling off the radar again. This bug has been open for almost 2 years now, its
OLD, it's blocking other usability bugs, it needs to be fixed. Also, I will
apologize for the emails everyone received (Id hardly call it spam though, its
definitely not UCE).
So my question now is, what can I do to help with this? I want to see this bug
marked as Fixed. The patches obviously need to be tested, but is there still
more Chrome work to do? That I can help with. I'm interested to see what
Chucker has done on this.
Comment 114•22 years ago
|
||
> Also, I will apologize for the emails everyone received (Id hardly call it spam
> though, its definitely not UCE).
The term 'spam' is generally used to refer to any Bugzilla mailings that do not
help to get the bug fixed.
Such as this one.
Comment 115•22 years ago
|
||
No offence, but the screenshot (from January!) in comment #53 looks pretty
fixed to me
Comment 116•22 years ago
|
||
>No offence, but the screenshot (from January!) in comment #53 looks pretty
fixed to me
Agreed, it most certainly does. Is it just that no devs tested the patch, or is
something else holding this back??
Comment 117•22 years ago
|
||
Re: Additional Comment #112 From Tobias Tinkerman 2002-07-11 07:27 -------
> Well, maybe if someone actually allowed this "enhancement" (BUG) to be fixed,
> than nobody would get spammed.
Well, if you could contribute to fixing this in one way or another, your comment
wouldn't be *considered* spam. If not, then patience is a virtue, as they say.
We all want this fixed, but that alone won't help.
------- Additional Comment #113 From Mike Palumbo 2002-07-11 08:47 -------
> Would you mind posting what you have complete, so that we can look at it? Or
> at least a screenshot anyway? <g>
As to a patch, no, because 1) I'm not that familiar with using diff and patch
yet and 2) I don't see any point in offering a patch that is known to cause
other regressions (such as currently, the loss of ability to remove the print
button in the navigator preferences as I'm working on that at the moment).
As to a screenshot, sure, why not :-) Created this one for your viewing pleasure:
http://soeren.mystfans.com/mozilla/newchrome/shot-2002-07-11.png
As this is sure to get criticized, let me note several things first:
1. yes, this is based off the icons from this attachment:
http://bugzilla.mozilla.org/attachment.cgi?id=74549&action=view , which aren't
perfect yet (see comments from biesi etc.)
2. no, the print button does not belong there for the default setup, as per
mpt's spec. it's just enabled because I could only disable it by manually
editing prefs.js at the moment and I was too lazy to do that for the shot.
3. yes, I've seen too that the shading between address bar and personal toolbar
somewhat isn't right, and I'm looking into that.
4. There's a strange problem with the bookmarks, search and history buttons
causing the sidebar sometimes not to open
5. The Go button is ugly, I know. It always was.
> As for customization, read the spec that mpt posted, under the "Implementation
> Plan" section:
> "1. The Toolbar and Address Bar should be split,
This is done.
> and the Personal Toolbar renamed to the Bookmarks Bar.
This is not yet done.
> This step can and should be done before other changes to toolbar structure or
> customization, as it provides a significant usability improvement in itself."
Okay, but I might be able to do the customization stuff too. I myself would
prefer a complete solution.
> It doesn't matter if we can't completely customize the toolbars yet, we should
> at least split up the address bar from the rest of the toolbar. It's an
> important start to getting some real usability in the Moz toolbars.
Maybe.
> Wasn't really any questions, but I will say that I am hesitant to take anything
> to the newsgroups; as soon as I do that, it's one step closer to this bug
> falling off the radar again.
For whom? I think the problem is that those who most want it fixed are also
those who least can fix it themselves. And vice versa.
> So my question now is, what can I do to help with this?
Are you good at graphics? Provide us with better new toolbar items. Not to put
the circle around them would be a good start, according to mpt.
> The patches obviously need to be tested,
I haven't looked at the patches yet. If I were to test them on my own build, I
would break my own changes ;-)
> but is there still more Chrome work to do? That I can help with. I'm
> interested to see what Chucker has done on this.
See above. (Additionally, I've removed the components bar, and other less
interesting stuff)
Re: Additional Comment #115 From Tobias Tinkerman 2002-07-11 09:16 -------
> No offence, but the screenshot (from January!) in comment #53 looks pretty
> fixed to me
It's a good start.
Comment 118•22 years ago
|
||
>As to a patch, no, because 1) I'm not that familiar with using diff and patch
>yet and 2) I don't see any point in offering a patch that is known to cause
>other regressions (such as currently, the loss of ability to remove the print
>button in the navigator preferences as I'm working on that at the moment).
Gotcha, didn't know there were regressions happening.
>http://soeren.mystfans.com/mozilla/newchrome/shot-2002-07-11.png
Looks great overall!
>> As for customization, read the spec that mpt posted, under the "Implementation
>> Plan" section:
>> "1. The Toolbar and Address Bar should be split,
>This is done.
Then why isn't this bug marked as fixed?? This bug is only for splitting up the
Address Bar from the Toolbar, which has been done.
>> and the Personal Toolbar renamed to the Bookmarks Bar.
>This is not yet done.
This is Bug #48820.
>Okay, but I might be able to do the customization stuff too. I myself would
>prefer a complete solution.
Yes, as would I, but that is beyond the scope of this bug. Not that it
shouldn't be solved, but it seems like you are trying to fix this and bug #15144
at the same time??? I suppose if you can do it, more power to you, I've always
been one for taking things one step at a time though.
>For whom? I think the problem is that those who most want it fixed are also
>those who least can fix it themselves. And vice versa.
Probably because this affects the "average users" much more than the programmers.
>Are you good at graphics? Provide us with better new toolbar items. Not to put
>the circle around them would be a good start, according to mpt.
I'll see what I can do, sure. Should I also try redesigning that hideous "Go"
button? :)
>> No offence, but the screenshot (from January!) in comment #53 looks pretty
>> fixed to me
>It's a good start.
For this bug alone, it's a solution. For the overall toolbar problem, it is a
good start.
I think we have enough here to test and at least mark this bug alone as
complete. I see no reason why we shouldn't do that, then move onto the other
customization/toolbar bugs? Please correct me if I'm wrong.
Comment 119•22 years ago
|
||
Re: Additional Comment #118 From Mike Palumbo 2002-07-11 11:08 -------
> >http://soeren.mystfans.com/mozilla/newchrome/shot-2002-07-11.png
> Looks great overall!
Thanks.
>>> "1. The Toolbar and Address Bar should be split,
>>This is done.
>Then why isn't this bug marked as fixed??
Don't ask me; ask others.
I haven't looked at the other patches, as said. Maybe they're doing exactly what
they should do.
> This bug is only for splitting up the
> Address Bar from the Toolbar, which has been done.
Well, mpt put his spec in *here*, so it appears there is more to this bug in his
opinion.
>>> and the Personal Toolbar renamed to the Bookmarks Bar.
>>This is not yet done.
>This is Bug #48820.
Oh. You're right.
> Yes, as would I, but that is beyond the scope of this bug. Not that it
> shouldn't be solved, but it seems like you are trying to fix this and bug
> #15144 at the same time???
Precisely, I'm trying to implement mpt's spec. Which maybe shouldn't be in this
bug, but in a tracking bug.
> I suppose if you can do it, more power to you, I've always
> been one for taking things one step at a time though.
See above :-)
> Probably because this affects the "average users" much more than the
> programmers.
Yeah. And that's the reason why this isn't fixed yet.
> I'll see what I can do, sure. Should I also try redesigning that hideous "Go"
> button? :)
Sure. That shouldn't be too difficult. If you need advice, ask for it at the
n.p.m.ui newsgroup.
> For this bug alone, it's a solution.
Indeed.
> I think we have enough here to test and at least mark this bug alone as
> complete. I see no reason why we shouldn't do that, then move onto the other
> customization/toolbar bugs? Please correct me if I'm wrong.
I'd be fine with that, assuming that the patch we'll be using causes no
regressions (it shouldn't be that difficult to write such a patch ;-) ).
Comment 120•22 years ago
|
||
To quote from MPT's original report:
"the Command Toolbar and the Location Toolbar should be split into two
separate toolbars."
I think a fix that achieves that should close out this bug. All other
customizations, changes, etc. that are not absolutely required to implement this
change, while important, should be addressed in their respective bugs or
spun-off into new bugs, if none exist. One of my pet peeves is the mega,
morphing bugs that seem to takeover "simple" requests.
Comment 121•22 years ago
|
||
Okay. I've just read through this bug. There's a lot of discussion about
things in addition to the original point of the bug. As far as I can tell, Mike
is right in stating that this bug is ONLY about separating the toolbar from the
address bar.
It's not about customizing toolbars, not about moving toolbars, not about having
multiple toolbars on the same horizontal level, nor is it about changing the
icons on the existing combined toolbar / address bar. Yet it seems to have
become a hot spot for debate on these very topics which is morphing the bug into
something that it's not, never was, and never should be - and all of this is
only causing unecessary delay and frustration.
I see that this bug is marked as blocking 7 other bugs - but is not itself
marked as depending on anything else that still needs to be done. The fix for
this should be simple - then the other ideas can be discussed in other bugs.
If there already is a patch that effects the simple toolbar / address bar split
then it should be reviewed. Why hasn't this happened?
Comment 122•22 years ago
|
||
<q class="ot">A bug is marked fixed when a patch for the bug has been committed to CVS on the specific branch used by the product. for Mozilla Seamonkey (for lack of a better descriptor), that branch is HEAD. No patch attached to this bug has been reviewed, or super reviewed, let alone committed to any cvs branch. As such, this bug is not fixed. If anyone has questions about the life-cycle of a bug that are not answered by the life-cycle of a bug page, please visit irc.mozilla.org #mozillazine and ask for more information. This bug should be focussed on development work, not learning how to use bugzilla.</q>... hyatt isn't working on this bug, if someone is interested in being listed as the assignee they can either take the bug themselves or ask in #mozillazine for someone to reassign it to them.
Assignee: hyatt → nobody
Comment 123•22 years ago
|
||
>If there already is a patch that effects the simple toolbar / address bar split
then it should be reviewed. Why hasn't this happened?
This is exactly what I want to know. I realize that the bug can't simply be
marked as fixed yet because it hasn't been reviewed; I think we all realize
that. The real question here is why have none of the patches been reviewed yet?
We should probably get this reassigned. Hell, I'll even take it if nobody on
the Mozilla team is going to (heh, can I do that?!). I want to see this solved!
We need to get the patches reviewed, forgive my ignorance here, but what do we
need to do to get that to happen? Also, should we make a tracking bug for the
toolbar, since it seems like there is a lot of discussion on the subject?
Comment 124•22 years ago
|
||
> Hell, I'll even take it if nobody on the Mozilla team
> is going to (heh, can I do that?!)
I'm not sure. You could put your name in the field and see what happens. <grin>
Theoretically, I also have the rights to change field information so I could
assign it to you if you can't assign it to yourself - but I don't how
appropriate that would be. So far I've only seen bugs assigned to people that
are part of the actual Mozilla team, and I don't know if just anybody can walk
up and claim a bug or not.
> should we make a tracking bug for the toolbar
Bug 126321 tracks toolbar customization.
Comment 125•22 years ago
|
||
Re: Additional Comment #120 From amutch@tln.lib.mi.us 2002-07-11 11:34 -------
>
>To quote from MPT's original report:
>
>"the Command Toolbar and the Location Toolbar should be split into two
>separate toolbars."
>
>I think a fix that achieves that should close out this bug.
And I don't, because of the following. If we were to fix bugzilla as seen here:
http://bugzilla.mozilla.org/attachment.cgi?id=51851&action=view or here:
http://bugzilla.mozilla.org/attachment.cgi?id=64762&action=view , we would leave
Navigator with lots of wasted chrome space; probably for months seeing how
"fast" the other related bugs are processing.
>One of my pet peeves is the mega,
>morphing bugs that seem to takeover "simple" requests.
And one of *my* pet peeves is the problem that causes them: that Mozilla is
still flawed in many areas. If we fix this and at least bug 15144 few weeks
later, that's fine. But it's not going to happen.
Re: Additional Comment #121 From Jason Bassford 2002-07-11 11:41 -------
> Okay. I've just read through this bug. There's a lot of discussion about
> things in addition to the original point of the bug. As far as I can tell,
> Mike is right in stating that this bug is ONLY about separating the toolbar
> from the address bar.
Yes, of course it is (the summary is clear enough). My point is that doing so
would leave navigator's chrome more broken than it is at the moment, because we
would leave more space for the address bar, but waste lots of space with a
toolbar with only five (!) buttons.
> It's not about customizing toolbars, not about moving toolbars, not about
> having multiple toolbars on the same horizontal level, nor is it about changing
> the icons on the existing combined toolbar / address bar.
True.
> Yet it seems to have become a hot spot for debate on these very topics which is
> morphing the bug into something that it's not, never was, and never should be -
> and all of this is only causing unecessary delay and frustration.
I joined this bug quite late, so this problem wasn't caused by me. One thing
that possibly confused many - including perhaps me - might be the spec from mpt
that's in *this* bug and says "Spec for toolbar arrangement and customization" (!).
Re: Additional Comment #123 From Mike Palumbo 2002-07-11 12:14 -------
> Hell, I'll even take it if nobody on
> the Mozilla team is going to (heh, can I do that?!).
Dunno if you have the permissions (check yourself in your preferences), but I do
have them, so I can reassign the bug to you if you really want to try and fix it.
> We need to get the patches reviewed, forgive my ignorance here, but what do we
> need to do to get that to happen?
See timeless's comment; this is quite clearly described in the "lifecycle of a
bug" documents.
> Also, should we make a tracking bug for the
> toolbar, since it seems like there is a lot of discussion on the subject?
I think this has turned into it, though nobody wanted it to (except perhaps mpt
- was there any special reason behind attaching the spec *here*?).
Re: Additional Comment #124 From Jason Bassford 2002-07-11 12:29 -------
> Bug 126321 tracks toolbar customization.
Well... it appears to be a dead bug though, and it doesn't depend on this one.
Comment 126•22 years ago
|
||
Comment on attachment 66757 [details] [diff] [review]
My take
on reviews please read comment 47
on potential specs mpt posted one in comment 77 (attachment 65067 [details]) and marlon
never mentioned a url for his here.
on what this bug is please read comment 51
on changing text comment 59 trumps, however anyone who objects is also welcome
to read comment 70 and of course comment 47
Given the preceding, i'm marking the current patch as needs-work.
Simply put: module owner and the mozilla.org lead have explicitly stated that
this bug is not the place to change text.
Attachment #66757 -
Flags: needs-work+
Comment 127•22 years ago
|
||
>I don't, because of the following. If we were to fix bugzilla as seen here:
>http://bugzilla.mozilla.org/attachment.cgi?id=51851&action=view or here:
>http://bugzilla.mozilla.org/attachment.cgi?id=64762&action=view , we would leave
>Navigator with lots of wasted chrome space; probably for months seeing how
>"fast" the other related bugs are processing.
BIG WHOOP. Look at IE, same scenario the only two extra buttons: autofill and
mail. Let's do it and put a button for autofill and a button to launch the mail
client.
>and one of *my* pet peeves is the problem that causes them: that Mozilla is
>still flawed in many areas. If we fix this and at least bug 15144 few weeks
>later, that's fine. But it's not going to happen.
You acknowledge that megabugs don't ever go anywhere but you want to create a
megabug out of this by adding 15144? You obviously don't believe, then, that
this is fixable.
Maybe just maybe if we LEAVE the extra space it will put the HEAT on to DO the
other bugs if everyone else is as peeved about the extra space as you are.
Comment 128•22 years ago
|
||
This can't land until toolbar customization is checked in. You're playing with
a much larger beast here than I think you realize. Just changing the chrome
structure of navigator is the wrong way to resolve this bug. The proper way to
fix this is to actually implement toolbar customization, which will allow the
user to set their toolbars how they like, ala IE. Just changing the way the
chrome is hardcoded fixes nothing other than a few users pet peeves.
Comment 129•22 years ago
|
||
Good - better discussion. If the toolbar/address bar is split we'll end up with
a toolbar that has some whitespace.
I personally feel that this should not be the reason for holding things up. A
personal toolbar can have as few as one button, if you've customized it that
way, and I don't see anybody complaining about whitespace problems there. (I'm
sure that there ARE some people with very few buttons in their personal toolbar
- even the screenshots for these patches show such personal toolbars with
whitespace.) The navigation toolbar would be in a similar situation. It may
not look quite right to some, but that can be easily correct later on with the
addition of a few more buttons - to be discussed in another bug. (Having it in
people's faces may even make a fix for that particular problem appear sooner
than it ever would if the issue weren't forced.)
Comment 130•22 years ago
|
||
> This can't land until toolbar customization is checked in.
I don't see this bug being blocked by that one. I also don't agree with the
statement in principle. (It's sort of like saying that at some point in the
future we'll have voice activated, artificially intelligent computers - so why
both manufacturing what will become out of date computers at present?) There
have been other toolbar changes introduced, none of which have had to wait for
customization to happen. Sure, when customization DOES happen, having it will
tend to invalidate several of the toolbar changes prior to it (because they
won't matter anymore) but I don't see that being a problem. In the interim, we
can at least get *some* things working better, rather than not any advancement
at all.
Comment 131•22 years ago
|
||
> In the interim, we can at least get *some* things working better
That's your view, which is why this has to wait. I, along with more people than
you think, like the current layout, and have no need for any of the other
buttons you propose adding. Going back to the way 4.x works is not an
improvement, in my eyes, or appearently in any of the real stakeholder's eyes.
>------- Additional Comment #31 From Blake Ross 2001-10-09 19:03 -------
>
>I agree with Marlon that a change like this shouldn't be made until we have the
>customization features necessary to allow the user to choose. Neil, what do you
>think?
The attached patch is not the correct fix, just a bandaid for those of you who
like a seperate address bar. Once again, the correct fix is to be able to
customize the toolbar to your liking, not checking a hard coded version of how
you like it to look.
Comment 132•22 years ago
|
||
> I, along with more people than you think, like the current layout
The reverse is also true.
> no need for any of the other buttons you propose adding
I've never proposed adding other buttons as a proposed solution to this specific
bug.
Arguing about your personal opinions on this bug at this point is pointless.
All the arguments have been made - on both sides. There are as many people who
want to see this as those who don't. For every comment you can quote to me, I
can quote one back to you. That's not productive.
In the end, if nobody will review a proposed patch and/or drivers won't allow it
to be checked in then that will be what kills it. If you want to continue to
argue against this bug in principle, you should take it the newsgroups. Posts
here should be constructive and/or address *technical* issues.
Comment 133•22 years ago
|
||
> This can't land until toolbar customization is checked in.
Yeah....well suppose you give us an update or some status of where toolbar
customization is at this point. As far as I'm concerned, it's nowhere. Marlon
had said in a bug, months and months ago, that he was halfway through a spec.
In another bug it was stated that toolbar customizaition was "just around the
corner". That corner was probably roughly a year ago. If it's only a few
months away than fine. However I have a feeling that it's nowhere near that
time frame. It would go a long way to help people, and bugs, that keep getting
told wait for toolbar customization if they knew some kind of milestone or year
or sometime when this might become a reality.
> In the interim, we can at least get *some* things working better, rather than
not any advancement at all.
Exactly.
Comment 134•22 years ago
|
||
> The attached patch is not the correct fix, just a bandaid for those of you who
like a seperate address bar
WRONG. It IS the correct fix for this bug, which is about separating the Nav
bar and Adress bar.
Comment 135•22 years ago
|
||
Re: Additional Comment #133 From Tobias Tinkerman 2002-07-11 14:08 -------
> > In the interim, we can at least get *some* things working better, rather than
> > not any advancement at all.
> Exactly.
No, not quite. I can see kerz's point: If we were to implement this, we would
end up with a toolbar with 5 or 6 (dependant on whether Home *will* be moved
with the patch or not) buttons and an additional toolbar with the urlbar and an
optional Go button (and, dependant on the patch, maybe a Search button as well)
on it. Those who like the current layout though - which is a single toolbar with
(except possibly Home) no less buttons, but way less space used, but then again
less space available for the urlbar part - will suffer. So to implement this
wouldn't be a win for everyone.
Re: Additional Comment #134 From Tobias Tinkerman 2002-07-11 14:29 -------
> > The attached patch is not the correct fix, just a bandaid for those of you
> > who like a seperate address bar
> WRONG. It IS the correct fix for this bug, which is about separating the Nav
> bar and Adress bar.
I suppose this bug is invalid or wontfix or whatever then.
Comment 136•22 years ago
|
||
> I suppose this bug is invalid or wontfix or whatever then.
Only if that's what the module owner or drivers marks it as. Until that time,
further discussion should be about how to best implement a patch.
Comment 137•22 years ago
|
||
Actually there are two other alternatives, and I'll mention them even though I
know the UI people would probably have a problem with it with at least the first
one.
Keep the existing combined toolbar, but also implement a Navigation bar and a an
Address bar. Make the default to show the Nav/Address bar, but also have the
possibility of hiding it and making visible the other two separately. That way
those who like it as it is are happy, and those who want the two separate are
also happy.
The other alternative is, if the module owner or drivers would be amenable to
doing this rather than simply marking it WONTFIX if that would be their decision
otherwise, is to make this bug dependant on bug 48926. Work can continue on
this patch until in parallel with any work that might be happening on bug 48926.
As soon as that bug is checked in, then the patch for this one could be checked
in. What this would mean is that the Nav/Address bar IS split in two, but there
would be the option for those who want it of having them joined horizontally and
appearing to be the same as is current. (While those who want one under the
other would also get their way.) Currently that bug is dependant on this one.
That dependancy would have to be reversed. (I.e. We're not separating anything
unless we know that we have the ability to put the two pieces side by side...)
However, as I say, a large part of the decision process will be based on what
the module owner / drivers has to say on this subject. Who *IS* the module
owner here? Is it whoever's "in charge" of XP Apps: GUI Features? I think we
really need some kind of authoritative answer - and hopefully there's just one
voice that will be able to speak up.
Comment 138•22 years ago
|
||
> Marlon had said in a bug, months and months ago, that he was halfway through a
> spec. In another bug it was stated that toolbar customizaition was "just
around > the corner". That corner was probably roughly a year ago. If it's
only a few
> months away than fine. However I have a feeling that it's nowhere near that
> time frame.
According to bug 22056 comment 100, Marlon stopped working on the spec because
the bossy people kept bothering him.
Comment 139•22 years ago
|
||
------- Additional Comment #136 From Jason Bassford 2002-07-11 16:51 -------
> Keep the existing combined toolbar, but also implement a Navigation bar and a
> an Address bar. Make the default to show the Nav/Address bar, but also have
> the possibility of hiding it and making visible the other two separately. That
> way those who like it as it is are happy, and those who want the two separate
> are also happy.
Sounds messy. Don't like that.
> The other alternative is [to reverse dependency with bug 48926 and fix that one
> first, then allow address bar within toolbar]
Yeah, that's better.
> However, as I say, a large part of the decision process will be based on what
> the module owner / drivers has to say on this subject. Who *IS* the module
> owner here?
I thought it's marlon, but I might be wrong.
I just noticed this is assigned to nobody. I thought it was assigned to Neil or
marlon. Strange.
Comment 140•22 years ago
|
||
> According to bug 22056 comment 100, Marlon stopped working
> on the spec because the bossy people kept bothering him.
In which case, we shouldn't be sitting back and waiting for a nebulous,
undefined fix that may or may not be checked in. We should assume that it won't
be happening any time soon and proceed with what we can.
Comment 141•22 years ago
|
||
> I just noticed this is assigned to nobody. I thought it
> was assigned to Neil or marlon. Strange.
It was assigned to Hyatt - until Timeless reassigned it to nobody, around the
time of his strangely formatted comment 122. He said that Hyatt was no longer
working on it. (This is reminiscent of bug 22056 comment 101.)
But even if it's now assigned to nobody - Marlon is the module owner?
>> [to reverse dependency with bug 48926 and fix that one first
> Yeah, that's better.
Unfortunately, according to bug 15322 comment 43 (this bug blocks bug 48296),
work on bug 15322 has been halted in favour of awaiting MPT's spec - which is
now in limbo. If no more work is done on bug 15322, bug 48296 will never be
fixed, and, therefore, THIS bug would still be halted.
I've posted in bug 15322 seeing if work can resume there. (Jason may not have
been aware that progress on MPT's spec had stopped.) If it can be resumed then
I can make the appropriate dependancy reversal between this bug and bug 48296.
Is anybody else as confused as I am? <grin>
Comment 142•22 years ago
|
||
Comment 143•22 years ago
|
||
It seems that this bug is getting hijacked by all kinds of other special
interest wanting to push their own pet-peeve bugs forward. This bug is about the
hopeful url bar seperation, not toolbar customization. If we stop trying to make
this bug into one big fix for the Navigator UI, we might start seeing some
progress for _this bug_.
Maybe we need to make a tracking bug for need Navigator UI changes. Getting a
list of needed Navigator UI changes under one meta bug would be the right
direction to go. At least it is better then spamming this bug.
Sorry for the spam myself!
Comment 144•22 years ago
|
||
hopefully most are aware of the completely sacrilegious nature of this
activity. please remember that this and subsequent changes that are being
proposed, would have to be implemented in a way that would not permanently
affect Netscape, which wants to keep the current design.
toolbar customization is being pushed heavily for the next release. if that
happens, then this work will be mutually benefical. ideally this would be
implemented so that each browser could choose its own default toolbar
arrangement. at least that is the ideal we should be focused on. Let's not turn
this bug into the validity of one design over another, because such a topic is
not winable within confines of a bug.
Comment 145•22 years ago
|
||
Marlon:
Please clarify your position on this bug.
1. Are you saying that Netscape is insisting that this bug (and related bugs)
does not get fixed until Netscape is ready for it to be fixed? (That would be
tantamount to admitting that Netscape controls Mozilla, something that's always
been publicly denied.)
2. Are you in fact the module owner here and, if not, who is?
3. There is no "work" being done here (which may or may not be mutually
beneficial) because this bug, and related bugs, have come to a halt due to
dissension and lack of clarity, often with a perceived lack of adherence to the
procedures in place to address specific bugs. At least that *seems* to be the
case. If it isn't, which bug in Bugzilla *IS* being worked on towards the
implementation of a new toolbar spec that we can look at?
4. Galileo was considered sacrilegeous, yet his was the correct viewpoint. <grin>
Comment 146•22 years ago
|
||
This bug should be marked wontfix imho. People seem to be split on how toolbar
arrangement and customization should be developed. One is to move the address
bar to it's own (this bug) then move on to allow customisation. Then there is
some folks who seems to want customisation first so existing look can be
maintained as default and people change it as they wish. Just two different way
of thinking, I am inclinded to go with the later method, customise first,
leaving changing looks to the user.
This bug basically force interface change (maybe skins too) without advancing at
all towards the ultimate goal (customisation).
Comment 147•22 years ago
|
||
> customise first, leaving changing looks to the user.
Yes, but customization doesn't appear to be happening. If there were a bug
number for it we could go to and get involved with that would be one thing - but
there doesn't seem to be. It's in limbo. In its absence, waiting for something
with not ETA at all (or even visible presence in any form) isn't the right solution.
Besides, as I mention in 137 there are some approaches that could be taken to
accommodate everybody.
Comment 148•22 years ago
|
||
You mean bug 15144? Seem to have some action starting.
Comment 149•22 years ago
|
||
The ultimate goal isn't customization, it is usability. There are serious
usability issues with the current interface. Most of you are already painfully
aware of them. For those who want a refresher, I'll point you to mpt's comments
on this:
http://mpt.phrasewise.com/stories/storyReader$35
Separating the toolbar from the address bar does not preclude maintaining the
current interface look, if that is what users or Netscape prefer. Again, from
mpt's original post here:
"the Command Toolbar and the Location Toolbar should be split into two
separate toolbars. These could be horizontally aligned to achieve the current
layout, or realigned to achieve any of the layouts described above."
The point is that the separation of the toolbar and address/location bar go
hand-in-hand with customization. Now, that doesn't mean that they all need to
be done in the same bug. But they all need to be done at some point.
What good is customization if the only way to achieve a usable location/address
bar is to remove needed toolbar buttons? I think you'll find many users who
think that the toolbar is already horked up by the lack of the home button. But
now I should remove forward and back buttons too so that I can get a location
bar where I can actually see the entire URL? I can't see how that's a solution
at all.
Comment 150•22 years ago
|
||
Maybe I am a bit stupid I don't see how separating the address bar with toolbar
would suddently enhence usability. Does anyone actually can't find the current
address bar to type the url? Didn't think so. In internet explorer I wield them
together to save screen space. It's a matter of opinion on how you like your
address/toolbars. Hence customisation.
Having said that I never said separate the address bar is invalid, but this bug
with it's current patch does nothing to solve the problem while possiblity
introduce some new one. How will user react to the fact now there are even less
screen space without the ability to do anything about it.
It's not about what should be done (we got the spec), we all know the ability to
customis is needed. It's about how to do it with minimal breakage. This bug has
no benefit without the customisation stuff put in place.
What mpt advocate is correctness, elegance and generally great for new users.
But seeing mozilla 1.0 is already released, most user who want to try mozilla
already did and got use to the fact that address bar are together with
navigation buttons. Changing it now will introuduce inconvience to existing user
without an option for them to go back (customisation again).
Comment 151•22 years ago
|
||
>Maybe I am a bit stupid I don't see how separating the address bar with toolbar
>would suddently enhence usability.
See comment 35
Comment 152•22 years ago
|
||
> You mean bug 15144? Seem to have some action starting.
No, I hadn't meant that one specifically - but thanks for pointing it out. I'd
been following bug 116183 instead, which looks like it's a duplicate.
In any case, ALL of these changes are just subsets of what we'd like to see
happen. Rearranging buttons is just one of the steps towards implementing a
properly usable (configurable) UI. Moving / splitting / joining / aligning
toolbars (in addition to buttons) is another part of it. Moving buttons is a
necessary but still insufficient part of the whole.
Ideally what I'm looking for is a meta tracking bug for UI customization /
usablity. If I only hear about work on MPT's spec being stopped because of
somebody's "boss", and I can't find a bug that directly relates to it, and
nobody will step in and claim ownership of this particular module, (plus I read
a comment from Marlon about how this bug is somehow a sacrilege against
Netscape's plans, without an explanation of what those plans are, where they can
be found, or why Netscape should have exacting control over Mozilla in this
regard) then it's frustrating because the whole project is in some shadow realm
that neither I nor anybody else not directly involved in it can gain access to.
Whereas, with THIS bug, which is a small but still necessary component of the
overall changes we want to see, I CAN get involved.
But, again, discussion has been sidetracked. Can we get back to the question of
a patch for this specific bug?
> In internet explorer I wield them together to save screen space.
bug 48926
> It's a matter of opinion on how you like your address/toolbars.
> Hence customisation.
Again, the point is that there *IS* no one, single, bug for "Customization".
Not even, as far as I can tell, a meta tracking bug for it. So it's impossible
that, suddenly, all of the pieces could just fall together.
The mass of separate bugs on this issue, in a synergistic whole, seem to
comprise what everybody wants. But some people don't want to work on A unless B
is first done. While other feel the reverse it true. With that perspective,
neither A *NOR* B will ever be finished. So work has to be finished on each bug
as it comes along. In the end they will all fit together. This isn't, and it
*CAN'T* be an all or nothing process. (Not unless you choose to go the
"nothing" route, and I don't think that's what anybody wants.)
But, again, discussion has been sidetracked. Can we get back to the question of
a patch for this specific bug?
Comment 153•22 years ago
|
||
Aaron if you open mozilla in 800x600 you'll see that if we separate the address
bar now the content area will only have around 60% of the screen height. I would
be much more annoyed that the length of the address bar.
Jason I just created a tracker bug 157199. It's not yet confirmed but hey, it's
a tracker bug if needed. Not hard.
Comment 154•22 years ago
|
||
Other than Mozilla, name ONE browser that puts the URL bar on the button bar.
You can't.
So why is it so all-fired important to keep the URL box in the button bar?
Home and Formfill buttons can be added, if you like.
If Mozilla went away I guess Mike Tseng and Mike Lee wouldn't have a browser to
use...
Comment 155•22 years ago
|
||
>Aaron if you open mozilla in 800x600 you'll see that if we separate the address
>bar now the content area will only have around 60% of the screen height. I would
>be much more annoyed that the length of the address bar.
That figure is entirely dependant on what OS, how big the taskbar is, and how
many toolbars, etc. are enabled in Mozilla. The whole point is that a person
can *eventually* be able to move and combine the status bars, etc. But we need
to take this one step at a time.
I personally am confident that if we get one of these patches reviewed, and get
it put into CVS, the customization and layout issues that other people here are
talking about will be soon to follow. Getting the address bar on a separate
line will put pressure on the owners of the other bugs to get them fixed! Even
if we don't get full address bar customization immediately, we can at least fill
in some of the blank space with a Home button (which is bug 89350), etc. This
will help to put pressure on the layout. (speaking of which, I am working on one
as we speak, as per comment #113.)
This should NOT be marked as WONTFIX or any other silliness. Sure, if we
immediately put the address bar on its own toolbar, the navigation might look
silly for a few weeks. But just look at how this thread *exploded* with
activity. If we keep up the discussion and the work, we can get these issues
solved. One step at a time though, this bug is blocking 7 others. Let's just
get it reviewed and in the CVS, I say!
No longer blocks: 157199
Comment 156•22 years ago
|
||
Added all dependencies on toolbars / buttons I could locate for the
meta-tracking bug 157199. It came to 22 different bugs! As you can see, there
is no single bug that, once fixed, enables customization. <grin>
Mike Palumbo: I'm with you, man!
Comment 157•22 years ago
|
||
Yeah, I agree with you Mike Palumbo. We have to start somewhere, and this bug is
a good start. Maybe this can get into the trunk sometime after the 1.1 branch?
Comment 158•22 years ago
|
||
I don't think you people realize what a can full of worms this bug is.
Not only is it about the most controversial aspect of Mozilla; its UI, it is
also about the lack of enforcement of volunteers' UI design specs (mpt's, in
this case) and the inability / reluctance for drivers to tackle this issue.
That said, I don't think you make it easier for yourselves by morphing this into
an even more huge bug which will solve all other UI bugs in bugzilla.
Comment 159•22 years ago
|
||
Please do not SPAM this bug. Keep discussion to technical merits / detriments
of patches to address Nav/Address toolbar separation only. Arguments against
this specifically, and UI in general, should go to newsgroups.
Others: From now on let's try to simply ignore further debate teasers and keep
ourselves focused on the task at hand.
Comment 160•22 years ago
|
||
Patch status:
With all of the "discussion" it's easy to lose track. Is there a patch that's
been submitted that proponents of this bug agree upon? With the exception of
the addition of a "Go" button (that's not part of the original Nav/Address
toolbar) http://bugzilla.mozilla.org/attachment.cgi?id=64762&action=view looks good.
This specific bug shouldn't be about adding anything else. In fact we might
want to remove the "Go" button, but if nobody else thinks so I'm happy with its
inclusion.
Does that screen shot have a corresponding patch submission?
Comment 161•22 years ago
|
||
>With the exception of the addition of a "Go" button (that's not part of the
>original Nav/Address toolbar)
>http://bugzilla.mozilla.org/attachment.cgi?id=64762&action=view looks good.
>
>This specific bug shouldn't be about adding anything else. In fact we might
>want to remove the "Go" button, but if nobody else thinks so I'm happy with
>its inclusion.
The GO button has been around for quite some
time now. It is not an addition. Through the preference panel, it can be
hidden or shown. The separation of the toolbar and address bar should not add
or remove features including this one.
Comment 162•22 years ago
|
||
> Through the preference panel, it can be hidden or shown.
Oh, good - so it's presence would still be linked to the preference. It wasn't
entirely clear from the screenshot (obviously) if it was hardcoded or just
enabled in that instance. I agree totally that nothing should be removed or
added from what we have now.
Comment 163•22 years ago
|
||
Note: This needs the updated btn1.gif to work in Modern.
It appears to work in Classic but you'll probably want the new home gifs.
Attachment #66757 -
Attachment is obsolete: true
Comment 164•22 years ago
|
||
Effort appreciated, but we don't want a home button as part of a patch for this
bug. A home button is addressed in bug 89350. We don't want to add or remove
ANY features from the existing Nav/Address toolbar for the purpose of solving
this one particular bug...
Comment 165•22 years ago
|
||
Comment 166•22 years ago
|
||
Excellent!
Can you also attach this patch to bug 157199 and name it "Patch for bug 49543"?
We want to track the patches for each part of MPT's spec in that meta bug also.
(Ideally, having not only each sub-component patch but also a "meta patch"
based on the combination of all of them. That way MPT's spec can be reviewed
not only on a piecemeal basis but also as a whole.)
I'm tempted to mark all other patches, MPT's spec, and screenshots of things
like home buttons as obsolete since they don't apply to this bug directly and
only confuse the issue. But will wait for feedback from others on that.
Comment 167•22 years ago
|
||
> I'm tempted to mark all other patches, MPT's spec, and screenshots of things
like home buttons as obsolete since they don't apply to this bug directly and
only confuse the issue. But will wait for feedback from others on that.
They don't belong here at all, but they're still important. Maybe they (the most
important from them) should be linked to in a comment in the meta bug.
Comment 168•22 years ago
|
||
Linking them to the meta bug make sense. But can't we do that while still
removing them from this bug? I'm just now downloading / uploading MPT's spec so
that I can attach it directly to the meta bug and obsolete it from this one.
Other bugs should be handled in a similar fashion where appropriate.
Comment 169•22 years ago
|
||
Re: Additional Comment #168 From Jason Bassford 2002-07-15 07:45
> But can't we do that while still removing them from this bug?
Does marking an attachment obsolete remove it? I don't think so.
Comment 170•22 years ago
|
||
> Does marking an attachment obsolete remove it?
No, annoyingly enough. Nor do I seem able to even obsolete an attachment
without first creating a new one. I guess that for now we'll just have to live
with copying appropriate attachments over to the meta bug and trying to ignore
extraneous attachments here. I've made a first start.
Comment 171•22 years ago
|
||
Comment on attachment 65067 [details]
Spec for toolbar arrangement and customization
You have to hit Edit to obsolete attachments.
Attachment #65067 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #64824 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #64763 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #64825 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #64826 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #74549 -
Attachment is obsolete: true
Updated•22 years ago
|
Attachment #91327 -
Attachment is obsolete: true
Comment 172•22 years ago
|
||
What is the status of "Patch v2"? Is this an alternative to the most recently
created, or is it now out of date?
Comment 173•22 years ago
|
||
mpt's specs (attachment from 2002-01-15) don't include a *Print* button. Why
not? Has there been a discussion on this. I would think most "common" users
(incl. my parents) would _much_ more often want to "Print" than "Edit" (which
strangely is included in his specs). I strongly disagree with this part of the
"spec". I also realize that this is not the right place to discuss this issue.
So ... where can I bring up my objections to this part of mpt's (otherwise good)
specs?
Comment 174•22 years ago
|
||
------- Additional Comment #173 From Peter Lairo 2002-07-15 11:38 -------
> mpt's specs (attachment from 2002-01-15) don't include a *Print* button.
Not true. It's just not mentioned. Quote from IRC:
<mpt> Oh yes, there are lots of buttons that would be off by default
<mpt> Print, Save, Zoom, Encoding, Style, Preferences, New Window ...
> Has there been a discussion on this.
I don't think so.
> I also realize that this is not the right place to discuss this issue.
> So ... where can I bring up my objections to this part of mpt's (otherwise
> good) specs?
netscape.public.mozilla.ui, as has been mentioned several times.
Comment 175•22 years ago
|
||
Comment on attachment 91339 [details] [diff] [review]
Just the basic split
>+<!ENTITY locationToolbar.tooltip "Location Toolbar">
Elsewhere in the UI, it's simply referred to as the 'Location Bar'.
Comment 176•22 years ago
|
||
> (From update of attachment 91339 [details] [diff] [review])
>> +<!ENTITY locationToolbar.tooltip "Location Toolbar">
>
> Elsewhere in the UI, it's simply referred to as the 'Location Bar'.
Elsewhere in the patch you mean? It can't be the rest of the UI because the
Location Toolbar is a new toolbar, are you confusing it with the URLbar?
Sorry about that, it's a mistake from undoing the renaming to Address Bar.
<!ENTITY locationBarCmd.label "Location Toolbar"> is correct.
Comment 177•22 years ago
|
||
>> (From update of attachment 91339 [details] [diff] [review])
>>> +<!ENTITY locationToolbar.tooltip "Location Toolbar">
>>
>> Elsewhere in the UI, it's simply referred to as the 'Location Bar'.
>
> Elsewhere in the patch you mean? It can't be the rest of the UI because the
> Location Toolbar is a new toolbar, are you confusing it with the URLbar?
Yeah, probably. I meant in places like the Preferences where it's referred to as
the "location bar". But I guess that's just referring to the actual text field.
> Sorry about that, it's a mistake from undoing the renaming to Address Bar.
> <!ENTITY locationBarCmd.label "Location Toolbar"> is correct.
Looks like that. I checked 4.x and it uses 'Location Toolbar' so you're right.
Reporter | ||
Comment 178•22 years ago
|
||
*** Bug 43739 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•22 years ago
|
Attachment #65067 -
Attachment is obsolete: false
Reporter | ||
Comment 179•22 years ago
|
||
Comment on attachment 91339 [details] [diff] [review]
Just the basic split
Marking needs-work, since it doesn't move the Home and Search buttons. (I
suggest obsoleting this patch in favor of attachment 91327 [details] [diff] [review].) The split+move
would make Navigator more usable for perhaps a few tens of millions of people,
and less usable for perhaps a few tens of thousands of people.* (That's one of
the reasons why it should be done regardless of any customizability.) For
split-by-itself, however, this would not be the case: the only immediate
improvement would be the lengthening of the address field, which wouldn't be
enough to justify the loss of vertical content area.
To fix this worst UI problem in Mozilla, there are two possible approaches.
(1) Wait for Netscape to fork the UI, so that those acting to minimize the
number of Mozilla/Netscape/etc users (Netscape UE) are no longer sabotaging the
work of those acting to maximize the number of Mozilla/Netscape/etc users (most
other contributors). The current toolbar layout makes Netscape much harder to
use, so Netscape want to retain it (comment 144). This is why, for example,
they claim repeatedly that this bug is dependent on toolbar customizability
(e.g. comment 45, comment 50, comment 128), when such a claim is the exact
opposite of the truth (comment 33). They know what they're saying is complete
garbage (it is disproved by almost all other browsers, including 4.x), but the
resulting talkfest achieves its purpose of delaying this bug.
(2) Get a patch reviewed, and super-reviewed by a module owner, neither of whom
are subject to Netscape's chilling effect. For r=, there are plenty of
candidates. For sr=, Hyatt is the obvious choice, since (a) he is one of the
module owners for the Navigator front end (Marlon is not), (b) he isn't
employed by Netscape, and (c) navigator.xul begins with an order to get
sr=hyatt for any changes. :-)
I suggest approach (2), since if you try (1) you'll go old and gray, and
Mozilla's UI will get worse in other places while you wait. (I should know, I
tried it for a few months recently.) While that is happening, PLEASE DO NOT
SPAM THIS BUG REPORT unless you are (a) attaching a patch or (b) reviewing a
patch.
* Yes, these are guesses based on heuristic evaluation. That's what I deal in.
Some things can't be measured using jprof.
Attachment #91339 -
Flags: needs-work+
Comment 180•22 years ago
|
||
Sorry for the spam, but there are working patches up here; who can we get to
review them? I refuse to see this bug become stagnant.
Comment 181•22 years ago
|
||
Well, if you read bug 161857, it would seem that the add/remove buttons panel
is going to be removed in favor of toolbar customization. If that actually
ever happens, so this bug will most likely be fixed once (if) that really
takes place.
"------- Additional Comment #4 From Blake Ross 2002-08-09 00:19 -------
We are getting rid of that toolbar pref panel, to be replaced by toolbar
customization (actual, real, non-lame toolbar customization.)"
You could also try a build of Phoenix. That already has basic customization
implemented already (although sadly you still can't remove the url bar from
the nav bar to it's own line, at least in the build I used).
Or you could also just give up on this bug and it's blockers and all the
jibber-jabber and patches that just get denied/ignored and just turn to using
IE instead as I have.
Comment 182•22 years ago
|
||
> If that actually ever happens, so this bug will most likely be
> fixed once (if) that really takes place.
There is no guarantee that it will ever happen. How can we be expected to close
this bug in the meantime? It's not a duplicate of "Phoenix" (this one was
opened first and Phoenix is not expressed as a bug number in Bugzilla in any
tangible fashion), which *appears* to be closed-source to a few number of
developers who are working on their own without communicating much of anything
back to the community about intentions, target milestones, or methods of
approach. Yes, you can download some recent builds and see some screenshots -
but nothing has yet been stated as to how / when any of it will be incorporated
into Mozilla.
In the absence of anything definite, it can only be treated as "vaporware" as
far as Mozilla itself is concerned. Perhaps not as far as the developers in
question are concerned, but certainly as far as anybody not directly involved is
concerned.
> Or you could also just give up on this bug and it's blockers and all the
> jibber-jabber and patches that just get denied/ignored and just turn to using
> IE instead as I have.
That doesn't help either. This is a Bugzilla entry and should be discussed on
its own merits. Expressions of curiosity / desire for forward momentum here is
understandable and the way that things should work.
If the people at Mozilla who are responsible for controlling check-in approval
of the various bugs open on toolbar customizability KNOW that they are working
on something else that will one day (soon I hope) appear in Mozilla full-blown
due to this work, and they know that patches to these existing Bugzilla bugs
will not ever get approval - then they should just close all of these bugs as
WONTFIX or INVALID and save everybody the bandwidth.
However, so far none of the module owners have taken responsibility for any of
these bugs - nor is there even a concensus (or admission) of who the module
owners happen to be. The lack of any such communication means that there is no
official mozilla.org stand on these issues, so they remain open. While they
*DO* remain open, they should be treated just as any other bug...
Comment 183•22 years ago
|
||
> this bug in the meantime? It's not a duplicate of "Phoenix" (this one was
> opened first and Phoenix is not expressed as a bug number in Bugzilla in any
> tangible fashion), which *appears* to be closed-source to a few number of
> developers who are working on their own without communicating much of anything
> back to the community about intentions, target milestones, or methods of
> approach. Yes, you can download some recent builds and see some screenshots -
> but nothing has yet been stated as to how / when any of it will be
> incorporated into Mozilla.
No, Phoenix is not a bug number in Bugzilla. It is a "product name", so you can
go to the Bugzilla query page and select Phoenix to see all Phoenix-related bugs.
It is not closed-source, either. I've been building and using it since it came
out. The source _is_ part of the mozilla tree and can be pulled with cvs.
IMHO, in the end, it doesn't really matter whether any of it gets into the
default mozilla/netscape "build". The source is out there, and distributions
like Red Hat will ship whatever they want to ship. (From the current beta, it
looks like RH 8.0 will ship mozilla for browser and evolution for email. I won't
be suprised if the next version uses Phoenix plus Xft support.)
This bug is just over 2-year-old, bug 15144 is approaching 3 years old, and bug
89350 was just WONTFIXed. I've given up on this and all related bugs. It is
quite clear that "they" simply won't fix these bugs.
Sorry for the spam. Anyway, I hope Phoenix will become what we all want.
Updated•22 years ago
|
Whiteboard: [geekweb-fixed]
Comment 184•22 years ago
|
||
If people want to fix this, it would be _easy_. You need just take the phoenix
code and port it to the xpfe codebase.
Comment 185•22 years ago
|
||
Hixie: Only once it's working properly in phoneix, of course -
currently it does nasty things with window.open flags, for instance...
Comment 186•22 years ago
|
||
there's no point in discussing the code here. it wouldn't matter if it was a one
line change; this bug isn't going to go anywhere until someone who can authorise
significant UI changes makes a decision to allow it to happen...
Comment 187•22 years ago
|
||
Who's against it?
Comment 188•22 years ago
|
||
Netscape. See comment 144.
If this is wanted, I could attach a patch as well. See
<http://www.developer.beonex.com/beol>, this bases on Communicator codebase.
Creating this separation was not that hard. Code isn't the problem here.
Comment 189•22 years ago
|
||
FYI, so that nobody misunderstands my last comment: IMO, it is totally OK that
Netscape is against this change. It is a controversial decision (I'd guess that
many Mozilla users would disagree with this bug as well), and Netscape opted
this way. Keeping Mozilla close to Netscape 7 makes IMO sense, at least in this
case. I agree that toolbar customization is what's wanted, and with the Phoenix
work, we are now closer than ever (actually, IMHO that's the coolest thing of
Phoenix at all). All we now need, basically, is the Phoenix implementation to
settle and then merged with or ported to Mozilla. (Right?)
Comment 190•22 years ago
|
||
Gee, I hear Netscape may be interested in Phoenix features such as this one.
Times do change. Someone should do a patch that works, doesn't regress default
appearance, and doesn't hurt tinderbox performance numbers (much; drivers will
negotiate). Then we can talk.
Sitting here fretting about something someone from netscape.com said a while ago
doesn't do anyone any good.
/be
Comment 191•22 years ago
|
||
NS does want toolbar customization, and this could be part of it. ->module
owner, nominating for Buffy, cc patricec (who is our browser UE rep).
Comment 192•22 years ago
|
||
Always makes me wonder about this bug why it isn't marked as depended on bug
15144. Let's be honest. There are valid objections to that dependence (see
comment 33) but, since Netscape has decided to give priority to customization, I
see no point on insisting the opposite. A dependence field might not be that
important to the resolution of this bug but, at least, would prevent whining on
the lack of progress.
Comment 193•22 years ago
|
||
As Peter mentions in #191, the separation of the Location Toolbar is part of the
next release.
Comment 194•22 years ago
|
||
Nav triage team: nsbeta1+/adt1
Comment 196•22 years ago
|
||
Marking nsbeta1-.
Comment 197•22 years ago
|
||
What will happen with this bug when Mozilla 1.5 is launched?
Mozilla 1.5 will have customizable toolbars in the browser and mailnews.
Comment 198•22 years ago
|
||
As with all bugs in this situation, the reporter is free to close it as INVALID
or WORKSFORME if they feel that the problem is no longer pertinent to the new
browser engine. (Or they can leave it open if they still want the Seamonkey
engine fixed.)
Comment 199•22 years ago
|
||
it is my hope that seamonkey will still be maintained. I would, therefore, not
resolve this bug until it is clear that that is not the case.
Comment 200•21 years ago
|
||
a separate url bar is the most critical feature missing from mozilla/netscape
Comment 201•21 years ago
|
||
the point of having a url bar is that it shows the url. currently, the url bar
does not show the url. it shows http://bugzil and http://www.go (there is no
way of determining or modifying which url you are at without maximising the
screen). ever tried navigating without knowing your location? so judging by the
dates on these comments, the people responsible for the UI of this product have
for the last 2 years, either been using internet explorer, been dividing their
desktop into 1600x600 slabs, or have never typed in anything beside a domain name.
Comment 202•21 years ago
|
||
Once Firebird is finished, and Seamonkey no longer needs to be maintained
because Firebird is everything Mozilla was and more, and becomes Mozilla, won't
this bug be irrelevant?
Comment 203•21 years ago
|
||
thanks.
yeah firebird is goodstuff and it solves this issue
http://www.mozilla.org/projects/firebird/
Comment 204•21 years ago
|
||
yeah and it was a joke - not directed at anyone - i have just been looking for a
UI fix for a long time.
you open source people do a good job.
Comment 205•21 years ago
|
||
Is there *anything* I can do to get this patch into the nightlies ?
I agree with Comment #120.
There's a patch that fixes this bug.
Get the patch into the nightlies,
mark this bug fixed,
and move on.
I disagree with Comment #128.
If a quick hack can make "some users" happy, let's do it.
I basically agree with #202:
Once the "latest testing release" browser at
http://mozilla.org/
fixes this bug, then this bug can be marked fixed.
-- David Cary
Comment 206•21 years ago
|
||
Re comment #205
I have been reading the book called "Rapid Development" by Stephen McConnel
(about project management and how to avoid mistakes), and that paired with my
experience on this project has made me change the stance on that as of the last
year or so. Checking in "quick fixes" has turned the codebase into a beast like
Jason Kersey said and I think we want to move now with the new Roadmap direction
to something more deliberate with plan schedules for inclusion of features and
strict checkin management (especially with Firebird) or we will just have
another mess. If you want to see this in action, just watch successive windows
releases. It says in the book that doing something wrong the first time can
cause 10 times the man hours down the line. It makes sense because new code will
depend on the incorrect code as it is added.
Besides the fact the patch is over a year old and already said it needed work,
putting in a fix like this would mean that we would have to come up with a plan
to implement this correctly. An, "Let's do the hack now and fix it later" rarely
works as outlined in the book "Rapid Development". If you can come up with a
schedule for doing it right, and find someone who will agree to follow the
schedule, then it might be OK. Otherwise, what will probably happen is someone
will have to rewrite everything down the line, or it could cause maintenance issues.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 207•17 years ago
|
||
Resetting A+QA after more than 4 years since last comment, more than 5 since last patch.
I expect this bug to wait till after toolkit customization of toolbars is brought over to SeaMonkey (and maybe some more) -> changing dependencies to reflect that. Please undo if I goofed.
Updated•16 years ago
|
Assignee: nobody → jag
Priority: P3 → --
QA Contact: guifeatures
Comment 208•16 years ago
|
||
Actually fixed by Bug 394288 since you can now create additional custom toolbars and then drag and drop the urlbar on to it or any other customizable toolbar in the toolbox.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•