[Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?

[Gregory M. Turner]

Hello Lazarusians.  I'm working on a component with a relatively fat design-time footprint (that is, compared to it's run-time footprint -- it's a smallish sub-project but I expect ~75% of the code to be as design-time-only).  

My objective is simple, so I'd might as well just spell it out: I'm building a component to manage and encapsulate trivial configuration metadata at the module level in a platform-independent way.  The basic approach I'm relying on right now is to give the user a TFrobCollection with various metadata-attributes, kind of like database columns.  There will be some fairly straightforward slice-and-dice of the metadata, including aggregation across module boundaries.

I want my code to be operational and maintainable in bleeding edge Delphi and Lazarus environments.  I don't care too much about old versions.  Being able to back-port to, say, D7, without horrible agonies, would be vaguely preferable, but it's far from a priority.

I am pretty confident all of the run-time and business-logic aspects of this can be implemented without any need to step outside of the standard VCL/LCL mainstay design-patterns.  The only thing that still has me still scratching my head is the design-time stuff.

Specifically, I would ideally like to be able to code up my Collection property designer just once, and without utterly pathological usage of precompiler features.  BTW even if it worked, I don't think I can just do form inheritance off TCollectionEditor or whatever it's called -- I'm looking to do something considerably more sophisticated than show a list and let the Object Inspector do all the real work -- probably showing the user a hierarchical representation even though the underlying data will be flat.

What's troubling me is that Lazarus and Delphi seem to diverge more and more radically the deeper I push towards OTA territory.  However, without some fairly elaborate designers I just can't see my component being both cross-platform and application-designer-friendly (I really hate when app. designers are forced to click back-and-forth bazillions of times, like monkeys, to accomplish semantically simple tasks, as too-often seems to be the case with Components supporting lots of TPersistents and Collections, but poor, buggy, or non-existent property designers... I won't name any names, but I'm sure many of you have been that monkey at some point or another (I know I have) and didn't like it :S

Anyhow... can some of you with more experience with the LCL <-> ide state-of-the-art give me some advice on where is the right place to draw the line?  i.e.: Should I just ignore all of the various Collection property editors and so forth and do something from scratch which absolutely minimizes OTA dependencies or will Lazarus be able to accommodate some more aggressive approach?  Are there any particular OTA interoperation oases that work really well right now?  Any hard-core face-slappers that I will need to fix upstream in Lazarus or the LCL before doing /anything/ meaningful along these lines?

So far my TOwnedCollection skeleton works like a charm in both IDE's using the default designers, btw.  I didn't have to use a single kludge. But my initial efforts at design-time stuff have ended up looking hopelessly pathological in one IDE or the other.

Thanks for any help/advice you may have for me, 

-- 

-gmt