I don't see a problem with 3 distinct VCLs, one for each platform, provide they all conform to the same interfaces (protected, public and published) and wrap any platform specific stuff like Windows messaging inside the controls.
Using a factory to create the VCL components on a form would allow a developer to simply change a configuration flag and a whole new set of controls would be instantiated, without needing to change the class inheritance in the application. Surely that's one of the strong points of object oriented design and polymorphism. As far as Java is concerned, I think fast natively compiled code without the need for a runtime engine distinguishes Delphi enough. Surely C/C++ is still widely used in MacOS and Linux for that very reason. Todd. Jolyon Smith wrote: > |> I just don't see it working unless it is possible to take > |> sophisticated applications using the current VCL (ie VCL32) and > |> with some effort but not a complete rewrite <snip> modify the > |> code using ifdefs etc so that you have single source that can compile > |> to either platform. > > I disagree. This is exactly the approach that Borland tried to take with > VCL.NET with disastrous results. Even in that case, where the GUI "toolkit" > was essentially the same, a simple "recompile for this platform" approach > results in an application that is not well suited for the platform at all. > Far from it. > > In the case of the Mac and Linux, those platforms are also quite visually > different and in the case of the Mac in particular provide a quite different > interaction with the user in many cases. How would you single-source VCL > apps that assume a regular 3 button mouse with chording support when running > on a 1 button Mac or even a Mighty Mouse equipped Mac? > > It's not necessarily a simple question of $ifdef'ing some event handling > code - the different user input devices (and the difference in available > user input/interaction controls, if you wish to exploit the "native" look > and feel of the respective platforms) mean that you will almost certainly > need to implement a quite different GUI on each version. > > Either that or dumb your GUI down to the lowest common denominator, > resulting in an app that is unacceptably retarded in the UI department to be > considered appealing on any of the platforms you choose to support. > > (for simple apps this might be viable, but you specifically referenced > "sophisticated" applications, and this is my area of interest also). > > Any NON-visual code should be easily single-source'able, but the V part of > the VCL really has to be different for each platform. "Visual" classes > will, by definition, need to be different from platform to platform because, > visually, those platforms ARE different. > > > Didn't CLX try to achieve single source cross platform support? > > How did that work out again? ;) > > > -- > "Smile", they said "it could be worse!" > So I did. And it was. > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: delphi@delphi.org.nz > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: > unsubscribe > _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
