Re: [Libreoffice] [GSoc] Progress report - Visio import filter

Hi Fridrich, Eilidh,

On Thu, 2011-05-26 at 09:39 +0200, Fridrich Strba wrote:
> In our private conversation you asked for some guidance about how to
> structure the library. Here are my basic thoughts (that are again my
> thoughts that come from having contributed to several libraries, but
> they are not the God's word):

Good that you bring that conversation public Fridrich :)

> 2) Since in the isSupported function I see that you are distinguishing
> two versions of Visio Document, I would suggest that you write a base
> parser class something like:
>
> class VSDXParser
> {
> public:
> VSDXParser(WPXInputStream *input);
> ~VSDXParser();
> protected:
> ....
> private:
> ....
> };
>
> That would contain common functions for all the formats as long as the
> common state that you will need to keep. It could have two derived
> classes for the n=11 and n=6 

Indeed that's more oriented-object way of coding. That's what we already
did in the DOC / DOCX / RTF export in sw, saves a lot of work and keeps
the code much cleaner.

> Now in the VisioDocument::parse(...) function, one could detect which
> file-format we are parsing, construct the corresponding VSD<n>Parser and
> call the parse on it.

Yes!

> 3) As to the development process, I would suggest to first have some dry
> parsing in place, with functions that read the different elements of the
> Visio document without processing them really. You can plant several
> VSD_DEBUG_MSG((...)); statements inside the functions (include the
> libvisio_utils.h and optionally un-comment for the time of heavy
> development the #define VERBOSE_DEBUG=1). Doing so, you get maximum of
> information on your console without actually the parser calling any of
> the interface callbacks. Then you can start from there by actually
> processing the useful content.

Don't hesitate to output loads of TODO printfs to help you monitor what
is missing. This way you'll easily see your progress. Ask Miklos about
it, I think he appreciated the idea last year ;)

> Sometimes, GSoC students are scared that pushing publicly code of
> questionable quality would be detrimental for them when a prospective
> employer googles for their work. This is largely a myth and the evidence
> is that if that was true, I would probably have to have spent all my
> life living on social help :)

To go in Fridrich's way, only few code is perfect from the very
beginning we produce it... but push it as long as it works (doesn't
break important things) and fix it after. Nobody will complain against
that as almost every developer does it (or did it at some point of the
time).

Regards,

-- 
Cédric Bosdonnat
LibreOffice hacker
http://documentfoundation.org
OOo Eclipse Integration developer
http://cedric.bosdonnat.free.fr