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).
Related
I need a fast and reliable HTML5 Browser component. For my needs TWebBrowser is too slow. I came across Chromium embedded but the components I found (DCEF3, DCEF4) are relying on Windows units. Also, there are no libraries for OSX32 as chromium is only available on 64 Bit for Mac.
Is there an alternative approach for native HTML5 for FMX on Windows, Linux and OSX?
Background: I use Delphi, FMX and FMXLinux to create a cross platform application on Windows, OSX and Linux and would like to embed and deploy Chromium together with TMS Webcore to offer a fat client and web access simultaneously without having to develop complicated forms twice (FMX and Web).
Michael
There is a version of DCEF maded by Salvador DF that can be compiled in Firemonkey at: https://github.com/salvadordf/CEF4Delphi.
It is a library for Delphi that i have tested on Windows 32&64Bit with good results.
I need to try it on fmxLinux using the binaries that you can find at: http://opensource.spotify.com/cefbuilds/index.html
But i think there is some work to do.
For Delphi VCL there is TWebBrowser and some 3rd party components like TEmbeddedWebBrowser available for browsing a web.
Is there a similar web browser component but for Firemonkey framework in Delphi XE2 (ideally with Windows and Mac support) ?
You can use the ChromiumEmbedded package for Delphi. There's a TChromiumFMX component which is suited for FireMonkey applications. I've tested the demo project from the repository and it works fine for 32-bit Windows.
However I can't tell you if nor how to build and use it in Mac OS. The only thing I can tell you is that the ChromiumEmbedded for Delphi is distributed only with Windows binaries, the binaries for Mac OS you can download from here.
As far as I know (!), the situation is as follows:
CromiumEmbedded supports OSX (& Windows of course)
There is a Delphi ChromiumEmbedded
Delphi supports OSX through the FireMonkey framework
There is even a FireMonkey version of the Delphi ChromiumEmbedded
The Delphi/FireMonkey ChromiumEmbedded does not support OSX
If somebody knows better, that would be fantastic.
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.
I'm curious about what it takes to program for mobile devices (Windows Mobile 6.1) and if I can use the IDE's we're already used to (RAD Studio 2009).
Is there a Mobile Development Community around where Delphi or C++Builder users can learn from?
Are there differences in development techniques, like: Drivers, Memory Limits, Device Specific Considerations and others?
Links to Documentation and Tutorials are always awesome!
Thanks!
You can do Compact Framework development in Delphi.NET (Prism?) but not natively in 2009.
It was a hot topic in the community a few years ago when I was involved, and it basically came down to resources, cost of implementation and potential license fees that made it not worth doing for Borland (as they were at the time).
That may have changed now, but reading the 2009 feature sheet it appears not...
Edit: It appears there is no designer support for CF in Prism.
If you prefer using Pascal you can use FreePascal to develop for Windows Mobile 6.1
I tried to install Delphi 7 on Vista several times and Vista prevented me from doing so by telling me that there are known problems with this application (Delphi 7). Several other people in my company experienced problems with installing D7 on Vista.
This lead to the conclusion that we were at risk with our D7 application, as the company could within the lifetime of the app switch to Vista or Windows 7 and newer Delphi versions are not in the policy of the company. Therefore management decided on rewriting the app in C#.
My question(s):
How to install D7 on Vista
Experience with such an installation
Risk assessment concerning stability of IDE and developed programs
Risk assessment concerning executability under Windows 7
Not using any third party components or database - there should be no problem running the developed app under Vista. If not able to develop and debug under Vista (which at the point being will be the only customer platform, yes, internal programming) will result in a sort of cross platform development - if we would be allowed to keep XP as the development platform.
It is not a developers decision to rewrite, it has been done in the company for the last 3 years: if you had to significantly touch an app developed in Delphi or if there was a certain risk of it not to survive the planned life circle/life span, it had to be rewritten. The life cycle just expanded to 2015 due to canceling another project.
So the main issue here would really be: I would like to have educated arguments about the risks.
Running Delphi 7 under Vista is no problem if you can turn UAC off. With UAC on, you get an error message when starting D7, but it still works, just click ok and go on.
Programs compiled with D7 have no problem with Vista. But new features of Vista are supported by Delphi 2007/2009 only.
We use D7 on XP and on Vista, building and maintaining a commercial App which has gone from D2 to D4, D5 to D7. Besides problems with the BDE, which made us switch to DBX (Corelabs) there are no problems.
Just follow these instructions and you'll be fine. No reason to turn off UAC! I've been running Delphi 7 on Vista for about a year without any problem at all. Debugging is totally fine too.
http://www.drbob42.com/examines/examin84.htm
For installing Delphi 7 in Vista, you can try this patch from Microsoft.
http://support.microsoft.com/default.aspx/kb/932246
As for the rest someone else I suspect will have more knowledge.
I have Delphi 7 working fine on my Vista development box. Yes there was a few issues during installation, but no more than other applications and these issues have been resolved in subsequent versions of Delphi.
None of this should cause problems with apps developed by D7 for Vista. We use Delphi as our primary development tool for all our applications and they work just fine with Vista.
It sounds like this is an excuse by someone in the company to get rid of Delphi and move to C#. Typical FUD tactics. There may be genuine reasons for your company to move away from Delphi, but Vista compatibility should not be one of them.
Also, if you'd like all the Vista-ready features in your Delphi 7 application, have a look at this article here: Creating Windows Vista Ready Applications with Delphi
This will make it so that your application correctly appears when doing Flip3D, or when showing a preview thumbnail when hovering over the app in the taskbar. Essentially, this will give you the "Vista-readiness" of Delphi 2007, from within older versions of Delphi (I have used this with Delphi 2006 and it works very well).
You also get the new Vista task dialogs and new Common dialogs with the modifications listed on the linked website.
I think there's a big jump from having trouble installing D7 in Vista (D7 which after all contains low-level bits and pieces for the debugger and which doesn't know about the 'correct' place to put things under Vista), to assuming that your own app will have problems with Vista...
You have the source code, you can test your program running under Vista, you can make whatever (usually minor) tweaks are necessary to your code.... I'm really surprised that you would decide to rewrite the app in another language just because you can't get the (old) development tool to install under Vista.
We need to know more about what your application does, and what components you make use of, to be able to make any guess at your 3rd and 4th questions. They're too general.
FOr instance, I have several D7 applications on the market, one of which uses open-source Interbase 6 with Delphi and can be a problem to get installed/working on Vista Home (the process seems less painful on Vista Business). Another of our apps uses SQL Express 2005 and runs quite happily on Vista. Our newest app, written in D2007, runs fine on Vista. On both Delphi platforms, our two main 'third party' tools are DevExpress controls and ReportBuilder.
I have been using D4 with Vista for year as one of our key products uses it, its good version still and there are workarounds to make it use new Vista features. You can call any win32 API (new functions) so there is no point to update to D7.
I installed/moved D4 to my new machine by hand:
1. by exporting registry hive(s)
2. registering a few components
3. copying files
thats it.. no need to run slow setupper.
As others have noted, there is no problem running Delphi 7 applications under Vista: We do this with a multi-hundred-thousand line Delphi 7 application that uses numerous third-party controls (Developer Express grids, TSILang translation components, etc.).
We use Vista as our primary operating system, but we run the Delphi 7 development environment in a Windows XP Virtual machine. It works perfectly, and there are no installation issues.
It is very simple really.. All what you have to is the following:
Search UAC (User Account Control) off and then intall delphi7 but, you must have no other version of delphi on your computer.
1,2 in Vista) no problems heard if you install http://support.microsoft.com/kb/947562 and configure UAC;
3) None stability issues are known to any of my friends here...
4) Not using Windows 7 with Delphi 7... But heard of many problems with both...