Closed Bug 158246 Opened 22 years ago Closed 21 years ago

Implement Search functionality into URL Bar (and autocomplete?)

Categories

(Camino Graveyard :: Location Bar & Autocomplete, enhancement)

Product:
Camino Graveyard
Component:
Location Bar & Autocomplete
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino1.5

People

(Reporter: neilio, Assigned: mikepinkerton)

References

Details

Attachments

(3 files, 8 obsolete files)

gg: for google search in address bar
4.62 KB, patch
Details | Diff | Splinter Review
gg: for google search 2
1.75 KB, patch
Details | Diff | Splinter Review
Yet another unified patch
37.68 KB, application/gzip
Details 
Please add in address bar searching (like Mozilla has) - I really miss this from
IE and Mozilla. I suppose at some point being able to set the search engine
searched would be nice, but if it was set to Google first I'm sure few would
complain :)
Confirmed using Chimera/20020718.
Severity: normal → enhancement
Summary: Add Address bar search (to google?) → Implement Search functionality into URL Bar (and autocomplete?)
Summary: Implement Search functionality into URL Bar (and autocomplete?) → [RFE] Implement Search functionality into URL Bar (and autocomplete?)
*** Bug 167176 has been marked as a duplicate of this bug. ***
to default owners
Assignee: saari → pinkerton
Component: General → URL Bar & Autocomplete
QA Contact: winnie → sairuh
Status: NEW → ASSIGNED
With this patch you can do gg:your search in the address bar and it'll search
google.
Comment on attachment 100283 [details] [diff] [review]
File with "standard" US google searching from toolbar

messed up patch
Attachment #100283 - Attachment is obsolete: true
This works great.  For now though it only does a "standard" US google search.
With this patch you can type gg:your search in the address bar and do a search.
 Right now it's only set for a "standard" US google search, but I think you get
the idea.
simon, what do you think about this?
Target Milestone: --- → Chimera1.1
I think that some kind of search via the url bar would be good. I'm not sure if
that should be bookmark keywords, or something like this.
Summary: [RFE] Implement Search functionality into URL Bar (and autocomplete?) → Implement Search functionality into URL Bar (and autocomplete?)
I was thinking of implementing this myself earlier, and this was the plan I had:

Make a plist using Property List Editor. In the list, place an entry for every
search site you want to use with its name. Make these entries strings with the
value of the URL needed to search using that site. So for AltaVista, dmoz,
Google, and Yahoo, you'd have:

{
    "Alta Vista" = "http://www.altavista.com/sites/search/web?q=%SEARCH_STRING%"; 
    "dmoz" = "http://search.dmoz.org/cgi-bin/search?search=%SEARCH_STRING%"; 
    "Google" = "http://www.google.com/search?q=%SEARCH_STRING%"; 
    "Yahoo" = "http://search.yahoo.com/search?p=%SEARCH_STRING%"; 
}

So load that plist on application load, and whenever they choose to search (via
the last item in the location bar a la Mozilla, I guess), just replace
%SEARCH_STRING% with whatever's in the Location bar (using simple NSString methods).

I guess this is similar to Bookmark Keywords, but I don't know. It's nice
because you can write a general search procedure and then add as many search
engines as you want by simply editing this file (thus giving customizability to
power users that just HAVE to have their search engine included). Also, it's
trivial to load the contents of the plist into a popup menu so someone can
change their search engine in a pref.

Don't know the differences between this and browser keywords though. 
*** Bug 172643 has been marked as a duplicate of this bug. ***
To me the Mozilla search on the url bar is the best, I just type anything, press
up and enter.
So how do bookmark keywords work?
This is a tip for all of you that have been wanting to get a toolbar search
item. You probably never new it was already there?

It works on the keyword feature the devs ahve finaly enabled in last weeks
nightly builds. This is how you "activate/do" it:

1. Create a new bookmark, give it a name, and make the URL   
http://www.google.com/search?q=%s

2. In the bookmark info window, give it a keyword "?" or something like that,
enything that seems to be handy.

3. type "? search terms" in your location bar to search.

Voila now you have a search toolbar item a la Internet Explorer. But a you may
have seen you could change the keyword into anything you want (search: / huh! )

These URLs can be used the same way:
http://www.imdb.com/Find?%s
http://www.versiontracker.com/mp....arch=%s
http://search.dogpile.com/texis/search?q=%s&cat=web&top=1
http://yp.yahoo.com/py....&desc=s

