Re: Doubts on writing a nautilus view

["Jauco Noordzij" <jauco jauco nl>]

You should take a look at http://roaringtofu.org/index.php/2005/10/23/nautilus-revisioning-update/ and http://svn.gnome.org/viewvc/nautilus-revisioning/trunk/
this is from a SoC project of a while back that sort of integrated
nautilus with a vcs. Not really the same as what you guys want to do,
but it did offer a calendar with revisions IIRC.

On Feb 3, 2008 7:51 PM, Jisakiel <jisakiel yahoo es> wrote:

Greetings. We are a smallish group of students from Madrid working on a usable backup application, sort of "inspired" in Timevault or Apple's Time Machine, for a software engineering course. (launchpad.net/hdlorean -sorry about the cromulent english there ;)-, and hdlorean.wikidot.com for the project page... unfortunately in Spanish!). Back when scoping the app, we wanted it to be usable over most all other metrics, which we thought it implied integrating it with the Desktop Environment of choice, in this case Gnome and Nautilus (for being the default in Ubuntu, the distro most of my fellows use).


The original idea was to integrate into nautilus as some kind of view, which would not only allow things like extended properties such as timevault does (https://wiki.ubuntu.com/TimeVault/ScreenShots?action="">), but also allow some sort of "time bar" integrated into the view, that when scrolled inside a folder would change the files and directories displayed to the state they had in a specific point in time (existence if deleted, old sizes, permissions, mtimes, etc), allowing it to "scroll in time". It would as well add overlays to the icons showing if they were modified / added / deleted since that selected point in time until the present state of the folder, and also allow sorting them by that criteria.


After being delayed by some programming problems and February exams (right here, right now! ;), we will be soon trying to get the GUI running as fast as possible while we finish the backend -pretty much designed already, still implementing-, as we are all tight on schedule and pretty much overworked. Unfortunately none of us are familiar at all with GTK or GNOME programming (nor with qt), but we managed until now by using pygtk + glade for the prototiping phase...


I started investigating the options we have for integrating with Nautilus. As far as I understood, we should / could: 

- Use nautilus extensions for the overlay and properties part, but not for anything else. They depend on the file being accessed, so for them to be usable we should implement a gnome-vfs layer on which to depend, which sounds "somewhat" complicated and not really documented -at least without any tutorials available- on python.

- Unfortunately neither gnome-vfs -soon to be deprecated, yikes!- nor nautilus-extensions would seem to be enough for the time bar design; we would have to implement a nautilus view.


On that point I get pretty much lost; I don't really understand our possibilities here as I don't know in depth the nautilus architecture. I saw something related to creating a view here http://campd.org/stuff/docs/extending-nautilus.html which points to gnome-python (perhaps in the sources?), and I've skimmed through the -great- documentation present in the nautilus sources, but I can't seem to find more documentation such as APIs or tutorials...

From this point, excuse me if I seem a bit lost:

- We can't really find how to fit our backup system into gnome-vfs, unless we would access the stored information like hdlorean://DATE/TIMESTAMP/fullpath and do some backend-based processing to add the differences in state to the present one, as well as some frontend processing to map bar-positions to DATE/TIMESTAMP ones. Opening of the files could be slow, as the interface was only designed to helping finding the contents.

- A NautilusView, in particular a NautilusContentViewFrame would be the only needed thing to implement? NautilusContentView "tells it" to load a URI (which one? that info depends on the time bar position if we use hdlorean://DATE/TIMESTAMP/fullpath, unless we just tell it to load the base path  as in hdlorean://fullpath and then modify the state of the folder when dragging it), then bonobo activation query loads the "component activated in the metadata" -whatever that means- and the views are told to load.

- We should extend FMDirectoryView or FMIconView, or at least use them, in order to implement as less as possible?. In the end, our idea is, basically,  "just" adding an horizontal scrollbar and listening to changes from it that change the files / folders that are to be displayed, which only exist as a "summary" in a database and are no real files. 

- Changes in the files are notified by the changed signal on NautilusFile. We'd have to trigger nautilus_file_invalidate_all_attributes to reload the files displayed for a given URI (if, for instance, a new file is created in the folder while watching its state a week ago we detect it in the backend and we should display it as "not present x time ago"; as well, if using hdlorean://fullpath paths style and the timebar is dragged ).

- Another possibility could be investigating the way used in abiword: http://www.ph.unimelb.edu.au/~msevior/abiword/nautilus-abiword.png . It seems as a bonobo component -keep in mind our understanding of it is still quite narrow and limited ;)- , but I don't really know how to quickly find more information on that, any other way than studying their sources. Any pointers to documentation? By reimplementing everything, kind of "as an independent subwindow of nautilus" -which is what that screenshot is like- we'd lose the existing logic and display code for the FMDirectoryView and icons, as well as potentially much of the consistency with nautilus. It could, however, be faster to program -less layers of fighting with different apis-, and be later reused inside our standalone gui. Does any other compromise solution exist between both?


- Should it be possible to do it in python some way?


It seems as an awful lot of work for a bunch of newbies... Just researching on the source code or apis -in case they exist- could easily take the two months we have even working on it full-time -which we can't afford-; what should be the quickest-est-est-and-easier way?

Any help or suggestion would be deeply appreciated  (yes, even "forget about it!" :). And hey, if anyone feels like proving how "easy" it is, feel free to branch us ;), although we're still not too proud of the quality of the code (working on it, but we won't get marked on that so it's still low-priority).

Thanks so very much for the help (and the patience reading until here!)


Jisakiel
jisakiel yahoo es

---

¿Con Mascota por primera vez? - Sé un mejor Amigo
Entra en Yahoo! Respuestas.

--
nautilus-list mailing list
nautilus-list gnome org
http://mail.gnome.org/mailman/listinfo/nautilus-list

-- 
groeten,
     Jauco Noordzij