New gui extension

[Germán Poó Caamaño]

On Fri, 2007-07-27 at 00:08 -0700, Brad Schick wrote:
> Jens Alfke wrote:
> > Regardless of GUI, any tools like this will have a lot in common in
> > how they access Mercurial. How does gtools work? Does it exec an 'hg'
> > process to do the work and parse its output, or does it directly run
> > the Python code in-process? If the former, are there any subtleties to
> > parsing the output of 'hg', since not all the commands can be themed?
> gtools is a mercurial extension written in python, so it gets called
> directly from within the hg process. I really wanted to avoid parsing
> text output and for the most part that was possible without duplicating
> too much mercurial code. The high-level hg commands are implemented in
> mercurial/commands.py which I mostly just called directly since they
> output just error and info strings. I really only had to duplicate code
> from the status function since it's output would have needed parsing.
> 
> I think mercurial could be improved by adding a high-level command
> interface that returned python objects rather than writing strings. The
> built-in stringy commands could be written atop that, as could graphical
> extensions and wrappers. Of course that doesn't help if your language of
> choice can't call python code.

I agree.  I have written an extension for Nautilus (the file manager of
GNOME) and I took ideas from mercurial/commands and so on, avoiding as
much as possible duplicate code.

I also thought the right way to do it was write a new class whose parent
were ui.ui.  But it always receive an string.  I must admit that I did
it in a rush (to show how to write Nautilus extensions) and probably I
missed something.

Regards,

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