The previous logic for sending/receiving the Q_GADGET definition used a custom GadgetsData type on both sides (a QByteArray for name and a QList of name/type pairs for each member). This isn't really needed on the send side, we just need the QMetaObject for the class. This simplifies the logic on the send side, as we no longer need to copy data around and merge duplicate types, and it allows extension to getting enums. On the receive side, we do need to copy the data. In particular, there can be nested types, where one POD includes another or an enum from another type. It is easier to extend the class if it doesn't need to support the send operation as well. On the send side, we now have serializeGadgets() which takes the pointers for gadget metaobjects as well as the list of needed QMetaEnum types. Using these, it constructs the list of necessary types to serialize and marshalls those. On the receive side, there is registerGadgets which uses the extended GadgetData struct (now including the data needed to create dynamic QMetaEnums) to create metaObjects and register the required types. Change-Id: I80ceff39131c7a2cdcfe592f338ea98f72e76874 Reviewed-by: Michael Brasser <michael.brasser@live.com>