True, but as I said my target would be a native FB class lib that would abstract over widgetsets, like LCL does. To start, qtpas would be enough, and in time, when necessary, calls could be addedcaseih wrote:I was under the impression that Qtpas interfaced with just enough of Qt to power LCL widgets. It wasn't a full binding when last I looked.marcov wrote:A flattened procedural api already exists (search for QTpas). Usually that is fairly stable, needing only major work with major versions.
The missing bit however is an abstraction between widgetsets. So something that you can use from an application that uses winapi on Windows (thus having no dependencies, and easy deployment), and QT/GTK (preferably QT) on *nix. (and maybe Cocoa for Mac if you still care for that, otherwise also QT)
But I think it is better to keep that abstraction layer native FB, just like LCL is native FPC. While LCL is quite complex, and hard to emulate, it would be nice to have at least something in FB.
Yes, FB misses some dialect options, but so did FPC in the early days, and we came pretty far.
Why would you need generics/templates for callbacks? And don't try to make the first tries to fancy.A full OOP binding for GTK in FB would be great. GTKmm is an amazing binding for C++. It leverages the full power of C++ (STL types, etc) while wrapping gobject in a nice C++-idiomatic way with no moc required. I prefer it to Qt in this regard. Unfortunately FB lacks features that C++ has that make GTKmm nice to work with, including templates for doing type-safe signals and callbacks, and reference-counting smart pointers.
But maybe that's more the IDE/designer centric approach of Delphi/Lazarus. You rarely manually set/define a callback anyway, just double click the handler spot.