You can go further than this. Set up a tab group, with different
search engines in each tab. Set up a URL for each search engine
with a %s. Now put the keyword *on the tab group itself*. Then
typing "? foo" will open up the tab group, searching for "foo"
in each tab. Neat eh?

credits: Simon Fraser & credits: netsmiley.
http://www.eternaltedium.com/cgi-bin/chimeraboard/ikonboard.cgi?s=3dedcb2a3507ffff;act=ST;f=8;t=248
While the hint is definitely nice (and I'm using it to search Google now), this
issue still exists. Many have commented on how they would like an implementation
of this using the same UI as Mozilla (Just type the search text in the location
bar and choose the last item in the autocomplete popup). 

Perhaps we can use some combination of bookmark keywords (transparent to the
user) with an item at the end of the autocomplete popup that will search using
the text in the location bar? 

Any ideas?
*** Bug 190179 has been marked as a duplicate of this bug. ***
Search keywords are the "answer" to this bug, but they need to be more accessible.

What if

1) We have a new special bookmarks folder, Search Bookmarks (like Toolbar
Bookmarks) that comes preloaded with all kinds of great keyword searches.

2) A curved edge search entryfield is an optional toolbar component with a
magnifying glass icon (like Mail, et al) whose dropdown list contains the
contents of the Search Bookmarks folder. You type your query and hit enter.
Also, search history.

3) New contextal menu item, disabled if no text is selected in the browser, that
cascades to reveal the same list and searches based on the current selection.

4) "Open URL in Navigator" services menu item cascades to reveal the same list
(is that possible?).

If we did a few things like this to make keyword bookmarks more accessible,
"Google Toolbars" and their ilk would look pitifully limited in comparison.
Keyword bookmarks would still work as is from any bookmarks folder, but the
special folder would control which ones are menu-accessible. Also, I can't think
of a functional reason why the search field has to be separate from the location
field (except maybe the search history), but I feel sure it would be less
confusing that way.
IMHO: Automatically search if the URL given isn't a valid URL. So, it would
parse and if there's just one word, with no "." in it, or if there's multiple words.

The default today is that if the user enters foobar, it tries foobar.com etc.
Why does it do that? I don't think people really use that feature that often.
Whereas, if it acted as a search on the default search engine it would be more
widely useful. With two or more words as the term there would be no doubt, with
one word, it would change the behavious to this new behaviour.
I had this working a la Safari/Mail, but there were some issues with the
NSTextField subclass I was trying to use. I'm in the process of doing a full
rewrite of the widget, though code for the searching itself is very short (20
lines or so) and won't be affected. I've looked at a few examples online, but
they're all deficient in one way or another. Regardless, I should have this done
relatively soon.
1 of 4 attachments

This is my implementation of the Mail.app search text field widget.  It
includes three classes: SearchTextField, SearchTextFieldCell, and
STFPopUpButtonCell. Should be pretty straightforward.
2 of 4 attachments

Here are my changes to BrowserWindowController.h and BrowserWindowController.m.
 Main changes to .m include an additional static variable that stores
information on the search engine titles and their associated search urls; a
huge change to performSearch: to perform a search based on the
mSearchTextField's stringValue.

Main changes to .h include an additional IBOutlet for mSearchTextField
Attached file Changes to BrowserWindow.nib (obsolete) — 
3 of 4 attachments

Main changes: Read in data from SearchTextField.h and added an NSView
containing an NSTextField with custom class SearchTextField.  Submits on enter
only. Connected the SearchTextField to mSearchTextField outlet of the File's
Owner. Its action is performSearch: of the File's Owner.
4 of 4 attachments

This is an important file. It's a plist of search engine titles and their
associated URLs. It goes like this:

Dictionary {
  PreferredSearchEngine => SearchEngineTitle
  SearchEngineTitle1 => SearchEngineURL1  
  SearchEngineTitle2 => SearchEngineURL2
		     .
		     .
		     . 
  SearchEngineTitleN => SearchEngineURLN
}

Important notes: PreferredSearchEngine is REQUIRED. It's value must be one of
the titles to a search engine listed in the plist.  In each search URL, %s is a
modifier to denote the search string, and %d is a modifier to denote the domain
you are currently at. For example, with Search this Site, the search URL is:

http://www.google.com/search?q=%s site:%d

Let's say you were at the site: http://www.mozilla.org and your search string
is "Camino".  When the search is performed, the browser will point to:

http://www.google.com/search?q=Camino site:www.mozilla.org

with the space and : escaped as necessary.

