Sushi

With the 3.0 release out, I kind of wanted to breath some fresh air and try something new, so I decided to experiment a bit with GtkClutter and Javascript, which I’ve been meaning to for a long time. I ended up writing a quick previewer for Nautilus, a-la Quick Look.

Here is the obligatory screencast of what’s currently in git.

The content type viewers are implemented with a simple plugin system, which Javascript and gjs make it very easy to have. I plan to add other viewers in the future for at least plain text and font files, and it would be nice to also have HTML, source code files with syntax highlight and maybe archives.

Although I’m not completely familiar with it yet, I found the JS experience quite positive, with most of the introspected methods I tried using working out of the box. It’s also perfect for developing nice UIs much faster. The project has in fact a mixed C/Javascript codebase, with some low-level object helpers written in C + GObject and all the UI in JS, like other projects such as gnome-shell and The Board (from which I copied most of the autofoo/build infrastructure and some code to play audio files, thanks Lucas!!) already do.

How do I get it?

I didn’t make a release out of it yet, as it still has a few minor bugs, but it’s actually quite usable already, and you can try it by downloading it from here

http://git.gnome.org/browse/sushi

Note that you will also need the “previewer” branch of Nautilus I published here to enable Nautilus integration

http://git.gnome.org/browse/nautilus/log/?h=previewer

Once a release is out I plan to merge the Nautilus branch and start using it by default, if it’s installed.

Need more?

I have other things in the pipeline for Nautilus and Adwaita this next cycle, which I will write soon about, so stay tuned!

38 comments ↓

#1 John Stowers on 04.29.11 at 4:11 am

Great work – I saw this in git ;-)

What is the startup cost of the viewer, how expensive is gjs vs. something done in native code. Following on, does the sushi process get restarted each time, or does it stay alive for faster previews?

Oh, and what was the key binding?

#2 Roland Taylor on 04.29.11 at 4:41 am

Sorry if I shouldn’t say it, but why not just use Gloobus for this? It looks like – no… it is – a duplication of effort :(

#3 Rowan Lewis on 04.29.11 at 4:58 am

Very nice! The video player preview looks better than Totem does, I wonder if it would be possible to “pin” the preview so that it stays open after focus has shifted?

Then I’d never use Totem ;)

#4 Nirbheek Chauhan on 04.29.11 at 7:07 am

This is awesome! Fits in wonderfully with the shell, and looks very sleek.

I honestly believe that features like these make users want to not stop using GNOME. I love it!

#5 Kris Thomsen on 04.29.11 at 7:18 am

Woow, this look pretty and awesome – and pretty awesome! :p Is it actually possible to watch a whole movie just in the preview (if you want to do that…) ?

#6 philn on 04.29.11 at 9:06 am

Looks cool!
Just a small tip for screencast: next time use a bigger font terminal :)

#7 korbe on 04.29.11 at 9:44 am

Great work. Really nice. :)

But if you use GTKClutter, user need 3D support with their graphic card to use-it?

#8 Marcus Lundblad on 04.29.11 at 10:16 am

Is third-party plugin support planned?

#9 Akshat Jain on 04.29.11 at 11:17 am

Why not just help with developing Gloobus-preview?

#10 Marc on 04.29.11 at 12:49 pm

Dude, that’s awesome! 8O

#11 Markus on 04.29.11 at 12:57 pm

This looks like a copy of gloobus-preview.

#12 Sushi – Previewer per Nautilus in sviluppo! « Ubuntu Secrets on 04.29.11 at 2:14 pm

[…] per l’installazione (soprattutto su Ubuntu!)… Consiglio comunque di dare una lettura all‘articolo del blog dello sviluppatore. Tag:gnome3, nautilus, previewer, sushi Ti è piaciuto l'articolo? […]

#13 cosimoc on 04.29.11 at 3:06 pm

@John: the keybinding I setup is Space, which both opens and closes the preview, in case it’s open already. The process is killed every time you close the window, but if you don’t close it, it will just work and display the previews in the same window/process. I don’t really have any numbers on gjs startup speed, or how it compares to native code, but the speed is decent on my X201.

#14 cosimoc on 04.29.11 at 3:10 pm

@Roland, Akshat, Markus: I know of Gloobus, and I had a look at their source code and implementation before starting a new project. First, Gloobus is in plain GTK+, so you can’t have any animations easily; second, it’s written in C++, when I wanted to learn JS. So, overall it was better to start from scratch.

#15 cosimoc on 04.29.11 at 3:13 pm

@Rowan: the preview “pins” itself automatically, i.e. it will always stay on top of the Nautilus window as long as you don’t close it. I think I might make the UI chrome a bit more transparent when it’s not focused, for this kind of use cases.

#16 cosimoc on 04.29.11 at 3:13 pm

@Kris: yeah, of course, there’s no time limit in the preview.

#17 cosimoc on 04.29.11 at 3:19 pm

@Marcus: to some degree it’s already in place, even though there’s no plugin API guarantee of any kind. The viewer plugins are just JS scripts that implement a set of methods, and register themselves and the mimetypes they support with a central handler object; so, there’s nothing that prevents a third party application to put a script in the viewers directory too and register it like a built-in one. Having said that, I’d rather have as many plugins as possible developed and contributed in-tree.

#18 Jordi on 04.29.11 at 4:35 pm

Hey, i’m the developer of gloobus-preview, why didn’t you contact me so we can improve gloobus-preview that works really well?

