In article <✉forums.codegear.com>, Luigi Sandon wrote:

> > GUI that -- because it is non-standard -- is harder for end users to 
> > learn.
> 
> What is standard on one platform may not be on others.

That's true ... and that's why a cross-platform framework should not try 
to produce applications that look the same on all platforms.


Java made that mistake in ... was it Swing? ... every app looks just 
like a crappy Swing app on every platform. That's no way to design for 
cross-platform.


Abstraction of GUI detail makes it possible to target multiple disparate 
platforms from a single codebase. You can write apps that are MDI in 
Windows but present multiple top-level Windows on linux (whose window 
managers typically don't support MDI idioms like child widows with top-
level style frames). You can write menu handling code that puts the menu 
of the application's window on Windows or linux, but uses the system 
menu at the top of the screen on a Mac. These are obvious large-scale 
examples, but you get the idea. A sufficiently well-designed cross-
platform framework can provide the native platform look and feel for 
basic applications on multiple platforms without the programmer having 
to customize the app for each one.


A small proportion of applications need to go beyond the basic UI 
manipulation that can easily be abstracted, and these applications will 
have to provide platform-specific code -- but even these can use the 
generic abstraction provided by a framework to do most of the leg-work.

> Office features like ribbons and outlook grids and bars are pretty
> standard on Windows, but not on Linux.

Office 2007 lookalike wannabees may use ribbons. They're hardly standard 
(they're not provided by the native Windows API widget set). The point 
about cross-platform frameworks is that they provide a platform-agnostic 
API for accessing the native widget set of each platform.


If you want to write an app with a ribbon you can do so ... but the 
ribbon will be part of your app's GUI -- which you can write using 
cross-platform tools if you want -- not something that a framework can 
abstract away.

> The problem is what tools Delphi aims to be. Actually it is a tool
> capable of delivering failry complex native GUIs on Windows. Would
> turning it into a xplat Jack-of-all-trades-and-master-of.none be a
> smart move?

I don't think that's the option that's on offer. cross-platform tools 
may not offer absolute mastery of all trades (to follow your analogy) 
but they (the good ones, at least) do most of the legwork without 
preventing you from refining the result if you want to. VCL doesn't 
offer mastery either.

> Is it what Delphi developers needs? Delphi developers
> today are not xplat developers - if they don't use Java or C++/Qt
> there is a reason.

Most Delphi developers are Delphi developers because the Delphi IDE is 
very good at making the process of designing and coding a GUI painless 
-- even pleasant -- and doesn't cost the earth. They don't care HOW 
Delphi does it, they care that it works.


Until recently Qt has been quite an expensive toolkit to use for 
anything but Free OS software so it's unreasonable to suggest that 
Delphi's relative popularity in commercial Windows software is due to 
any technical shortcoming of Qt's. 


Cheers,
 Daniel.