Tag: tracker

Posted on by — Leave a comment

Introducing News

update:

yep, you did not read it wrong. There are two implementations for News: I’ve proposed this app on our wiki more than an year ago. But I just started implementing it 10 days ago. Coincidentally, Igor Gnatenko and Vadim Rutkovsky have started to work in a different implementation of the same idea.

We’ve spent more and more time in big social network sites, which are somehow a smaller version of the world wide web outside, but It doesn’t mean that we want this websites to grow so large until they become the Web themselves. What we love the most about the Web is that it’s open and decentralized, so let’s keep it this way. It’s got ‘space’ for everyone. 🙂

RSS is the opposite of this centralized world of social networks. It’s got no owner, no privileges, no pricetag. Google — the biggest player on the Web — has been indirectly and maybe accidentally killing RSS. Google Reader was shut down two years ago and because of the death of the first biggest feed reader, websites have been disabling their syndication features. As a consequence, RSS is dying too.

We, the free software community, despite of using big social networks as a source of information, we still have individual blogs and aggregators. Since the death of Google Reader we’ve been on an widespread search for an equally great feed reader.

Introducing News

news_wire_1

News (gnome-news) is a GNOME 3 native feed reader. It follows a design-based approach for new features just like the core GNOME apps we love. It uses tracker as a datastore, and tracker-miner-rss for feed synchronization.

It is written in gjs, using a model-view-presenter/presenter-first design pattern. Using architectural design patterns for GNOME apps isn’t pretty common, but is something I’ve got used to, working for Parafernalia writing apps for the Endless OS. I guess that’s something I will elaborate more on later.

It is available on my Github page.

What’s next?

  • make sure distros have tracker-miner-rss enabled by default and ship libgrss
  • define a roadmap for new features
Posted on by — Leave a comment

#GSoC Final Report

Hey,

I can believe it’s over. This Summer passed way too fast! It was a great opportunity of learning more about free software development, programming, and GNOME.

To describe and evaluate my Google Summer of Code, I have chosen an interview-style post. I think this is the most efficient way of describing my internship experience.

What do you consider the best aspect of participating in GSoC?

The satisfaction of feeling part of something bigger than yourself. To work side-by-side with people really engaged in software development.

What do you consider the most challenging part of your internship?

Definitely it was conciliating the program with my university duties, since it’s not summer in the Southern Hemisphere. Although getting familiar with large projects, such as Tracker, was hard as well.

How was your mentor?

Cosimo is a great person and has been a great mentor. He has been patient in leading me to the right direction, pointing me what to do, and teaching me what was needed.

What would you do different if you could do it again?

It’s easy to point mistakes but they are part of the learning process. You got to learn from your mistakes to not repeat them.

I could have started my work in Documents UI sooner to have more time to polish/enhance/improve it. Also, I could have asked [more] for help and completed the Tracker task in lesser time.

Which tips would you give to future students?

  • Ask for help/tips/advice. I’ve lost a lot of time in tasks that my mentor could answer in seconds. 🙂
  • Attend GUADEC!
  • Show your code!

What one thing did the GNOME community do that you consider very helpful for your project and would suggest they continue to do?

Incentivate interns to attend GUADEC. It is an environment of creativity and innovation which certainly will inspire students to get involved even more with the community.

Removable-devices support in Documents

The original proposal was: “To make GNOME Documents able to manage and view files on plugged in removable devices. Including extending Tracker to provide the APIs we need to implement the feature.”

What has been achieved?

Tracker:

The ‘IndexFileForProcess‘ API method has been created. It lets client-applications call Tracker to index files/directories/mount-points transparently on an application basis (you can read more about it in my last report). This mechanism works nicely for what we want in Documents.

Documents:

Documents is able to recognize a plugged-in removable device, create a ‘virtual’ collection containing all the documents inside the device.

What was left behind?

  • Users should be able to Import files from removable devices to the local disk.
  • An already imported document shouldn’t be imported again.

Software is never done! So I’m committing myself to getting these things [gnome] done. 🙂

What’s next?

