GNOME Bugzilla – Bug 609207
search should match mime types handed by apps
Last modified: 2014-04-26 17:19:18 UTC
This was actually Mo's idea. But filing for her. It would be nice if we were able to find apps that handle mime types typed into the search box. For example, if I don't know what can handle pdf it would be nice to match Evince. We'll probably have to use the mime information in the desktop files and match the human language strings that describe them (maybe from shared-mime-info or something).
Created attachment 153819 [details] [review] add search provider. It find applications by handle mime types.
Comment on attachment 153819 [details] [review] add search provider. It find applications by handle mime types. some quick notes: I was expecting them to show up with the rest of the Application matches. I'm not sure having them in a separate group is right. Jon? This only matches filename extensions, not localized mime type names. That seems fine to me though... in most cases the localized name is just the (unlocalized) extension plus "document" or "image", so they'd have to type the extension first anyway. >+const GLOBS2_PATHS = [ >+ '/usr/share/mime/globs2', >+ '/usr/local/share/mime/globs2', >+ GLib.get_home_dir() + '/.local/share/mime/globs2' >+]; This should use GLib.get_system_data_dirs() and GLib.get_user_data_dir() >+ do { >+ if (str.charAt(0) == '#') Hm... there's no part of glib that's already parsing this file that we can take advantage of? (Though it's not that complicated, so...) >+ dis.read_line_async(GLib.PRIORITY_LOW, new Gio.Cancellable(), Lang.bind(this, this._onReadLineComplete), null); don't pass a dummy cancellable. If you update to gobject-introspection master, all GCancellable args are automatically marked (allow-none), so you can just pass null. >+ dis.read_line_async(GLib.PRIORITY_LOW, new Gio.Cancellable(), Lang.bind(this, this._onReadLineComplete), null); ditto
Created attachment 153940 [details] [review] Add ability to find applications by handle mime types. Corrected patch. > Hm... there's no part of glib that's already parsing this file that we can take > advantage of? (Though it's not that complicated, so...) glib does not have function that doing that. (Or something similar).
Comment on attachment 153940 [details] [review] Add ability to find applications by handle mime types. >+ let paths = GLib.get_system_data_dirs(); >+ paths.push(GLib.get_user_data_dir()); >+ >+ for (let i in paths) { that won't work; you can't use "let var in var" with array. you have to do for (let i = 0; i < paths.length; i++) { >+ this._globs2.push({ 'file': Gio.file_new_for_path(paths[i] + '/mime/globs2'), time: 0 }); you never use the "time" field again, so it would be easier to just have this._globs2 be an array of strings, rather than an array of objects. >+ this._ext[ext] = [line[1],]; lose the trailing comma. (it works fine in gjs but it's not standard javascript) >+ if (this._apps[id]) >+ { >+ res.push(id); >+ } you don't need {}s here, but if you're going to have them, the "{" should be on the same line as the "if"
someone more familiar with the dash/search/appsystem performance issues (ie, walters or marina?) should probably look at this too
Created attachment 154051 [details] [review] Add ability to find applications by handle mime types. > that won't work; you can't use "let var in var" with array. you have to do why? It work well. Example: let b = [2, 3]; for (let i in b) { log(i); } It will print 0, 1(as expected).
(In reply to comment #6) > Created an attachment (id=154051) [details] [review] > Add ability to find applications by handle mime types. > > > that won't work; you can't use "let var in var" with array. you have to do > > why? It work well. > Example: > let b = [2, 3]; > for (let i in b) { > log(i); > } > It will print 0, 1(as expected). There are two problems with iterating over arrays like this, one which we don't care about, and one we do: 1) Iterating over an array like this will include methods that are added to Array.prototype - if you say "Array.prototype.sortReverse = function() { ...}" then sortReversed will be included in the loop. We don't care about this. 2) Iterating over an array like this gives the elements of the array in unspecified order. This means that it can only be used when order doesn't matter, which means we get a mix of iteration like the above, and iteration like 'for (let i = 0; i < array.length; i++) { ...}'. This is really ugly and confusing.
Created attachment 154244 [details] [review] Add ability to find applications by handle mime types. Don't mix 'for in' and 'for'.
Comment on attachment 154244 [details] [review] Add ability to find applications by handle mime types. ok, apparently owen wasn't clear. Don't use for..in with arrays. Even if you don't care about the order.
Created attachment 154295 [details] [review] Add ability to find applications by handle mime types. Don't use for..in with arrays
Created attachment 154303 [details] [review] Add ability to find applications by handle mime types. Fix problem with to run result
no word from Jon yet, but Owen and I both think that having the mime-type matches in their own separate section is wrong
(In reply to comment #12) > no word from Jon yet, but Owen and I both think that having the mime-type > matches in their own separate section is wrong In last patch, result show in app section.
Review of attachment 154303 [details] [review]: In the big picture I'm uncertain about searching through the MIME database: * They're not translated, so this only works for English * There a a whole heck of a lot of them, and I'm worried about false matches; say typing "star" to find your Starfield Astronomy app, but getting OpenOffice because it handles "application/vnd.stardivision.impress" For the original bug report, it seems to me if we just patched Evince to mention "PDF" in the Comment field, that would solve the problem. Or we could propose a Keywords type thing for .desktop files. Or actually, we could search through the system package database description. The Fedora one definitely mentions PDF. A patch which starts integrating the shell with PackageKit would be really cool IMO...
(In reply to comment #14) > In the big picture I'm uncertain about searching through the MIME database: Patch search by extension(doc, pdf, cpp ...) > * They're not translated, so this only works for English Why? (extension is not translated) > * There a a whole heck of a lot of them, and I'm worried about false matches; > say typing "star" to find your Starfield Astronomy app, but getting OpenOffice > because it handles "application/vnd.stardivision.impress" Patch has mostly same problem. We have extension like pdf.gz, dvi.bz2; So It will also show 'Archive Manager' for pdf.
*** Bug 622166 has been marked as a duplicate of this bug. ***
I think this bug is obsolete with the recent keyword goal: https://live.gnome.org/GnomeGoals/DesktopFileKeywords For instance in evince Matthias added the following keywords: "pdf;ps;postscript;dvi;xps;document;presentation;" that handles most formats nicely (cf bug 687604) The keywords goal is to include file formats and protocols, which is a broader definition of this bug, and is easier to translate. Closing?
(In reply to comment #17) > I think this bug is obsolete with the recent keyword goal: > > https://live.gnome.org/GnomeGoals/DesktopFileKeywords > > For instance in evince Matthias added the following keywords: > "pdf;ps;postscript;dvi;xps;document;presentation;" that handles most formats > nicely (cf bug 687604) > > The keywords goal is to include file formats and protocols, which is a broader > definition of this bug, and is easier to translate. > > Closing? Do we expect app authors to list all the file formats they support in their .desktop files?
I'd say yes. Doing that allows them to tune for pathological cases.
Tentatively closing this as obsolete. If reopened, the bug should be reassigned to GIO which is where application search is implemented nowadays.