In article <✉forums.codegear.com>, Joanna Carter wrote:

> I suppose that's, sort of, my point. Unless someone is prepared to 
> "emulate" what are presently single-platform compoents, it's never
> going to be a "simple recompile".

That's true, of course: Unless the framework provides its own platform
-specific implementation of widgets that are not available on a given 
platform it can only provide a complete abstraction of the widgets that 
are available on all the platforms it covers.


Going back to the ribbon: The ribbon may be a standard widget in Win7 
but certainly isn't in Vista and earlier versions of Windows -- so an 
application that wished to use a ribbon would have to provide the 
implementation unless it limited itself to Win7. That implementation 
could be provided (on, say, XP as well as linux/Mac/whatever) using the 
primitives found in a cross-platform toolkit, which would make it 
cross-platform too.


I'm not sure that I'd want to do that, though. Nobody really expects to 
see a ribbon on a non-Windows platform. Better to use the cross-
platform toolkit to built a non-ribbon GUI that works everywhere, and 
build a specialization that provides a ribbon Windows (only) if you 
feel it's needed.

> So, for most apps, that is going to mean devolving down to the lowest 
> common denominator of UI controls.

That would be the case with the most basic of frameworks, yes, but it 
ain't necessarily so.


No, the cross-platform toolkit should provide a basic framework for 
each platform it supports and that framework should provide an API that 
enables client apps to access the GUI functionality without having to 
know or care quite how that GUI is presented. That doesn't mean that 
all platforms get only the lowest common denominator, but may mean that 
some features are not available on some platforms if those platforms 
don't support all the GUI mechanisms abstracted by the framework.


So, going back to the ribbon again, a (hypothetical) framework might 
provide a means to describe a ribbon as well as means to describe menus 
and toolbars. On Windows the default might be to produce an application 
that displayed a ribbon, while on another system the default might give 
a menu and a toolbar, and on a third system there might be no way to 
display a toolbar so the default would give a menu only. What's more, 
the programmer might be able to specify that the user should be able to 
configure the application on Windows to use a menu and a toolbar 
instead of (or as well as) a ribbon. After all, it's usual in pre-
ribbon applications to be able to turn toolbars on/off, why not the 
ribbon as well? If other GUIs later provided their own native 
implementations of the ribbon, then it would be trivially easy to add 
ribbon support to the applications on those platforms as soon as the 
framework provided ribbon support on those platforms.


What certainly *is* true is that a cross-platform toolkit can only 
provide abstractions of the widgets that it knows about, but it can 
know about -- and abstract -- widgets that are not supported on all the 
platforms it supports.


Cheers,
 Daniel.