There is enough speculation about what library / libraries we’ll encounter in the next version(s) of Delphi. We know that the next version code-named Fullcrum (don’t click here and here – AFAIK the links aren’t related with the team’s intentions ;-)) will be a cross-platform product which will target Windows, Mac OSX and Linux…
It seems that it will be only a 32-bit version and the Linux support will be in the ‘preview mode’ even if it seems that they will try to do their best. Take it rather as Mac OSX is the first GUI target after Windows.
Also we know that the compiler suffer a major overhaul, having a back-end / front-end architecture, thus giving the possibility of more codegens and more languages, even if for us, delphians, the biggest gain should be the language improvements which such a modern code base should provide.
But what about libraries?
We know that VCL is tied to Win32 API, hence there was a lot of speculation about a presumable VCL 2.0 which will be the cross-platform cousin of the actual VCL. Such a library exists (is in development) and will be delivered alongside with VCL which will be kept for Windows development. The team called it VCLX in the newsgroups and elsewhere – even if it seems that the actual, release name will be different 😉 – and in the roadmap it is written about it “Limited backward compatibility”.
But where we can found more info about VCLX?
Breaking NDAs are not a solution, believe me. I’m against such practices because it isn’t fair and even if we tend to forget that we are men, at least in the 11th hour, let’s try to keep the last drop of humanity which remained.
…And in fact, if I wouldn’t find a public information about it, I wouldn’t make this post.
But the public information about VCLX is a little bit hard to find so, I think that’s better to pinpoint it and discuss a little bit the implications. So, where is that ‘public information’ which will inform us about this mysterious VCLX?
Perhaps is here? (Screenshot bellow – read it carefully)
For an old delphian the things are quite clear: The new VCLX is the (old) Kylix’s CLX revamped. Hence the VCLX is QT based. For the ones who are new to Qt see the Wikipedia entry also.
Well, in fact isn’t a big surprise at all. Because even if Mac’s OSX has a ‘native’ framework, for Linux such a thing just doesn’t exist. So, they must rely on some already established framework because starting from scratch on Linux isn’t feasible at all because of many reasons. Also, because of many reasons, Qt seems the most logical choice.
And now a word for the Mac fans: Guys, it seems that they dig quite deep in the Mac OSX’s inner workings an (perhaps) we should expect some nice surprises. I think that if they would limit to QT support on Macs they wouldn’t do such an extensive research in the area. See on the matter a series of posts from one of the compiler engineers. Also, we know that Chris Bensen (one of Embarcadero’s senior R&D engineers) went to Apple in order to discuss some core technical issues with the guys there (among them there are some ex-Borlanders who worked on Delphi years ago – don’t be cheated by his webpage content – a nice one btw – click on that ‘About’ link…)
The Win64 ‘problem’
Oh, 64-bit development… Fear not, Nick made it clear that VCL will be used for 64-bit development:
Hence we have:
- VCL for Win32 and Win64
- QT-based VCLX (aka CLX) for Win32, Mac OSX and Linux
Well, I think that this is really great news and a good direction, but some points are very interesting to discuss:
- CLX was very famous for its bugs which created a very anti-CLX thinking current. I think that one of the main targets of the team who works on the “new” VCLX is its quality. And this stands even if VCLX is QT-based or not.
- QT-dependency. We know that QT is pretty big. We will have the same deployment problems which .NET ecosystem has? I think that perhaps is possible to deploy (even statically link in some cases) with ease only the QT part which is actually used – this, of course, aside of possibility to deploy the executable without any QT library inside (assuming that the QT is already installed on the target machine).
- Native Mac. If we will not have a Mac native library, how ‘native’ will be QT on Mac? Ok, there are some applications which doesn’t care about being native (multimedia editors, other skinned applications etc.) but fact is that Mac community is pretty sensible at Mac’s look & feel. I think that we need a response on this.
- Performance and flexibility. Pascal layer over QT layer over OS layer… Seems obvious. But here we should mention two things: The FreePascal crowd doesn’t complain too much about performance issues (at least as far as I know, correct me if I’m wrong)
The GUI part (the part where the cross platform framework is badly needed) isn’t so demanding in terms of speed. Perhaps it would be feasible to provide a thin (ok, as thicker as it can 🙂 ) direct access layer to the Operating System’s API/ABI? - Compatibility. Uhhhh… compatibility. With VCL of course. Granted, we cannot have the same UI widgets. But I think that we can gain (sometimes a lot) from the same RTL and same non-visual classes (think
TStringList, for example) – also if this is low-cost-high-gain for Prism also, then why not? - 3rd Party Support.. Related to the above. Of course, we think that in order to succeed, VCLX should have a strong 3rd Party Support. But an interesting thing to mention here is that if, the Out of the Box components are good enough to be usable in 2010 AD, then the pressure over the 2ndary market will be much lower. For example, if the VCLX’s DBGrid will be good enough (guys, not every field can be displayed and edited in a TDBEdit) then many customers will limit their demand to this. If not, they will not commit to buy. And will wait. And will wait… or switch, of course.
- Price. What will make us buy Delphi when QT and QTCreator exists? When XCode exists? Language? IDE? Extra features in VCLX / RTL? DataSnapX? Till now DataSnap was available only in the Architect edition. I think that RAD Studio 2011 should have concrete distinctive features in order to have clear selling points against both QT as well as against Apple’s free toolchain (XCode / Interface Builder).
So, after all these points (also, I’m sure that there are much more – please feel free to add them in comments) I still do think that it is a good direction, but all boils down on how this direction will be executed.
You?
Wings of Wind Software 
For linking statically you’ll have to purchase a commercial license of Qt. LGPL doesn’t permit static linking.
Also, isn’t DataSnap an Enterprise feature (not Architect)?
I agree about the selling points though. Sure, Delphi and C++Builder won’t die anytime soon even if people use them for legacy projects only – but without innovative and competitive advantages beyond backwards compatibility they’re never going to attract new users.
“LGPL doesn’t permit static linking.”
Good point. I wonder now what agreement (if any) is between Embarcadero and Nokia…
“Also, isn’t DataSnap an Enterprise feature (not Architect)?”
Doesn’t matter very much. The main point is that this feature is pushed to the high-end SKUs thus limiting it as selling point, community impact etc. Too bad because for a connectivity layer the market share is important, at least IMHO.
“VCL 2.0 [ …] The team called it VCLX”
No that is not a VCL 2.0. It would be VCL -1.0 (minus 1.0) unless they invest at some man-years into it.
Yeah, my wording wasn’t correct. I meant by VCL 2.0 the other library not the next one. Hence a VCLX / xVCL / whatever is more appropriate.
“It seems that it will be only a 32-bit version and the Linux support will be in the ‘preview mode’ even if it seems that they will try to do their best.”
does this mean that Fulcrum will have different GUI framework compare to the previous Kylix?
I wouldn’t say “different”. Rather “greatly enhanced”. Because, as it seems, is (more or less) the same library but based on (most probably, isn’t it?) a much newer version of QT and, also, having many of the bugs fixed. But the main difficulty on Linux isn’t so much the QT support (the same applies to Mac) but providing the infrastructure. I think that providing a Delphi experience on Linux is more harder because Linux is a more ‘sparse’ OS compared with Windows and OSX.
If I ran Embarcadero, I’d do this:
* release Linux and Mac OS console/server capability without GUI, and clean up
1st-gen compiler bugs before getting QA hammered with 1st-gen GUI bug reports
* sell the Linux GUI as an add-on, this will confirm actual demand and possibly
reduce QT licensing fees paid by Embarcadero
* allow RAD Studio to easily use FreePascal as the compiler for console/server apps,
but make this an “unsupported” feature to free up QA to deal with other issues.
As a RAD Studio 2010 customer, I would buy RAD Studio 2011 only if Delphi-compiled console/server apps were robust on Linux or FreeBSD. I can use that feature TODAY, while waiting anxiously for 64-bit on Windows. “Preview” quality would make me skip this year. I don’t need GUI on Linux this year.
Linux is immensely more popular as server OS compared to desktop OS. Maybe Linux-based clones of iPad or Ubuntu 10.4 might change that in 2010, but Linux server base is already well-established: no guessing required.
Let us not forget that Linux can run native Win32 binaries using WINE, which improves every two weeks. Even Microsoft Office runs under WINE.
Give us robust Linux console/server apps this year. Don’t make customers and your QA encounter 1st-gen compiler bugs and 1st-gen GUI bugs all at the same time. Embarcadero’s reputation may depend on taking or ignoring this advice.
I had a chat with David I in the comments of one of his blog posts (see here). Quoting him: “Server side for sure. But developers also want desktops other than windows, especially for Macintosh OSX” This means, at least in my interpretation, that ‘preview mode’ means robust server / console mode programs for Linux and, if the God wants, also GUI.
So, I think that you are not alone in your request.
“allow RAD Studio to easily use FreePascal “. This is nonsense. To allow this at least the RTL and other libraries should work with FP – thereby hindering the use of the full Delphi language for the very basic libraries, and tying them heavily to FP itself.
The Mac and Linux market share is so small (2-10%)! I doubt that the cross way brings the great money to Emba. I am waiting for Delphi Win64 for years (using more than 2 GB). My money waits…
Your refered qc entries are old (the newest one is from 2008 and refered as Delphi 9).
So this is for me invalid input.
Hmmm… let’s see:
– The Quality Central has two areas: public and private. One can have access to the private area only if is working on the new release in some way (as Embarcadero employee or any other 3rd party). So what we see is only the public area.
– The difference between a public and a private QC report is a flag in one of its fields. So there it is a clear distinction between public and private report. (Easy isn’t it?)
– But both kinds of reports (public and private) have a common thing. And this is the category tree which of course is stored in a single tree. (Ok, perhaps, they could do private categories but here isn’t the case).
– I’m enough familiar with the QC and for many years (as you mentioned) the ‘CLX’ category stayed the same including its name. In the newsgroups we (as customers) talked about VCL 2.0 (a very logical name – even if its wrong) but the team corrected us and named it VCLX – nobody from us thought at this name (I don’t say that it is odd, I just stress that it is an entirely internal finding).
– Suddenly the label VCLX appears in the place of CLX, confirming, at least IMHO, a very logical decision. They have a lot of code in CLX more or less tested, a lot of {IFDEFs} in VCL to assure the cooperation at a certain level with CLX (non-visual, RTL etc.) etc. Getting all this stuff out and plugging in another architecture which would be written from scratch it would be a no-no from my POV.
– About “old QC entries”. Sure, no problem. I suspect a bunch of private QC reports in this area which forced the change of the category’s name.
Did someone alredy give it a test? Is it hot?
About testing – sure. They gave enough hints about this. Also, if you’re attentive you can see here in comments someone who said something somewhat from inside 🙂 But usually the tests are under NDA and hence don’t expect too much info to leak. Anyway based on past experiences with CLX, the crux of the problem is its quality seen on the main two coordinates: lack of bugs and feature matrix. But I think that they will do it. The things seem encouraging.
Thank you. I dont expect leaks, … I’ll take care about when it is here and final. Encouraging is the word. As a somewhat strange kind of hobby programmer I see this very relaxed. Being ones own customer is best.
Mike
Thanks for the info. Now it is clear we don’t need this kind of multiplatform. We are going to target non-windows platform with other tools.
…hehehe…
Our Luigi. 🙂 Sometimes is so easy to recognize you. (No, I don’t say that you’re wrong or right. Just that you’re steady on your opinions)
“We are going to target non-windows platform with other tools.”
1. Such as?
2. Why?
http://www.mono-project.com/
No, it won’t be Mono. That’s another dead end, useful only to MS to push .NET on Windows.
Already supported by Delphi Prism. So, IMHO no need for native Delphi to support it too.
Oh yes, that’s me – sometimes I just use the initials.
1) C++ and siblings.
2) It is pretty clear now that once again they can’t deliver a comprehensive solution and are able just to build a botcher one with very little chance of success. I am more and more conviced that are Embarcadero Delphi tools to need this solutions, not its Delphi customers. The fact it targets Mac first (with Qt!) seems to confirm this – many high-end Linux desktop users moved to Macs when it became BSD based. Qt would have made sense under Linux, when there’s no native GUI, not under MacOS. But a DBA using a Mac could accept it – especially if the alternative is a clumsy web-based interface. I just wonder if they knew Oracle no longer releases a MacOS native client – 11g R1 and R2 hasn’t one, AFAIK SQL Developer relies on the thin JDBC driver. So good luck developing database apps for the Mac 🙂
Let’s see this time what’s the price Delphi for Windows pays for this new round of butterfly chasing.
The writing was pretty much on the wall from the moment they announced the two VCL streams: Native Windows VCL and Cross-Platform VCL, a lowest common denoninator/jack of all trades master of none poor cousin to the Native Windows powerhouse (unfair? I don’t think so… VCLX apparently will start life with only “half the bits” of “native VCL”, so it’s playing catch-up (in a number of ways) from the get go, and has a LONG way to go to get there whilst having to deal with 3 different destinations in a consistent fashion along the way).
It may not be CLX per se, but the philosophy is the same. This combined with the renewed pursuit of the Big Ticket Enterprise developers whilst simultaneously sinking resources into developing a product aimed at a market famous for embracing “free” and eschewing expensive tools, and also turning away from The Little Guy in the market where there is a well known and established demand. All this must sadly finally dispel any question that the mis-steps taken by Borland in the Inprise years could be laid at the feet of a management team that was left behind when they divested themselves of CodeGear.
Clearly the people with their hands on the tiller then are back steering the ship and, if anything, it was the steadying hand of Borland that forced the team to find their true course back to native Windows code when operating as CodeGear.
Now the effects of that steadying hand have been shaken off, and the ship is being steered onto the rocks once again.
They holed the hull under Inprise. CodeGear managed to keep the ship afloat and for a time the frantic bailing and the bilge pumps seemed to be keeping ahead of the waters flooding the vessel, but finally she is going to succumb.
The rats left the sinking ship long ago, all that remains now is to continue shuffling the deck-chairs and enjoy the band playing their tunes as she goes down once and for all.
Over the last 5 years, I have had three employers. Each of them have had, and still have a great need for 64-bit support on Windows. None of them really need cross platform, apart from in the “wouldn’t it be cool if one could”-departement.
From Embaracadero’s perspective, I see no conflicts between 64-bit and cross platform – as adding 64-bit support while retaining 32-bit support, also really is a cross platform exercise. An intelligent backend compiler that can generate platform specific code, while largely maintaining source code compatibility.
Note that one would still have a signficant amount of work on the system support libs – stuff like registry and ini file emulation being the simple bits, and security and device interfacing on the more complex side, and hopefully this is where VCLX will benefit from putting QT to work.
Although I am not quite such a fatalist as Jolyon, I am, like Rich, somewhat concerned about the resource drain that can come from the GUI complexities. Hopefully, VCLX will be a very thin wrapper around QT – making it less of a burdon on Embarcadero.
The iPhone/iPads, the Androids, the anticipated Chrome, the OSX, the Linuxes – the argument for cross platform support certainly is strong.
It still remains to be seen if VCLX/QT will allow developers to create apps that will be sufficiently native GUI-wise, to not be perceived as a half-baked crossplatform common denominator mongrel.
Who need the registry and ini file emulation under Linux? It’s a Windows specific features, keep it for Windows.
(Unfortunately) Lars’s said that this is the easy part. The difficult part is making abstract other issues like security and device interface. Here a good move was IOUtils.pas introduced in Delphi 2010 which basically virtualized in a certain degree the Windows’s file system.
Instead of a layer over layer over layer (VCLX -> QT -> OS) I’d prefer the QT library converted into Delphi language under LGPL. Then we will have Delphi QT -> OS – just 2 layers.
Actually the QT framework IS a VCL for Linux and OSX. It’s the same situation as for VCL.NET – VCLX is a totally redundant level.
“I’d prefer the QT library converted into Delphi language under LGPL”
Sure, theoretically everyone wants that. But how much manpower is needed to do it? How much manpower is needed to maintain it?
It’s all about C++ -> Delphi conversion.
Emb. is creating the new C++ & Delphi compilers with a common backend:
C++ source ->
Internal representation (.DCU?) -> machine code
Delphi source ->
[1] frontend [2] backend [3]
To make the C++ to Delphi conversion they have to create additionally the Delphi-language backend:
Internal representation -> Delphi source
[2] [4]
1 (one) additional backend instead of a whole crossplatform Visual Components Library!
Moreover, this converison will allow to seriously test the compiler: the received Delphi source codes [4] should be transformed to the same internal representation [2], as the initial C++ source code [1].
I would really like to see more focus on server-side development on Linux.
As for UI I still think that the best solution would be HTML/JavaScript (ExtJS or qooxdoo) tool with libraries to commnicate to DataSnap server (with DataSnap’s DataSet-to-ExtJS Grid and other JS controls binding).
There is no way to catch all client platforms, even with QT. But HTML5.0 with JavaScript is everywhere. And quality of interfaces provided by ExtJS and Qooxdoo is enough for business applications. Do you make games with Delphi?
As for server platforms – there is a few: Win, Linux and some Unix. Here I would like to see some ORM/OPF solution in addition to plain DataSnap.
Do we really need native UI on Linux, MacOS, Solaris, etc? Hasn’t HTML/JS became a true cross-platform client platform yet?
An HTML/Js GUI can work for some applications, but would be totally unusable for many others – and not only games. The fact that many apps turned to often hardly usable HTML interfaces just because the fashion dictates so doesn’t mean everyone will accept them. There are still a lot they can’t do. HTML 5.0 is so new it is not everywhere, and no, HTML/JS didn’t become the true cross-platform client yet – and I hope it will never become because it wil be a huge step backward in usability.
Yes, yes and yes. ECMA Script is a defacto standard which is used a lot more far than most of us would expect and not in web apps only. In my apps the compiled scritps will take over lots of business logic.
I think you got the point from what one can read between the lines from some comments. As long as we assume that a Crossplattform Delphi allows us to move the CS world to Apple or Linux, it will be very hard to figure out certain scenario where such a tool makes sense.
This is not what native compilation will be used for … Native GUIs still make sense, if you think of anything that is related to production. We should not forget the major part of IT budgets (1/3 is for individual applications) are related to the core processes of the customer’s business and in reallity this means logistcs and production and this means in the end flexible GUI, integration and speed of a kernel (lean application architecture) implemented in native XXX but dynamic content. Typical .net domain at the moment or C++.
With the JS Comps we have the flexiblity we need also if we embed them on the client side. The defintion of the GUIs will be dynamic over the years. This is what I believe. This has already been working in the worlds biggest ERP app for decades now;-).
QooxDoo is cool … dynamic languages in the end will make it for the content. For me the webserver alone is not this lean application specific “kernel”. Here is the Delphi developers potential …
One of the reasons Linux didn’t make into the desktop market is its lack of a common GUI among applications. Now with all the Js/Flash/Air/Silverlight stuff we are going exactly the same direction under Windows and other systems. We are losing shared, common, coherent GUIs using most of the same controls to deliver eye-candy applications where the user needs to re-learn each GUI because controls have different shapes, colors, positions, and use.
I really wonder why in the past few years IT decided to move backward.
Totally agree concerning the “richness” of GUI widgets under Linux of any flavour and a lot more the different appserver + addons and the companies indivuidal frameworks based on these combinations especially considering the Java “corner”. One must decide in the end for one way and go it consequently. In the end this will lead to a huge problem.
On thing is the complexity of a development – we should not forget – the Delphi RAD approach helps to handle development process complexity. In the area of web development we see 2 reactions
–> so called process level like SCRUM as a respone to slow development times
–> Scripting, Scaffolding … all this stuff.
We will see. Until now nothing is better. Somehow the “Metadata” or RTTI seems to be the big hope … Jo mei.
I do not expect the “normal” business user to be a typical Linux or Apple User for the scope of Delphi 2011. This is why this why the focus for Delphi 2011 concerning Linux is ok for me so far. So for me the migration of CS Apps written in Windows is not the major goal to achieve with Delphi 2011.
But what I expect is that that elements from web based apps will be part of the GUI in the future. The fact that lots of JS libs exist does not mean that they are the wrong thing by default from a technical point of view. The real pain is the way these apps are developed. This will lead to exactly the same problem the C++ world is facing currently.
>>I really wonder why in the past few years IT decided to move backward.
The thinking is different. The challange is mastering the new technology – this is the driver, … web development is heavy if you try to build something maintainable. This is one argument. There exist a lot more… but we would go beyond scope here… a second is massive specialism, seperating the developer from the Desgin process in serveral cases … mhhh … – I can only talk about what I have seen and this is enough but not the whole IT world;-).
HTML/JS based apps, and their siblings, are an issue, not a solution. HTML was not designed with application development in mind. Javascript was a “grassroot” development to plug some flexibility in HTML.
Interface built on that are a nightmare from an usability point of view. I am really tired of application each having a different menu working in different ways, different buttons – as long as you can tell it is a button – links that are commands and so on. Using them without a mouse is often impossible or very hard.
IMHO that is a huge step backward, it reminds me of the DOS times when each application had a different interface with a different parading. An OS must impose GUI standards and guidelines because that makes exploiting a computer power fully. If one just uses Facebook and little else, well, a dumb terminal is the proper device.
“I really wonder why in the past few years IT decided to move backward.”
Money.
The 1st target is money and not the customer satisfaction.
@LDS: I agree totally with you from a technical point of view but I’m not assuming that money is spent to have happy users, the money is spent to have less of them in ones own house and with the help of “web driven apps” the cost of the processing is moved to the supplier or customer and for this a central hosted application is still the easier way.
I don’t mean that I see this as a big step forward concerning working conditions but automation is the goal.
Especially in the early and mid the last decade Java started to be used for document centric GUIs … this lead in the end to a dominance on the infrastructure side and now the next step is on the way – legacy system replacement via Java. And there everything is better than a dumb ascii terminal. Another trend is to get rid of workflow apps based on groupware –> Move to web centric solutions … e.g. if we think of BSCW one of the first products of this kind web based –> For thes applications the dynamic of web fits too, the more elements one combines.
The problem I see here is, that “tiny” issues are solved a big way especially if think that one does not need an appserver infrastructure to handle thousands of users on an Oracle DB for example … and a lot less in scenarios with hundreds of users … you can take most of the open source DBS…
For this the datasnap (without DBX – I hope they will make this open to thirdparties who can plugin their own stuff for data services) and similar things can be an answer. We cannot deny the existence of the existing solutions based on Java technology. This is why there is an integration demand … and still a chance for applications based on native GUIs.
We for example not leave out the chance to show an order and the status of the steps fullfillment a “HTML” like way and provide the possibitly to allow actions from this view…
@WOW:I didn’t want to say it – thanks that you did it. The problem I see is that espcially the solutions that have been built a smart way focusing on – today we call it – user experience suffer a lot from this, because the market is satisfied with hosted solutions more and more. A chance is maybe that the workgroup approach could come back and leaves room for new products, but I personally don’t believe that we will be in to position to build them cost effective without a high degree of customization in the product.
And coming back to this thread – this is still Windows world and some funcionalities on a Linux machine on the server side … with no big demand for a GUI under Linux, maybe on Apple.
Mike
“…the datasnap (without DBX – I hope they will make this open to thirdparties who can plugin their own stuff for data services)…”
It is (speaking about Delphi 2010). You can plug in almost everything you like. The communication protocol is JSON. You have delegate drivers, callbacks, plug-in architecture for (un)marshalling objects etc.
Sorry I don’t own the Enterprise edition as I use DA and have an eye on RTCSDK this.
The DBX connection itself for example if I want to use AnyDAC in this case … I’m not sure if I can so simply provide data services this way … –> For dataservices especially.
For Message Filtering and related yes Datasnap looks good so far, I agree. Currently I’m investigating a solid base to bring the patterns from “Enterpise Integration patterns” to Delphi … or at least the pascal world … but I don’t want to start from nothing. At the moment I need to integrate via AXIS and use the JBOSS ESB but this is little to much …
Mike
Having wasted not inconsiderable personal money on Kylix/CLX back in the day, I am not encouraged by this news.
It is bad enough that Delphi itself has become so colossal.
But if Delphi projects are going to need large accompanying distributables, we will have destroyed one of Delphi’s remaining unique selling points that enables it to cling to its share of the market.
“But if Delphi projects are going to need large accompanying distributables…”
If you will stay with VCL then this won’t happen. Remember, there will be two libraries: VCL for Win32/64 and VCLX for x-Platform. Also, I think (or should I say hope?) that isn’t impossible to deploy only the needed Qt libraries…
Hey!
I’m one of who want cross platform support before 64bits. But this look like a Kilix reedition.
Can someone remark what’s really new and can bring new users to Delphi.
Why it will work this time?
I think that’s obvious for them. Being just a Kylix revival isn’t enough. They must ship a product which is at year 2010/2011 grade.
“Why it will work this time?”
Their past experience. And Haiti Relief.
Pingback: Delphi 2010 » Blog Archive » Delphi 2011 и далее: будущее библиотек.
Isn’t DataSnap also available in the Enterprise edition?
Yes, it is. See here.
I guess it’ won’t be a multiple plataform iDE, but a crossplataform compiler using th Win IDE.
I guess/hope it will be first complete console only
IMHO it would allow use of any Gui layer (native/qt/gnome, cocoa) ala Freepascal
Linux and Mac should be 64 bits (so why not Windows??)
My perosnal hope: NATIVE WinCE (it shouldn’t be that hard!!!)
Dnaiel Luyo
“I guess it’ won’t be a multiple plataform iDE, but a crossplataform compiler using th Win IDE.”
Yes.
“I guess/hope it will be first complete console only”
No. Qt means that there will be also a GUI layer.
“IMHO it would allow use of any Gui layer (native/qt/gnome, cocoa) ala Freepascal”
Cool. But I don’t know how much from these bindings (except Qt) will be shipped with the product…
“Linux and Mac should be 64 bits”
Theoretically: Sure. Practically: Are you sure???
“My perosnal hope: NATIVE WinCE (it shouldn’t be that hard!!!)”
I think that’s harder that it seems. And also, AFAIU, WinCE isn’t in a very good shape nowadays. Perhaps in the future. Many asked about mobile support.
A Windows only IDE … mhhhh … One should develop under the OS the app is running … somewhat strange … How to debug?
“One should develop under the OS the app is running”
Yep – theoretically true. And practically (of course). But they wanted to skip the big manpower needed to (re)write a new crossplatform IDE and use the Galilleo (the current IDE) instead and to give much more value to the customers.
“How to debug?”
Of course, they will provide a remote debugger which will be a C/S tool over (most probably) TCP/IP or similar – the Client: shipped with/embedded in the .exe – the Server: Galilleo. (of course the architecture can be more complicated but just to show the basic idea).
Also, it’s worth mentioning that the debugged application can live in a Virtual Machine.
Thank you.
Debugging: This make sense … I’m really looking forward.
I was wondering how they could port the IDE so fast … this is almost impossible also within 2 years. This makes sense only if there is a broader demand … somehow understandable.
“Delphi QT”
Sounds like a christmas bell
So we hear SO much about cross-platform, but has there been any talk about anything else coming in the next version. I am up for maintenance renewal now and while I am happy to “support” the ongoing development of Delphi to ensure that it’s still around for me in the years to come, I am not so certain that I want to contribute another AUD$600 unless I am getting something for it, and I have no need for cross-platform. Don’t get me wrong, I don’t want to open the “should I or shouldn’t I debate about maintenance”, I want to know what’s in it for the Windows developer, from what I can tell it’s nothing or very little.
@Peter: QT is pronounced “Cute”.
I wonder what the intended target audience is for cross-platform Delphi. I know, I asked this before, but surely each target platform will have mature development tools native to that OS?
@Tony: That is the danger of subscriptions.
The pressure to produce something that will satisfy customer needs is off because the revenue flow is guaranteed in the short to medium term.
@Ken: Yes and no. A maintenance contract is something usual. Depends on the product.
The advantage of a subscription is to make the sales and budgets more predictable, especially when the numer of useres stays the same over a longer period – this is nothing special to Delphi … this is the product life cycle. With the years you get your base and thats it. A company cannot simply drop a compiler … nor can Oracle stop with the DEC VAX version – but a fistfull of customers pay the maintenance …
@Tony
Embarcadero listend to their customers and there was a strong demand for cross-plattform, because the argument during these days (This was before Chrome was shipped as Prism ) was – if the only chance is to compete against a VS this is not a real vision. What I don’t know if those who voted for crossplattform are the ones who will do it afterwards and I’m sure they will find a reason why not to do (the special ones)… but I’m uncertain if all the guys really had an idea of what they demanded and what crossplatform means in the end concerning efforts. Crossplattform is something different then F9 on another OS … the architecture of a cross-plattform app is different …
*) You cannot make business with satisfied users who never upgrade …
“Embarcadero listened to their customers and there was a strong demand for cross-platform … but I’m uncertain if all the guys really had an idea of what they demanded and what cross-platform means in the end concerning efforts. Cross-platform is something different then F9 on another OS”
Absolutely correct. And even if you DO know what you are demanding, Embarcadero’s questionnaire didn’t make it easy to explain oneself.
Mhhhh … I think it is their freedom to offer what they think that makes sense.
I have listend to the Podcast with Michael Rozlog. The overall picture is consistent. I’m wondering if the IDE is in the position to mimic the Apple look and feel during design time – in the form designer. We will see.
“I’m wondering if the IDE is in the position to mimic the Apple look and feel during design time – in the form designer.”
I don’t think so. If the VCLX is QT based then it will have most probably the Win-like rendering. Another interesting thing to see is how it would mimic the integration of the menu of our app with the OSX’s system menu.
>>integration of the menu of our app with the OSX’s system menu.
:-). I think it should not go so far – during designtime;-). I thought maybe it is possible via theming … look (feel during designtime is somewhat to much – correct). But visual for me is not the task … concerning cross plattform in the early beginning and it is still crossplattform …
It is possible to make experience in this area already
http://www.twinforms.com/ –> based on wxwidgets…
“It is possible to make experience in this area already…”
heh… I do think that they are aware of Twinforms… The announcement (which was posted incindentally in .non-technical forum) caused quite a stir at that time.
About UI on Linux again.
If we don’t speak about “run everywhere” then
Radical approach: abandon UI on Linux at all. If all you need is to port your Win32 app to Linux then for me it would be enough to run it under Wine. I loose Linux look-and-feel then, but is it really required for business applications? In this case the compiler shoud just warn about not Wine-safe calls and the IDE provide Wine config wizard.
So we have native Linux server-side part and Linux/Wine client part. And all we miss is KDE/Gnome look-and-feel (and some desktop integration features).
What do you think?
“Wine support” works already. If a Delphi application doesn’t do some dirty tricks it should (normally) work under Wine. I tested one or two – also I heard from others that they successfully ran Delphi apps under Wine. This doesn’t mean that (if they choose to support this route also) there isn’t room for improvement.
About console mode support: sure – this is a fairly common request and I have high hopes to see it in Fulcrum.
Pingback: Delphi 2011 – Spekulationen, Gerüchte und Diskussionen
Pingback: BLOG DO NARIGUDO » Blog Archive » Delphi 2011 and beyond: The Libraries Ahead « Wings of Wind Software