In addition to finish what’s left in my task, I want to apply for a GNOME Foundation membership, and keep contributing to GNOME.

Acknowledgements

I want to thank the GNOME community for helping students get involved with free software development, Google for giving me the opportunity of work with GNOME, Cosimo Cecchi for guiding me in my project, and you for reading this long report. 🙂

Cheers!
Felipe.

Posted on by — Leave a comment

#GSoC Report V

Hey, this is not my GSoC final report. 🙂

I didn’t expect to be still talking about my work on Tracker at this time, but Martyn Russel has made some nice suggestions of modifications to my code on his review of my patch. The ‘IndexMount’ DBus method has been exchanged for an ‘IndexFileForProcess’ DBus method. It’s a more generic mechanism which allows Tracker to index files on a client-application basis.

It works almost equally to the old ‘IndexMount’. Receives a request-to-index a file/directory/mount-point and watches the bus name of the calling application. It stops the indexing process when no bus names are associated to the file.

I am not that late, I am also working in Documents. Currently Documents loads plugged-in removable devices, uses the Tracker mechanism I’ve described in the previous paragraph to index them, and creates a Device Collection into the overview containing documents inside the device.

I am preparing a preview for my GSoC Final Report (that I will post tomorrow).

See you! 😉

Posted on by — Leave a comment

#GSoC Report IV

Hey! I’ve finished the work that was necessary on Tracker to make it better able to serve Documents and other applications. I just need to get my patch reviewed and perform the necessary alterations.

By the way, It actually took me more time to get DBus working on JHbuild than tying the DBus method to the tracker-miner-fs‘ method which I wrote before. I bypassed it by following this old Murray’s blog post.

So, how useful is it?

To begin with, a typical scenario would be an application sitting on Tracker (such as Documents), which wants to tell the file-system-miner to index a given mount (by indexing, I mean crawling the mount point for files AND adding the device as datasource on the Store).

Besides, the most obvious scenario we want to avoid is when an application, which calls off directly a miner method, crashes. It would cause the indexing operation to fail.

In doing so, we have chosen a different approach using DBus. Now you can send a message to the /org/freedesktop/Tracker1/Miner/Files/Index object, with a mount-point-uri as parameter, and it will tell the tracker-miner-fs daemon to index the Mount accordingly. It also avoids unnecessary crawling of Mounts when more than one application wants their content.

Front-end side: using this mechanism in Documents…

From now on, Documents lists on plugged-in removable devices as collections on the overview. By clicking on a Device Collection, you get it indexed.

What’s next?

A couple of things that I consider essential are:

  • Let users Import documents from a device (maybe exporting?)
  • Do not index already imported documents

That’s all folks!

Posted on by — Leave a comment

#GSoC Report III

Hey, it’s been almost two weeks since my last report, but I’m still here working. I am [finally] free of my university exams, i. e., GSoC is my new full-time occupation. 🙂

In my last report, I described a method that I was working on which adds a mount point easily to the tracker store. It’s now finished!

So I’m now working on tying this method up to the DBus name of the calling application. I’m getting familiar with DBus and this code will be available ASAP on my tracker repository on GitHub.

Cheers,

Posted on by — Leave a comment

#GSoC Report II

Hello everyone!

I’m a little late on my report, but [finally] it’s here now. It’s been hard to conciliate college and GSoC but I’m making good progress on my task.

As I told you before, my first task is to make Tracker capable of indexing files on removable devices on an application basis (on demand). It means making the Tracker API easily capable of receiving calls from applications to index a given device.

Currently, Tracker uses a GSettings key to flag whether or not removable devices and optical discs should be indexed. In these first 3 weeks I’ve worked on a mechanism to escape the strict duality dictated by these GSettings keys.

I’m working on building a method for tracker-miner-fs which receives a GMount object as a parameter, adds this GMount to the Tracker Store, and call the indexer to perform its job.

The next step is to tie these mechanisms up to the DBus name of the calling application in order to finally make it work on an application basis (on demand).

You can hit me anytime on IRC. Let me know if you have doubts/questions/suggestions.

bye!