Doubtful. The .NET community already dwarfs the Delphi community. What incentive is there to develop a new component set that has the potential for 4 times as many bugs and will only be used by a fraction of Delphi developers when they could invest those resources into improving existing VCL and .NET components with wider reach and more return on the investment?
I like the idea to have one code base for Windows and Mac. But the FireMonkey framework is currently too buggy, to create real application with it. As everybody knows, who follows some Delphi blogs, EMB is not very good in fixing bugs or listening to it's community. Therefore, I understand and support the DevEx Team with his decision not to support FMX in the near future. I personally feel, that the FMX framework needs a lot of re-design, with some API changes. TOO SLOW and TOO BIG.
It's time for EMB, to convince us that FMX is a rock solid, high performance cross-platform framework!!!
Long Answer My guess: So far there are too many breaking changes with each new release of FireMonkey. It must be hell on earth for a component developer to support and maintain components for all existing FireMonkey versions. I wouldn't be surprised if DevExpress is going to wait with FM components until the quality of the FM framework reaches the quality of the DevExpress components - yes, I think the DevExpress quality is far better than the quality of the FM framework.
But it would be nice if DevExpress would release at least a Grid for FireMonkey ... and the ExpressBars ... and the ExpressPrinting engine .... and ... :)
In another universe Embarcadero would buy DevExpress and put them in charge for the further development of FireMonkey.
I can't speak to the quality of the FMX framework itself, having never used it. My quip about 4 times the potential bugs was based on the number of supported platforms. 4 platforms means 4 different implementations of OpenGL, 4 different sets of native UI widgets and 4 different low level screen painting APIs. Ok, so maybe it's more like 64 times the number of potential bugs. ;-)
Doubtful. The .NET community already dwarfs the Delphi community. What incentive is there to develop a new component set that has the potential for 4 times as many bugs and will only be used by a fraction of Delphi developers when they could invest those resources into improving existing VCL and .NET components with wider reach and more return on the investment?
ReplyDeleteI like the idea to have one code base for Windows and Mac. But the FireMonkey framework is currently too buggy, to create real application with it. As everybody knows, who follows some Delphi blogs, EMB is not very good in fixing bugs or listening to it's community. Therefore, I understand and support the DevEx Team with his decision not to support FMX in the near future. I personally feel, that the FMX framework needs a lot of re-design, with some API changes.
ReplyDeleteTOO SLOW and TOO BIG.
It's time for EMB, to convince us that FMX is a rock solid, high performance cross-platform framework!!!
Long Answer
ReplyDeleteMy guess: So far there are too many breaking changes with each new release of FireMonkey. It must be hell on earth for a component developer to support and maintain components for all existing FireMonkey versions.
I wouldn't be surprised if DevExpress is going to wait with FM components until the quality of the FM framework reaches the quality of the DevExpress components - yes, I think the DevExpress quality is far better than the quality of the FM framework.
But it would be nice if DevExpress would release at least a Grid for FireMonkey ... and the ExpressBars ... and the ExpressPrinting engine .... and ... :)
In another universe Embarcadero would buy DevExpress and put them in charge for the further development of FireMonkey.
Short Answer
No.
If somebody just needs a powerful grid, have a look at DevMachine FireDataGrid. It looks similar to the DevExpress Grid.
ReplyDeletehttp://www.devmachines.com/firedatagrid-overview.html
I can't speak to the quality of the FMX framework itself, having never used it. My quip about 4 times the potential bugs was based on the number of supported platforms. 4 platforms means 4 different implementations of OpenGL, 4 different sets of native UI widgets and 4 different low level screen painting APIs. Ok, so maybe it's more like 64 times the number of potential bugs. ;-)
ReplyDelete