Re: (great) widget layout progress

Hi Caolan,

On Mon, 2012-08-20 at 17:03 +0100, Caolán McNamara wrote:
> Making a bit of progress in widget layout.

        It looks really beautiful to me :-) I loved the container enabling etc.

> Incremental Conversion: Here's an "incremental" conversion from the
> binary format to to .ui. In this case no code changes happen at all.
> Once the .ui widget ids (and their types) match the ids that the
> existing code expects then "magic" makes it work out of the box if the
> ui is correctly named and put in the right place.
> http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/cmclayouttrans&id=aefe9698a6982eaefdae51dbaebc15a4e0bd28a7

        Wow ! that is even more awesome :-)

> The idea here is that, with the right conversion utility, the .src files
> could be converted to some basic glade-editable skeleton and there's no
> programming ability required to knock that into shape for submission.
> The submitted .ui can then be dropped in as-is, and/or code then
> optimized to complete the conversion.

        So - Kohei started to try to write one of these in python for the
resource files before; not sure if you're aware of that. I suspect some
of it could be re-targetted / re-used the code is here:

http://cgit.freedesktop.org/libreoffice/build/tree/scratch/layout-src2xml/README?h=libreoffice-3-4

        It'd be great to resurrect / build on that if we can to automate the
container-isation; though it is rather a tricky task I suspect.

        Do we have a "GtkFixed" style back-compat hack that will continue to
nail widgets into their places, but do it in TWIPS such that we could do
a one-shot conversion of everything and then iterate ? [ then let the
designers re-work them incrementally ].

> [*] maybe the cast-happy syntax looks a bit vile. Perhaps a bit family
> of get_foos_by_name, or a get_by_name<T> template instead ?

        So - I had a few thoughts here ;-)

http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/cmclayouttrans&id=064c21aec9245148e90290afd00c46b0999d19c4

        One of the things I love about the new model is shrinking the
generated / dialog code-size - by killing all those bazillions of
function calls in constructors.

+ m_pDivIntervalNF = static_cast<NumericField*>(m_pUIBuilder->get_by_name("linesspin"));
+ m_pDivRowsFT = m_pUIBuilder->get_by_name("lines");
        ...

        I suspect it would be more efficient (if we can) to build a descriptor
of the fields (with their types), and map (and verbose-type / NULL
check) all in one place. In my experience it is remarkably common for
even programmers to tweak the XML and rename / loose widgets in such a
way that the code crashes later ;-) I'm sure as a C++ programmer there
is some magic template-ness that could do this in a single line with
better type-safety:

        typedef struct {
                const char *name;
                void      **member;
                type_info   type;
        } CnxData;

        CnxData aCnxs[] = {
                { "linespin", &m_pDivInternalNF, typeof(*m_pDivInternalNF) },
                { "lines", &m_pDivRowsFT, typeof(*m_pDivRowsFT) }
        };
        m_pUIBuilder->connect_data (aCnxs);

        or whatever - presumably with some more macro goodness to align the
member names with the widget names:

        CnxData aCnxs[] = { CNX(DivInternalNF), CNX(DivRows) };

        etc. I guess glade also has this automatic signal connection goodness
that does a similar thing, and we could map to our links quite nicely -
but of course, manual connections are fine too.

        Anyhow - I'm rather excited about this - it looks insanely cool :-) are
there any notable blockers stopping us getting it into master ?

        Thanks !

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot