Search widget is not consistent with the rest of the OS

[Jeremy Bícha]

For GNOME 3.6, GNOME introduced GtkSearchEntry. Core GNOME apps such as Contacts, Nautilus and System Settings have already switched to it (and there are others that aren't shipped by default in Ubuntu like Boxes and Documents). The rest will likely follow soon.

Software Center should use or extend GtkSearchEntry.

But if it doesn't, Software Center should at least move the search icon to the right of the search widget and merge the search icon with the clear icon.

http://developer.gnome.org/gtk3/unstable/GtkSearchEntry.html

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: software-center 5.5.0
ProcVersionSignature: Ubuntu 3.7.0-3.9-generic 3.7.0-rc6
Uname: Linux 3.7.0-3-generic x86_64
ApportVersion: 2.6.2-0ubuntu5
Architecture: amd64
Date: Thu Nov 22 23:23:32 2012
MarkForUpload: True
PackageArchitecture: all
SourcePackage: software-center
UpgradeStatus: No upgrade log present (probably fresh install)

[Robert Roth (evfool)]

Subscribed mpt for design feedback, as he'll have to help us with some ideas. Currently the Software center wiki spec [1] states that:
* "Inside the leading end of the field should be a symbolic magnifying glass icon. Clicking the icon should focus the field and select its entire contents." - This is sort of incompatible with gtksearchentry, as that one does not have the search icon on the leading end, but on the trailing end, and only if it is empty.
So either we'll have to use another symbolic icon on the leading end (to be available for click and select contents) or ... (here's where anyone can drop some ideas on what to do)
[1] https://wiki.ubuntu.com/SoftwareCenter#The_search_field

[Matthew Paul Thomas (mpt)]

The "click the icon to select the contents" feature is just a bonus, not something important to retain. However, I see two design flaws with the GtkSearchEntry design as described.

First, it makes no visual distinction between a live search field and a submitted search field. Putting the search icon at the trailing end suggests that it is a button you can click to perform the search; this is how it behaves in Firefox, Internet Explorer, and Wikipedia, for example (not to mention Nautilus 3.4 and earlier). But if you do click it -- without realizing that its appearance has just changed -- far from performing your search, it erases it! This would be a problem for USC.

Second, toggling between the search icon and a clear icon means that for applications that use submitted searches, the search icon would be absent most of the time. This isn't a problem in USC, which uses live search, so search field contents are always temporary. But for example in a Web browser, a standalone search field retains the most recent search terms so that later you can adjust them and try again. In this situation, a GtkSearchEntry would usually show only a clear icon. It would be ironic if the only time the field contained a search icon was when it isn't being used for a search.

I doubt either flaw could be fixed without breaking the GtkSearchEntry API to introduce a flag for distinguishing live/submitted search fields.

[Jeremy Bícha (jbicha)]

mpt, thanks for replying.

The last time we talked about search field consistency was bug 828567 which I submitted to GNOME as https://bugzilla.gnome.org/659284 which got merged with https://bugzilla.gnome.org/652809 which is how we got GtkSearchEntry. I guess you'll want to try to work with Gtk/GNOME to extend GtkSearchEntry before using it in Software Center or Unity?

I'm not so sure we need a distinction between live search and submitted search. I think local searches with GNOME3 are usually live searches (Nautilus for instance has switched to live search). Unity's "more suggestions" feature is live search.

It's just those web browsers and LibreOffice which don't use live search (although the web browsers do use live search for the find in page [Ctrl+F] feature). Although it probably doesn't mean much to a user who doesn't care about the technical details, those apps all use GTK2 so it makes sense that they are currently inconsistent with how GNOME3 apps work.

[Matthew Paul Thomas (mpt)]

<https://bugzilla.gnome.org/show_bug.cgi?id=652809> unfortunately shows no solution for the live/submitted distinction, despite an application developer asking specifically how to handle it. I'm not an engineer, and I see no user benefit from switching to GtkSearchEntry. I'm just explaining how the design would need fixing if anyone else wanted to do that. :-)

Whether "local searches with GNOME3 are usually live searches" is not really relevant, for three reasons. First, whether it's local or not isn't relevant: USC searches are currently local, but may become Internet-based in future, while still being live. Second, Gnome 3 has few useful (and hardly any best-in-class) applications, so Ubuntu will indefinitely ship applications from elsewhere, including applications with search functions that can't reasonably be live. And third, notwithstanding your sterling work on the Ubuntu Gnome Remix, I'm sure you understand that the vast majority of people who use Gnome 3 software will never encounter the "Gnome" name -- so we can't reasonably use that to establish a mental model for how search fields behave.

As I understand it, neither Firefox (XUL) nor LibreOffice (VCL) use GTK at the widget level. And even if they did, GtkSearchEntry doesn't seem featureful enough for Firefox to be able to use it anyway.

[dino99 (9d9)]

That version is no more maintained