#19 cosimoc on 04.29.11 at 4:45 pm

@Jordi: as I already said in a previous comment, I considered it and tried it, but I was not satisfied with the approach Gloobus took (C++ and plain GTK vs. JS and GTK+Clutter…to be fair I also wasn’t really comfortable with the quality of some parts of the codebase); the amount of work needed to patch it to make it behave like I had in mind would probably have been more than writing it from scratch, so I went that road.

#20 Marco on 04.29.11 at 9:46 pm

Nice work.
I got the source from git, compiled and everything is so smooth… with my little intel 945GM.

I think using a keybinding is little tricky, could sushi start just hovering the mouse over the file for a little (like tooltips).

Anyway, great Cosimo. You’re doing a great work for Gnome3.

#21 John Stowers on 04.29.11 at 10:01 pm

@Jordi

I suspect if gloobus-preview claims the well known dbus name that nautilus expects then it can be autostarted instead of Sushi.

@Cosimoc

Is this correct?

#22 cosimoc on 04.29.11 at 10:03 pm

@John, yes, this is correct. If gloobus, or another similar previewer, implements the NautilusPreviewer interface and makes itself able to be DBus-activated it will be picked up just like Sushi.

#23 Emmanuele on 04.30.11 at 8:46 pm

looks really neat! great work, Cosimo! :-)

#24 Hylke on 05.01.11 at 3:40 pm

I use this feature on the Mac a lot, it’s very handy for photos, but it sucks for icons because they are scaled up.

Navigation behaviour is very annoying too, we can do much better!

Anyway, great work! :)

#25 Lucas Rocha on 05.03.11 at 3:40 pm

Great work! :-)

#26 Jakub Steiner on 05.06.11 at 12:07 am

This looks fantastic!

#27 Roland Taylor on 05.08.11 at 9:07 pm

Yes, gloobus doesn’t allow easy animations, is in plain GTK+, and in C++ blablabla….

Point is, this is more likely to become default (for reasons we don’t need to go over here), but it’s pointless… why duplicate the **effort** (sorry I sound upset – not upset at you specifically)…

#28 Quoi de neuf pour Gnome 3.2? | provisoirementvotre on 05.20.11 at 8:46 pm

[…] Pour une démo de Sushi, je vous invite à lire l’article sur le blog de son créateur:  lien – “Trouver et se souvenir”: Voilà un des plus gros morceaux de Gnome 3.2. Ici le but […]

[WORDPRESS HASHCASH] The comment’s server IP (66.135.48.241) doesn’t match the comment’s URL host IP (76.74.254.123) and so is spam.

#29 » Issue 133 GNOME Commit-Digest on 06.02.11 at 9:04 am

[…] A quick previewer for Nautilus, named sushi, has been pushed by Cosimo Cecchi, he wrote about it in Sushi. […]

#30 Edoardo Odorico on 06.05.11 at 9:35 pm

Well done… this is a good road to walk on.
Tricky stuff like that makes everything easier . See u soon @ smorta (tra un bel po’ mi sa)

#31 genix on 06.12.11 at 7:30 pm

I’m trying to compile nautilus with fedora 15, but it seems “gdbus-codegen” doesn’t exists in glib2 anymore. Does anyone what I can do?

#32 mr.dreamer on 06.13.11 at 5:16 am

configure: error: Package requirements (glib-2.0 >= 2.28.0
gobject-introspection-1.0 >= 0.9.6
gjs-1.0 >= 0.7.7
gjs-dbus-1.0 >= 0.7.7
gobject-2.0 >= 2.28.0
clutter-1.0 >= 1.6.0
gtk+-3.0 >= 3.0.0
clutter-gtk-1.0 >= 0.91.8
clutter-gst-1.0
gstreamer-0.10
gstreamer-pbutils-0.10
gstreamer-tag-0.10
libmusicbrainz3
evince-document-3.0
evince-view-3.0

#33 dimaNech on 06.21.11 at 6:54 am

Just amazing!!!! ^^

#34 Ryan Sharp on 07.12.11 at 12:54 pm

@Roland Taylor, “duplication of effort” could be also be described as “parallel innovation”. That’s what free software is good at.

Gloobus is written in an awful language, is pretty low quality code and doesn’t make full use of the Gnome libs. Why don’t you quit whinging and get on with whatever it is YOU are doing. Thing’s get stale and people get complacent without competition.

#35 Lucas (no not the one from the post) on 07.22.11 at 1:52 am

Is there a risk of amazon blocking album art lookups? Wouldn’t a better approach be to look for a tag embedded in the mp3 and then go searching? What happens when it picks the wrong one is the cover cached or is it refreshed every time?

#36 cosimoc on 07.22.11 at 3:12 am

@Lucas: that’s exactly how it works; embedded album art is always looked for first, and if that fails, it tries to fetch it from Amazon. A possible improvement could be caching the downloaded covers and looking for them in the local cache before going over the network; this is just not implemented yet but it shouldn’t be too hard to do – patches welcome :)
There should be no risk of collisions here, as the lookup is done using the ASIN [1] taken from Musicbrainz using the tags stored in the file. No lookup should be done if the file misses even the basic author/title tags.

[1] http://en.wikipedia.org/wiki/Amazon_Standard_Identification_Number

#37 Enrico Badalamento on 08.19.11 at 6:07 pm

Excellent work !

#38 DaVince on 08.24.11 at 2:34 pm

Looking up from last.fm if Amazon fails would be even better, I think. :)