Comment 44 for bug 64594

Hi Felipe,
> do you think maybe it would be best to develop hubackup off the
> distribution, and re-include it in the archive when it's ready?
Hubackup was removed from jaunty, see bug #320797 . So that is already
done.

> This doesn't explain why the restore GUI refuses to start. Why does it
> happen?
The GUI is simply not finished and can actually not run at all. It lacks
the code to actually do something.

> It seems dealing with dar itself is a compromise of time, and
> availability of a proper binding. I have some Perl skills, and have seen
> Python, maybe I can help with that if there's some prototype somewhere
> to give a headstart. If the GUI (pygtk) was at least working, it could
> be a fast thing (not for Jaunty anymore).
The problem is basically, that developing python bindings is not really
a big problem, once you know how to do it and have the time. Dar itself
(and libdar) is well written and contains a lot of C++ classes which
should be directly available in python. This means, that the classes and
methods should be wrapped to appropriate python classes. The usage of
these classes together with pygtk shouldn't be too difficult, given that
I had done it partly myself. However, the C++ code of Dar is using
nearly everything that makes classes in C++ fun, like friends,
overloading operators and templates. To make things worse, the templates
are then exchanged on a compile-time (pre-processor) case which makes
the whole thing not easier. Again, its not difficult, just time
consuming, if done right.

For reference, since python bindings can be done mostly on an automated
basis (if the code is not too complicated), someone used swig to do
exactly that. However, the usage of friends, overloaded operators and
compile-time settings force you to also dive deeply into swig to fix
those bindings. I think that a complete C++ rewrite of the bindings
would probably be easier than to fix the (now probably) completely
broken bindings.

For a start, I suggest you take a look at the libdar API itself and the
use cases on the wiki for hubackup. One can see that the ability to use
the bindings would make the integration not too difficult.
I have some code which you may want to see. There is a little more to
see than in the current code. You can browse through my branches if you
like, it should be in there. I don't have much time at the moment, but I
can look through the code in ~1 week. If you want to wait, I can then
point you directly to the interesting parts. Given that I haven't looked
at the code in a year or so, I need some preparation, though :).

It is possible to create a expect like interface to dar on the
commandline, but I suspect it to be quite slow. It doesn't provide some
useful information in order to make the display of data easy.

For the graphical interface, there is the glade stuff to define the
windows, but you need to do some work on e.g. displaying the data in a
treeview, providing progressbars and such. I have made some progress on
this in my code as well.

I hope I could shed some light on the issues around the problem. If you
need other specific information that I have not covered, don't hesitate
to contact me.

Regards,
Martin