This file should go in a localized resources folder (i.e. English.lproj) so
that it can be used for localizing search engines (so that we use Google
Spanish in the Spanish localization of Camino).
I just realized I have a bug in the search text field (it doesn't show the image
of the field in the customize bar).  I've got this working at some level, but
I'll have to tweak it a bit tonight and resubmit.

Also, there's a small memory leak in BrowserWindowController.m. 

[mSearchTextField release];

should be added to the dealloc method.

Sorry about that.
I just added initWithCoder: and encodeWithCoder: to the SearchTextFieldCell
class.	This tarball has all of the files (just to make it easier).
Attachment #118722 - Attachment is obsolete: true
the other thing i was thinking about is does this handle the case where the
toolbar is all text?
Perhaps it would be handy to use the already available small_close.tiff instead
of the SearchCancel.tiff Prachi Gauriar added to his patch. It would save 4KB :)
If this patch is going to be submitted the "Search" toolbar item (the one that
will open the webpage of your favorite serach engine) has to be removed.
In reference to comment 27, it's actually going to only save 978 bytes (check
the Get Info view in the Finder).  Quite frankly, I don't think anyone will get
bothered by that and it's not really worth the effort to open the file and
resubmit changes to the text field.

This does replace the search item in the bar.  I'll work on making sure this
works in text-only toolbars later today. Shouldn't be difficult to do.
Contains all of the files for convenience.

Changes were made to BrowserWindow.nib to add support for a sheet.  Changes
were also made to BrowserWindowController.h/.m to add support for displaying
that sheet. Hopefully I've caught all the bugs at this point.
Attachment #118724 - Attachment is obsolete: true
Attachment #118725 - Attachment is obsolete: true
Attachment #118727 - Attachment is obsolete: true
Attachment #118740 - Attachment is obsolete: true
Major changes:
* Add MPL to all new files, made lots of style changes to be consistent with
mozilla.org code, and removed some extra methods that never really got called.
S 
* Fixed a leak in SearchTextField by autoreleasing the cell before we set it in
awakeFromNib.
* Switched the order of %d replacement and %s replacement in BWC's
performSearch: method so that the %d is replaced first.  This happens so that
if the user has a %d in their search string, it will be searched for properly. 

* Added a check in BWC's performSearch: method to make sure we're getting the
message from a SearchTextField before we start to try to search.  If we're not,
just visit the user's default search page. Updated the nib to last night's
revision.
Attachment #118781 - Attachment is obsolete: true
Pink said in chat:
> talked with simon, we decided:
> 1) don't put the google bar on the toolbar by default 
> 2) remove the old search button 
> 3) remove the search engine field in prefs 
> 4) make the cmd-key focus the google bar or sheet it out if it's not on the
toolbar.

1) and 2) don't have to be dealt with because I made no changes to the toolbar
defaults and replaced the search toolbar button with the search toolbar text
field.

New unified patch to deal with 3) and 4).  Changes from last patch (all paths
relative to mozilla/camino):

* Modified PreferencePanes/Navigation/English.lproj/Navigation.nib to address
3).  Also shifted other fields accordingly to make the layout better.

* Modified doSearch: in src/application/MainController.mm to address 4). 
Basically we just call BWC's performAppropriateSearchAction method instead of
performSearch:

* Modified src/browser/BrowserWindowController.h/.mm by adding a
performAppropriateSearchAction which will either select the search toolbar item
if it's visible or show the sheet if needed. Also removed the else clause in
performSearch: so that if the sender isn't a SearchTextField, don't do
anything. Also renamed mSearchTextField to mSearchBar.

* Modified resources/localized/English.lproj/MainMenu.nib so that the "Search
Page" menu item is now called "Search the Web".

* Modified resources/localized/English.lproj/BrowserWindow.nib to change
mSearchTextField to mSearchBar.

* Modified SearchTextField.h/.m to override selectText: so that text selection
wouldn't select grey text (i.e. the search engine).  

* Modified drawWithFrame:inView: in SearchTextField.m so that it's more robust
regarding when it should draw grey text or not.


Hopefully I kept all the files straight.
Attachment #119447 - Attachment is obsolete: true
prachi, this is missing the patch to the project. can you attach that?
landed, it's pretty sweet. thanks prachi!
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
I wrote an article on how to customize the search engine list... here's the link:

http://comp.uark.edu/~pgauria/CaminoSearchCustomization.html

Thought this would be a good place to put link to it.
Blocks: 147975
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: