As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Will the next version of Delphi be released with cross platform support and Qt based components? If so, do we have to distribute with Qt? (I don't know anything about Qt)
How can Qt help the Delphi world, and why did many programmers using C++ start using Qt with, and what will happen to VCL?
do we have to distribute with Qt
Probably. A lot depends on how it will be implemented, and how Qt will be linked to executables. There are also interesting implications depending on what kind of Qt license is used. The LGPL is not the MPL or the BSD...
why many programmers using c++ started
using Qt with them
Qt is a C++ library, and C++ developers use it directly. It makes sense to use it from C++ to write portable applications. It makes a lot less sense to create a wrapper over a wrapper, what the Qt/VCL would be. They will take that road because it's faster to deliver a cross-platform framework that way, but they didn't learn anything from the mistakes they made (CLX, VLC.NET) and will repeat it again. They will have to map a library written with its onw design to the Delphi library design, and it means a lot of compromises without any control over the underlying framework. IMHO, it will be a failure like the CLX and the VCL.NET.
There will be a new VCL+ library, released together with the VCL "classic" library.
As far as we can tell, this VCL+ library will be based on Qt 4.
And the "classic" VCL will remain, but targeting Windows only.
Since Qt is C++ based, there will be a dll containing a "flat" version of the library, ready to be accessed from Delphi code. This dll will have to be released with your application. Since Qt can be statically linked, I guess this dll will contain all necessary Qt code, ready to run on Windows/Linux/MacOsX. But another possibility will be to have a "flat" dll which will be able to call other Qt dll, which could be upgraded on purpose, when a new official Qt update will be released: it could be better not to rely on EMB to follow the Qt upgrades, that is not to buy a new Delphi license to have access to the updated Qt framework.
I suspect the way Qt will be used by Delphi programmers will be far away from how c++ programmers use the library. Qt relies heavily on macros and pre-compilation (compiling a Qt application is very time consuming), whereas Delphi will rely on components and more classic class orientation (which compiles quickly).
We can only guess from what was done with the CLX library, when Borland released Delphi and Kylix based on Qt 2. I hope they have learned from this experiment (CLX was never widely deployed/used). But Qt 4 is definitively much more attractive than Qt 2 was.
What we don't know yet is how deep the VCL+ will rely on Qt Core. Will some part of the RTL be translated into better matching the Qt design? For example, will multi-threading and sockets call the corresponding parts of the Qt Core? It could make sense, for cross-platform compatibility, not to reinvent the wheel, since Qt engineers already made the hard work and maintain it...
Well, according to their previous roadmap, current version (Delphi XE) was supposed to provide cross-platform support; that is, compiling your project for different platforms (Win, Mac, Linux), not porting the IDE to those platforms. But they didn't provide it, and postponed it to future releases.
The current roadmap is still vague; it says they will provide it, but no specific time frame (except for 64-bits compiler preview). Embarcadero has postponed expected features (e.g. 64-bits support, or cross-platform support) without informing the customers properly a few times, for example, most (if not say all) of their customers had no idea cross-platform support was excluded from XE up to a few weeks before the official release. So it wouldn't be a surprise for me to see they postponing this again or totally dismiss their current roadmap.
For Qt, according to Mike Rozlog, Delphi product manager, in his interview with Delphi Podcast; their cross-platform support would be based on their previous cross-platform library (CLX) which was available in Delphi 6 and Delphi 7. Even he mentions that most of existing CLX-based apps might compile successfully using the new cross-platform feature. So if this hasn't been changed, then Yes, it will be a Qt base solution. CLX was also based on Qt library.
If it is Qt-based, then you have to deploy Qt runtime library too. In Linux it shouldn't be an issue, cuz as far as I know, most of Linux distros already have Qt runtime installed. For Windows, I know it is not installed by default. I don't know about Mac OS.
How can Qt Help the Delphi world
Qt is a popular and well-established cross-platform framework which is owned and developed by Nokia, and is published for free (LGPL license). Delphi is probably just supposed to use Qt GUI widgets for cross-platform GUI support, but Qt itself consists of many different libraries for almost anything, and just a GUI framework.
why many programmers using c++ started
using Qt with them
You should ask this from C++ developers, but as far as I can say; Qt is a proven cross-platform framework, has a nice IDE and UI designer (Qt Creator), can be easily integrated with popular development tools (e.g. Visual Studio), has good support, you can find Qt port for almost all major programming languages, and Nokia is using it as the base software framework for their current and future mobile platforms (e.g. Symbian^4 and MeeGo).
what will happen for VCL
Again referring to Mike Rozlog; they are going to keep VCL as a Windows-based framework, and provide a new framework for cross-platform development which is similar to VCL.
Related
I have developed a commercial extension for the Unity3D game engine in F#, it's a piece of code which extends the editor with advanced node/graph editing features. F# is perfect for this due to the nature of immutability and DU's.
But, to my question: I realized that the license for the FSharp.Core.dll which comes with Microsoft .NET/Visual Studio probably doesn't allow you to re-distribute it with a commercial project? How would I go about finding out if this is the case or not, and if it's not is there any way to create my own compiled version of FSharp.Core.dll which would run on Unity3D?
The reason I ask is because Unity3D uses Mono 2.6 (albeit a modified version, to my understanding) under the hood, and there is no FSharp.Core.dll bundled with the editor, so I need to supply my own with my extension.
See: Is F# 3.0 runtime redistributable?
The answer is of course Yes. The language would be pretty useless if its core library wasn't re-distributable...
I am embarking on a cross platform app, but not mobile. It will be win/osx/linux. Would love to use Delphi + firemonkey, but it appears linux is not a possible target?
The GUI will not be extensive. Most of the code is non visual.
What are my options here? (Do I end up using lazerous for the linux side.... and then I have to have a special UI there?)
Please let me know my options here, how to solve this cross platform dev project (and hopefully avoid c++).
Linux is not currently one of the supported operating systems, as can clearly be seen from the product description on the Embarcadero web site. If you need Linux/Unix support, XE4 and FireMonkey aren't an option. (XE4 supports Win32, Win64, OSX, and iOS.)
There's support for Linux planned at some point in the future (after Android, which is currently being developed and slated for release later this year).
I have to develop an application to run on Windows CE accessing a remote Firebird database.
I would like to use Delphi to do so.
Is it possible?
Native Delphi only works with x86 compatible processors and Win32/Win64 or MacOS 10 API.
Ken White already pointed to you Delphi Prism, however if you would purchase it, instead of re-marked tool, you'd perhaps purchase the original product, i heard it comes with multiple platforms support instead of one. RemObjects Oxygene is the original product, part of which is re-sold as Prism.
Another option would be using Lazarus (vanilla or CodeTyphon distro). Its LCL library mimics VCL in many respects and FPC compiler mimics Delphi language (and some other Pascal dialects as well).
http://www.pilotlogic.com/codetyphon/help/index.html?cross_build_for_windows_mobile.htm
http://wiki.freepascal.org/Windows_CE_Interface
http://www.lazarus.freepascal.org/index.php?topic=8175.0
No, it isn't. Delphi XE2 does apps for Win32/64, OS X, (and with the help of FreePascal, iOS), but not for CE.
You can probably use Delphi Prism to do so. There is a separate delphi-prism tag for that here at SO.
In fact, you may be able to use the Delphi IDE to build Windows CE applications, using KOL-CE library, after some adaptations.
KOL-CE - Key Objects Library CE is a set of objects to develop powerful (but compact) Windows CE/Pocket PC/Windows Mobile/Win32 GUI applications using Free Pascal Compiler. The library is based on KOL library by Vladimir Kladov (http://kolmck.net).
It targets the Lazarus IDE, but since it is a fork of a Delphi project, you may be able to use it in your Delphi IDE, perhaps after some modifications. And if you are not able (or do not have the time) to do the needed modifications, I'm quite confident that you would be pleased to use the Lazarus IDE and modern object pascal instead of switching to another language.
You need to install the FPC arm-wince cross compiler for Win32 to compile WinCE executables, but you develop your application in Windows, with the IDE.
Note that KOL is a light new set of components, very diverse to the VCL. Very powerful, but only low-level object code can be re-used, since they are not compatible with the VCL (or the Lazarus LVCL).
Using Lazarus and its native LVCL components is also available to Windows CE, is much close to the VCL classes layout, but will produce much bigger executables than KOL-CE.
For the historic perspective: no you can't in Delphi itself as of Delphi 2007.
In Delphi 2005 and Delphi 2006 could do this, targeting the .NET Compact Framework on Windows CE as Delphi contained a Delphi .NET compiler that was more compatible with the Delphi language than the current (but much more evolved) Oxygene .NET/Java platform implementation of the Delphi language.
As of Delphi 2007, the Delphi .NET compiler got retired.
Right now, Oxygene is much better as it supports a broader set of language and platform features than Delphi .NET ever did. It is less compatible with the Delphi language because the platforms it supports warranted for some language deviations that in practice are very useful.
Oxygene ships both separately (with a full feature set) and as Delphi Prism (with only the .NET portion).
For Delphi 2005/2006 you needed the CF Build Helper from Jeremy North and the Class Helpers I wrote (they are included in the CF Build Helper). A nice article on how to use both is at EDN.
Given the hoopla you had to go through back then, it is much wiser to use Oxygene if you want a language very close to the Delphi language.
For a historic overview of Pascal and Delphi like languages, read this article by Jim McKeeth.
I have a Mac app needs to migrate to windows. The app was created using objc and Lua.
I use Delphi to develop app for Windows.
Is it possible to integrate Lua to Delphi in and develop for windows phone7?
Welcome any comment
Thanks
To answer your first question, YES you can use Lua in Delphi. Simon J. Stuart has an incredible blog/website where he has created a number of really useful stuff for Delphi developers. His Lua4Delphi suite will help you integrate Lua scripting into your Windows application. Go to: http://www.lakraven.com/ or http://www.simonjstuart.com to check out the rest of Simon's stuff ... highly recommended!
With regards to the second part of your question (writing a Delphi app for WP7), that would be NO ... you're out of luck there (as Mason mentioned above).
It's definitely possible to integrate Lua with Delphi, but good luck getting it to run on Windows Phone 7. WP7 will only run apps built in the Silverlight or XNA frameworks.
Windows Phone 7 is not possible now, and is not likely to be possible in the near future, using Delphi, or even with Delphi Prism. Key elements of Microsoft's WP7 SDK are limited to the two current .NET core languages (C# and Vb.net). If Microsoft decided to help out remObjects a little bit, then a delphi Prism targetting Windows Phone 7 could become a possibility, but that is out of RemObject's hands, and its unlikely that Microsoft will be interested in helping them join in on the WP7 platform. Perhaps with sufficient engineering dollars, someone could figure out a way to force their way into the WP7 SDK.
Lua is a pretty simple C library, and it should be possible to put it into a DLL and load it into your delphi program. You could write your application in windows, with delphi, and use LUA scripting, and if you find a .NET "lua interpreter", like LUA.net, you might investigate integrating that into a WP7 app that you wrote entirely in C#.
First of all (before this question get down voted): I am a developer developing 99,99% of my programs using Delphi targeting Win32 (developing in Delphi 7 still, very slowly migrating to Delphi 2010).
When Delphi 2006 or 2007 (can't remember which version at the moment) came out I bought the RAD Studio edition to be able to start developing .net applications using Delphi.net and VCL.net.
I played around with it for some short time, but in the end, due to work load just kept using Delphi 7 as development platform.
When Delphi 2010 came was released, I decided to give .net a go once more, and (foolishly) bought the Studio License once more thinking the include PRISM was the previous Delphi.net (to be developed in the Delphi IDE).
Now that I have installed PRISM (and the Visual Studio 8 IDE - o horror), I am just wondering whether PRISM is a new version of Delphi.Net or not (probably not). And if I can use some of my Win32 code under Prism.
UPDATE AFTER SOME REPLIES: I keep the question open because you get more answers when a answer has not been selected yet.
I do miss the Delphi IDE though. It's all a mather of taste but having to develop in two different IDE's (where f.i. the keyboard shortcuts are different - and I don't want to give up the Delphi ones, thank you)) is not my idea of spending my development time.
Prism is a replacement for Delphi .Net - it has been developed by RemObjects and its original names were Oxygene and Chrome ( http://www.remobjects.com/ ).
Because it's much more mature than Delphi .Net in the .Net segment it now is included in Delphi RAD Studio instead of Delphi .Net.
You won't be able to use all of your W32 code, but the syntax is very similar and most algorithms will probably work without any change.
See http://prismwiki.codegear.com/en/Win32_Delphi_vs._Delphi_Prism for a detailed comparison of Delphi W32 and Delphi Prism.
No. Delphi.NET was designed specifically to be backwards-compatible with Win32 Delphi code. Prism is not. It was not developed by the Borland/CodeGear team, doesn't include VCL support, and has a handful of minor language differences. It's better to think of it as a new dialect of Object Pascal than as Delphi.NET.
The main difference was that Delphi.Net was mainly a port of the RTL/VCL to .Net, as well as an adaptation of Object Pascal to be a .Net language.
It had to include a full blown IDE with a special Delphi.Net Form Designer.
The goal was to help move a VCL Forms application to .Net with a minimum of changes, or create new application without having to re-learn the IDE and the library.
Delphi Prism is also an adaptation of Object Pascal to the .Net world but with more emphasis on being a fully fledged .Net language (even more so than C#) and much less worries on being compatible with Delphi.
It is just the language, hosted in Visual Studio, and does use whatever designer is provided by the IDE.
So in the end pure Pascal code will be very much similar, and easily ported, but rich GUI applications will need more rewriting/redesigning.
Yes and no.
Oxygene (FKA Delphi Prism) replaces Delphi for .NET, but it is not a new version of it.
They have different design philosophies and are not 100% compatible. As Francois pointed out, Prism does not include the VCL.Net. Instead it focuses completely on supporting the .NET GUI Frameworks: WPF, Silverlight, Prism, WinForms, ASP.NET, etc.
Delphi for .NET was all about migrating and backwards compatibility. Delphi Prism is all about being a full featured .NET development language and "forward compatibility."
You can create you pure business logic as code compatible between Delphi native and Delphi Prism, but all the GUI and IO code (anything that makes use of the VCL or RTL) will be specialized.
Check out the Oxidizer and ShineOn for more help in migrating and code compatibility with Delphi Prism.
No, Prism has been labeled Delphi more to make it more popular, like Delphi PHP.
It's not like Delphi.NET, with a VCL-alike etc, or even a compatible language (it uses method instead of procedure and many other deviations).
So you can see if you like it, but from what I have seen from it, having used Delphi won't be much of an help, and neither do existing codebases.