Closed Bug 244099 Opened 17 years ago Closed 15 years ago
Make Google/Search resizeable
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; (R1 1.1); .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: I need a way to make the Google/search input box a bit smaller. I love that resizing feature on Safari: I have its Google input box always on minimum size which is enough for the few times I am using it, and by doing that I am saving real screen estate for the URL bar which users are using more in comparison. Currently, your google/search input box is 150 pixels long, which is too much for my taste. Please either consider make it 90pixels long (on iBooks it is important to be able to have full URL view), or make it as Safari does and give us the option to resize that search box. Reproducible: Always Steps to Reproduce: Actual Results: Too long input box for its own right and for the limited use it gets. Expected Results: I would like it at 90 pixels instead of 150. Or, make it resizable.
I do not agree with you that the Search input field should be made smaller. It's so small now that many words get clipped at a certain point. On the Mozilla Forum mnay people are actually requesting to enlarge it. I altered the title of this bug to "make it resizabele" so all parties are content. Mike and the guys what do you think?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Google/Search input box is too large → Make Google/Search resizeable
i do not believe that we can use a NSToolbar and do this, the OS just can't do it. While i agree with you, we'd have to rewrite the entire toolbar from scratch. I'll future it because it is a nice to have, but i don't see it ever happening.
Target Milestone: --- → Future
Just out of curiousity, an idea.... I remember on the forums we were saying that for that to work, the Location and Search items would have to be one toolbar item, and some people might not want that. However, would it be possible to combine them into one, with a resize thing in between, that would allow either part's width to = 0? For example, if you drag the resizer all the way to the right, then the Search would be invisible. And if you want it back, you can drag it back. So would it be possible to combine Location + Search into one toolbar item and have a resize widget in between them? Or is that still essentially the same as rewriting the entire toolbar code?
I attached a nib file containing two split view containing textfield to show it's very easy to create such a thing in IB, it's 10.2 compatible by the way.
It looks to me like what we should do here is replace the location bar with an NSSplitView that contains both the location bar and a search bar. Anyone else have a better idea? cl
(In reply to comment #5) > It looks to me like what we should do here is replace the location bar with an > NSSplitView that contains both the location bar and a search bar. Forgive the ignorant question, but would that allow people to remove the search field (or location field) independently of each other?
No. Basically, what I have in mind is something like what Safari does, except we'd allow the user to minimise the search field all the way to nothing, so the only thing left at the far right end of the location bar would be the resize widget. Safari only allows the search field to be shrunk down to ~100px wide and then refuses to go any smaller. My general feeling is that changing it will help more people than it will annoy, but those of you who've been triaging bugs for a while probably have a better handle on this. cl
(In reply to comment #7) > No. Basically, what I have in mind is something like what Safari does, except > we'd allow the user to minimise the search field all the way to nothing Hmm, I see Safari 1.3.x actually lets the search field be removed independently of the location field (but the location field removes the whole toolbar!?). That said, your solution sounds like a good compromise if the two cannot be removed independently of each other.
(In reply to comment #8) > Hmm, I see Safari 1.3.x actually lets the search field be removed independently > of the location field (but the location field removes the whole toolbar!?). Safari 2.0 seems to permanently conjoin the two as one item. If one is present, both must be. I wonder if it's a change in how Panther vs. Tiger handles the NSSplitView class, or if the later versions of Safari has implemented it differently (or both). Regardless, the behaviour of Safari 2.0 is what I'm suggesting, albeit with a fully collapsible search field. > That said, your solution sounds like a good compromise if the two cannot be > removed independently of each other. Like I said, Jasper suggested the split view. I'm far from an Interface Builder expert, so if there's a better way to handle this, I'm all ears. It was also suggested on Mozillazine that we take a look at how Shiira implements this, which I'm about to do. cl
Safari 1/2 don't have a native toolbar so they can do what ever they want, we do have a real toolbar so we will bump into some limitations. Shiira uses a textfield which has a resize handle incorporated at the left side, which in my opinion isn't very intuitive as you will only run into it by accident. I think the idea of having a textfield splitview would be best. And I also think it's a good idea to allow the user to minimise the search field all the way to nothing. I'd bet 95% of our users have the search bar visible at all times, maybe some have it on a different location on the toolbar, that's just to bad.
(In reply to comment #10) > Safari 1/2 don't have a native toolbar so they can do what ever they want FYI, that's not true of 2.
It is as far as I can tell, just open the browser.nib of safari and you will see that all the toolbar icons and what not is in the nib file. I know it looks and behaves like a real toolbar, but I have never heard of one where it was done in a nib.
If the location bar and search bar were one "item" allowing the search bar to be "hidden" by resizing it really small instead of actually removing it from the toolbar, wouldn't this cause an extra "phantom tab" when tabbing from the location bar into content? That doesn't seem user-friendly.
(In reply to comment #13) > If the location bar and search bar were one "item" allowing the search bar to be > "hidden" by resizing it really small instead of actually removing it from the > toolbar, wouldn't this cause an extra "phantom tab" when tabbing from the > location bar into content? That doesn't seem user-friendly. Smokey mentioned that yesterday on MZ. I don't know enough about NSSplitView (yet) to answer this one way or another, although it seems to me that the logical way to handle it would be to skip over any fully collapsed children of NSSplitView in the tab chain. Whether or not NSSplitView does this by default, I have no idea, but it also sounds like it might not be *too* hard to work around if it doesn't. cl
*** Bug 312558 has been marked as a duplicate of this bug. ***
Is there any particular reason we should be concerned with making this work on 10.2? If not, I'm going to concentrate on fixing this with bug 330666 in mind. cl
Assignee: mikepinkerton → bugzilla
landed trunk and branch.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: Future → Camino1.1
Verified on trunk.
Status: RESOLVED → VERIFIED
For housekeeping purposes, assigning to pink so it doesn't look like I did anything here and pink's the one who actually fixed it.
Assignee: cl-bugs-new → mikepinkerton
QA Contact: toolbars
You need to log in before you can comment on or make changes to this bug.