In article <[EMAIL PROTECTED]>, "MacArthur, Ian (SELEX GALILEO, UK)" <[EMAIL PROTECTED]> wrote:
> Yuri said: > > > The are more than one reason to avoid bundling a package with > > more than > > a reasonable default and a _simple_ api: > > > > With dynamic loading, we could be done with a very simple api, a base > > theme (say gtk+ alike) and forget about it. > > Are we talking about some sort of dlopen-a-like system, maybe even with > a C-callable API? (So as to dodge the c++ name-mangling issues across > compilers.) Yes, I was thinking of something C-based (much like current callbacks). > I get around that by allowing some C++ API, but that only works because > I build everything with the same compiler. For random plugins built with > different tools (particularly on win32 where there are more compiler > choices...) things get tricky. > I'm sure someone knows better than I do about this, however, so I'm > happy to be enlightened! Yes, cross-compiler support of C++ objects is a mayor issue, and I don't think there's a solution. I mean, nothing has really changed much since 10 years, and I still need to use Comeau to get external templace processing. The only thing that changed was a sightly more consistent template and namespace support. It also gets worse with dynamic loading. I really don't want a CORBA brokerer in fltk. Currently, the c-based callback mechanism, in its simplicity, has worked quite well. It allows for extensions to be integrated easily, much more than a template-based system could have. It's a mayor success to have several extensions available online, IMHO. _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
