[Updated] GSoC: File manager integration for Linux (TortoiseHG)

Germán Poó-Caamaño gpoo at ubiobio.cl
Mon Apr 7 22:56:23 UTC 2008


I just updated my proposal for Google Summer of Code, with special
consideration on feedback I received.

Details about are available in Detailed Description. 

---------------------------------------------------------------------
File manager integration for Linux (TortoiseHG)


I will extend Mercurial and Nautilus to make Mercurial more
user-friendly.  These features includes aids for common tasks available
through menus in a file manager and offer a GUI for managing the project
itself.


Project:

I have two different goals:
  1. Improve the integration between Nautilus and TortoiseHG.
  2. Provide a unified GUI to follow a project using Mercurial. 

Both goals are related.  The first one provide a quick access
for Mercurial commands, calling the second one for an 
specific task.  And the second one is an application that can
run stand-alone and/or be called through 'hg view'.

-- Improve the integration between Nautilus and TortoiseHG --

  Currently the development branch of TortoiseHG has support for
  Nautilus integration, however it has some caveats to be solved,
  according to http://tortoisehg.wiki.sourceforge.net/Nautilus I
  can deduce:

  1. Make the plugin stable.
  2. Enable the plugin works not only in debug mode.
  3. Support for submenu.
  4. Enable other options still hidden for Nautilus.

  Im my opinion:

  * (1) depends on (2) and (3).
  * (2) depends on system wide enviroment variables that I 
    should investigate.  As first approach I can say Nautilus 
    is started by gnome-settings-daemon, hence oesn't use 
    any environment variable defined in .*rc by the user.
  * (3) depends on the following bug reported in Gnome's 
    Bugzilla:
    http://bugzilla.gnome.org/show_bug.cgi?id=440026

  The example provided in that bug has a bug :-) I was able
  to create submenus, but it works only for selected files.
  The submenu created for background is only shown as a 
  first level menu.

  The work that I propose in order to improve the Nautilus
  usability is composed by the following tasks:

  a. Getting a fix for (3).  Probably I will have to 
     make some research in the nautilus extension's
     bindings.

  b. Getting a fix or documentation about getting the
     extension/plugin running in any kind of session
     (normal or debug).

  c. Enable more options to Nautilus as requested by
     the mentor.

  I think (a) and (b) have some tricky involved and more
  important to fix.


-- Provide a unified GUI to follow a project using Mercurial --

  The GUI should use the Mercurial's API and to provide the
  funcionality available by the shell.

  As I was pointed in Mercurial's list, TortoiseHG is written
  in PyGTK and it provides a GUI for several Mercurial's commands.

  After testing and checking the code, I noticed that:

  * Every command is implemented with a stand-alone dialog.
  * Every dialog is a gtk.Dialog or a GDialog (which inherits from
    gtk.Window)
  * Every traditional widget is embedded directly in every dialog
    (by traditional I mean, provided by PyGTK).

  In order to get an unified application I propose to start 
  working on:

  a. Getting some widgets out for the dialog.  
       For instance, the History TreeView could be a Custom 
       Widget, with extra getters/setters/signals.  This
       widget could be embedded in the same dialog but with
       a clear separation of code.

     At this stage, I will keep the same UI for dialog, but
     using this widgets instead of keeping all the code inside
     the dialog.

     It will enable to create/improve another UI using exactly
     the same widgets.  when everything were working fine, the
     transition will be smooth.

  b. Propose an integrated UI using all the refactored widgets.

  c. Improve the UI, using better widgets for each task.
       For instance, in order to add/remove columns in the
       History TreeView is used a RadioButton list instead of
       a CheckButton list.  It also could be done using a
       context menu over the columns.

       The contextual menus are supposed to accelerate the
       funcionality provided in a general/intuitive way. The
       same happen for Toolbars.  I would like to study
       and propose a better UI that takes in consideration
       the User Interface Guidelines, at least the provided
       for Gnome as start point.


-- Other improvements --

  There are other improvements that can be done, and they
  shouldn't be so hard. For instance, provide a layer of
  interoperability between operating systems.

  For instance, currently the font setting is hardcoded.
  If TortoiseHG is running over Gnome, it could use gconf.
  If TortoiseHG is running over Window, it could the registry
  or any other way to access to font information for the system.

  Mercurial provides a mercurial.utils for this can of stuff.
  In the case of TortoiseHG, could be use the hggtklib (probably
  it is already the purpose).


Deliverables:

  - TortoiseHG/Nautilus integration working stable.
  - An unified UI using the codebase already available and
    reusing/sharing as much code as possible.


Having a good separation of code, it will enable to TortoiseHG
to be integrated into other File Manager in other desktops, such
as Thunnar/XFCE.  However, they will need to provide bindings for
Python.

-- 
Germán Poó Caamaño
Concepción - Chile




More information about the Mercurial mailing list