Connecting the old with the new

I spent some time recently on modernizing the look of  the application chooser in GTK+. Here is how it will look in 3.12:

appchooser-new

appchooser-fail2

As you can see, I added a search button, as it was showing up in the mockup I was working from.  Of course, I had to come up with some answer for how to make it do the expected thing. The application chooser has always supported typeahead search: if the focus is on the list, just type to search. This is an old feature of GtkTreeView:

appchooser-typeahead

But we’ve recently added a nice new search bar widget to GTK+, and I wanted to see if I can’t combine the old treeview search with the new search bar:

appchooser-searchbarThankfully, it turns out that this is very easy. You just  call

gtk_tree_view_set_search_entry (treeview,
                                search_entry)

and all the right things are happening automatically behind the scenes. The full commit that does this in the app chooser looks a bit more complicated, but that is mainly because the app chooser is broken up into separate dialog and widget classes.

If you have a treeview that could benefit from a more explicit search option, you should consider doing something like this.

Here is a video that shows this in action:

28 thoughts on “Connecting the old with the new”

  1. English isn’t my native language, but shouldn’t it say “View All Applications” instead of “View All Application”?

  2. Still no way to add a cutom application. People use this all the time and I have new users that are SO frustrated because the app they want is not in the list.

    Please please add this back.

      1. No. View All Applications lists only applications that have a .desktop file that is known to Gnome. It does not allow you to go through the file system to look for an executable (Windows 8 e.g. still allows this).
        Of course, going through the file system is a major pitb, but as long as not all applications/installation methods are not perfect, the desktop should allow working around their restrictions.

        So, a +1 to the original request from me.

    1. Please add that feature, to choose a custom application. I agree that the removal of that simple feature, was one of the mos frustrating one in the past. And it’s not only for applications not having a desktop file because their installation routine is not correct. This feature was also very useful, to open a file with a script or any piece of software, that does not have any gui.

      1. Just for the record: nothing has been removed. The GtkAppChooser dialog has never included a desktop file editor.

    1. Yeah, this doesn’t look very good; it only makes sense to us because we know Software is the name of the software app. The capitalization of Applications makes it even worse. I think this would read better as simply “Find Applications.”

      Alternatives: “Find New Applications,” or “Search for Applications,” or something similar.

    2. Totally agree. I imagine that it is because GNOME has been moving to generic names to describe apps. “Software” in this case must not mean “software” but a specific piece of software that is meant to be used to find and install software!

  3. Great work!
    I’d like for the search to filter out non matching applications while searching though, much like how it works in Documents, Files or Contacts.

  4. Looks great, thanks!

    The one thing I do not see as an improvement is the search bar.

    I generally dislike the search bar taking up space from the view it’s searching on, I think it’s distracting and messes with my spatial perception, specially because when I finish searching and I want to click an item it moves after the click which is really disturbing (particularly on Web).

    Hopefully we’ll switch to something more akin to what the search-ahead box or gedit’s drop-down search at some point =)

  5. 1st off i saw this on Fedora Planet while searching for Fedora.Next info and seeing this downright scared me to the point where i want to abandon ship while there is still time. Fedora was always gtk centric more or less, which scares me even more since i used it from FC1. not trying to shit at this work at all, since it really does what and how it is intended to. i also apologize on this rant, but it is rant against Gtk

    i would just like to know whos bright idea was to put dialog buttons in title. it goes against everything in usability since normally one passes trough data left-top to right-bottom. any sane user thinks going back on top as last resort.

    there are 3 standards now, Ok left, Ok right, Ok right top. and since some of us used Gtk+ for cp apps, guess that’s not welcomed any more.

    2nd thing i’m wondering is if this really belongs in Gtk. wouldn’t things like that belong in gnome? putting so gnome specific things in core Gtk screws every developer that used it for creating non-gnome apps.

    for me whole gnome HIG is basically driven by 3 drunken monkeys and my computer is becoming even less as usable as my phone. please, don’t do same with Gtk

  6. What will happen to GTK+ dialogs in desktop enviroments other than GNOME? It doesn’t seem good that GTK+ dialogs start having every single button on top.

  7. I have a file with an extension .agr. It’s for xmgrace, or grace. And with all the searches, I can’t find a way of telling gnome to use xmgrace for opening my file. Once upon a time, when gnome was configurable, I could enter the path to a binary.
    Having Cancel and Select on top of the window? C’mon…

  8. I think it might look better taking up 2/3rds the width rather than one third or half, but I dunno. I’m a stickler for such things. lol

  9. So, here’s my particular problem with this application chooser: FontForge (= font editor) uses a custom .sfd file format as its default format. These files look very much like text files to Gnome, apparently which is not much of a wonder, they are human-readable UTF-8 (?) files.
    So, when I set .sfd files to open with FontForge, so will all my .txt files etc. Is maybe Gnome being a bit too clever when sniffing for the file type and should in this case just look at the file type? Any was around this?

    1. GNOME uses the file extension to find the mimetype, and then looks up possible handlers for the mimetype.

      So, if you add a custom mimetype for .sfd files, say text/x-sfd, and register fontforge as a handler for it, it should only be used for files with extension .sfd

  10. Hi.
    I’m sorry, but is there a webpage somewhere explaining the rationale of having the “cancel” and “select” buttons at the top of the window in the tilebar?
    It doesn’t make any sense to me. I have not seen it in any other software. What is the point?

Comments are closed.