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 ↓
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?
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 🙁
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 😉
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!
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…) ?
Looks cool!
Just a small tip for screencast: next time use a bigger font terminal 🙂
Great work. Really nice. 🙂
But if you use GTKClutter, user need 3D support with their graphic card to use-it?
Is third-party plugin support planned?
Why not just help with developing Gloobus-preview?
Dude, that’s awesome! 😯
This looks like a copy of gloobus-preview.
[…] 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? […]
@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.
@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.
@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.
@Kris: yeah, of course, there’s no time limit in the preview.
@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.
Hey, i’m the developer of gloobus-preview, why didn’t you contact me so we can improve gloobus-preview that works really well?
@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.
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.
@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?
@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.
looks really neat! great work, Cosimo! 🙂
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! 🙂
Great work! 🙂
This looks fantastic!
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)…
[…] 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.
[…] A quick previewer for Nautilus, named sushi, has been pushed by Cosimo Cecchi, he wrote about it in Sushi. […]
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)
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?
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
Just amazing!!!! ^^
@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.
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?
@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
Excellent work !
Looking up from last.fm if Amazon fails would be even better, I think. 🙂
Leave a Comment