Jump to content
Sherlock

FmxLinux bundling with Delphi and RAD Studio

Recommended Posts

Me, i crave VCLLinux. (One of the FEW ideas that would make me "upgrade" from pro to Ent.

However, all ye proud owners of Enterprise+, rejoice. Eugene do have attention to detail.

  • Like 1

Share this post


Link to post
52 minutes ago, Alexander Elagin said:

I'd prefer CrossVCL, but anyway this is a good step.

That is not for Linux, only for MacOS. Or am i misinformed?

Share this post


Link to post
Posted (edited)

I don't see this announcement as a good sign.

 

From the management/project point of view, they bought a license from the FMX initial developper, who left EMB last year (IIRC) to re-create his own company https://www.fmxlinux.com - EMB dev team was not able to do it on their own anymore.
Sad. I worry about Delphi future if they need to rely on external coders for new targets or features.

 

From the technical point of view, Linux was supported - with FPC as compiler - 10 years ago http://web.archive.org/web/20091213100642/http://www.ksdev.com/dxscene/index.html when FMX was called DXScene.
So is it a real progress to be able to have back a feature I got 10 years ago, when I bought my lifetime licence to DXScene?
BTW the "LifeTime" of my DXScene license did last 1 year only, since it stopped when EMB bought DXScene - I really felt it was some kind of theft at that time. Now their "LifeTime" license is $349 - I really wonder if it is worth it...

Edited by Arnaud Bouchez
  • Like 2
  • Thanks 1

Share this post


Link to post
Quote

Sad. I worry about Delphi future if they need to rely on external coders for new targets or features.

That is idera style business model.

Quote

I would never go back using a KSDev product. 

KSDev has other products like CrossVCL and DelphiStyles.

Share this post


Link to post
25 minutes ago, Arnaud Bouchez said:

it stopped when EMB bought DXScene - I really felt it was some kind of theft at that time.

I felt the same when AnyDAC, now FireDAC, was sold to EMB (or whatever was its name back then) when I just paid its renewal for another year. Needless to say I never got my money back nor got access to FireDAC which I avoid since then because of such attitude. Luckily, DevArt (UniDAC) offered a great alternative. I just hope that FmxLinux and CrossVCL will remain property of KSDev.

  • Like 4

Share this post


Link to post
Quote

I just hope that FmxLinux and CrossVCL will remain property of KSDev.

I guess so:

Quote

Starting yesterday, Delphi and RAD Studio customers, with active subscription to the Enterprise or Architect editions can download, install , and start using FmxLinux for building FireMonkey applications targeting the Linux 64-bit platform. We continue develop and distribute FMXLinux and we recommend do not install FMXLinux by GetIt and keep use our own installer. It will always be full, supports old version of Delphi, contains additional examples and much more. And you will always get fast updates from us. Best regards, KSDev Team

 

  • Like 2

Share this post


Link to post

From business point of view, it is correct move. 

 

Only a handful of companies have the capacity and resources to do everything. For the rest, it is vital to recognise what their core skills are and how they can align them with the strategic goals. Directing valuable resources to peripheral goals is a waste of resources and of customers' money.

 

So, by offering FMXLinux they basically:

 

1. Provide new ways to use Delphi without devoting (and wasting) their own resources as it is clear for some time now that EMB does not see Linux GUI as strategic option (for now at least)

2. Attract or retain customers who have an interest on that platform

3. Allow a third party to provide support (again preservation of resources). This third party (in theory and in practice I hope) has resources to support GUI Linux better than EMB

4. Keep their resources focused on the core business (compiler development, etc.)

 

I don't have any experience with FMXLinux and not really target that platform at the moment but I hope the package worths its money  

Share this post


Link to post
Posted (edited)
1 hour ago, John Kouraklis said:

From business point of view, it is correct move.

Indeed, from the business point of view, they want to push people buying the Entreprise or Architect editions... so get more money...

But the weird point is that the (very competent) guy behind FMXLinux made it after quitting EMB... weird talent/HR management for sure.
 

Edited by Arnaud Bouchez
  • Like 1

Share this post


Link to post

It still baffles me that DXScene or VGScene were usable given the years it took FMX to properly work.

  • Like 3
  • Sad 1

Share this post


Link to post

I think it's good for the reach of FmxLinux, as long as KSDev keeps it as their own property, so that the product's development will be kept healthy as is.

 

But if EMBT buys also the IP, I believe it's a bad thing for FmxLinux and its current customer.

 

Share this post


Link to post
40 minutes ago, Stefan Glienke said:

It still baffles me that DXScene or VGScene were usable given the years it took FMX to properly work.

The funny thing is, there was a OpenGl Layer for Windows working really well at this time. (I'm also a lifetime customer, my "lifetime" was 4 or 5 month.....). After the purchase the OpenGl part was dropped, not longer usable, and older Delphi not more supported. It was one of the worth purchase i have ever done.

  • Like 1

Share this post


Link to post
Posted (edited)
11 hours ago, edwinyzh said:

I think it's good for the reach of FmxLinux, as long as KSDev keeps it as their own property, so that the product's development will be kept healthy as is.

 

Right, I hope that too.
Its important that KSDev (same as everybody else) can make a good living from their products, otherwise the support may starve.
Better to long-term cooperate with external, good companies than to buy out technology completely and filleting out only the good parts without further support and understanding the concepts behind.
So I hope that Eugene is suprising us with new ideas and amazing technology many more years in the future :classic_smile:

Edited by Rollo62

Share this post


Link to post
15 hours ago, Stefan Glienke said:

It still baffles me that DXScene or VGScene were usable given the years it took FMX to properly work.

There are several things to consider here

 

  1.  kitchen sink design... while it may look like working in proof of concept scenarios, it is hard to extend its functionality without breaking something
  2. originally it was meant to be fast vector based UI framework, and then it got a whole load of styling and pixel perfect baggage - combine that with 1. result is bugs and slow performance
  3. proof of concept library with limited set of widgets is easier to put together, to cover all that is needed to make usable cross-platform apps, FMX had to be extended with many additional widgets, behaviors, functionality - combine that to 1 and 2 - again bugs...
  4. different memory models on Windows and mobile platforms made it harder to debug various issues and aspects - more bugs

 

FMX significantly improved over the years, but its original kitchen sink design is still holding it back.

 

FMX on Linux is good (great) move considering the developer's needs. I just wonder how many kitchen sinks Embarcadero bought this time around. 

  • Like 2

Share this post


Link to post
1 hour ago, Dany Marmur said:

@Dalija Prasnikar pls explain your use of the expression "kitchen sink" in this context. 

It means that you touch one class in one (base unit) and the whole framework gets dragged in.

 

Cyclic dependencies between units are enormous and there is no clean separation between low level code dedicated to direct interaction with graphics engine and high level code. 

 

Not related to the term... but there is also another architectural deficiency because a lot of layout and painting logic is totally illogical. Resulting in two things - harder to achieve your design goal (implement design you need) and second constant unnecessary recalculations and iterations through view hierarchy because changes that could be contained to small part are propagated all over - making the whole thing slower. 

  • Like 1

Share this post


Link to post
6 hours ago, Dalija Prasnikar said:

FMX significantly improved over the years, but its original kitchen sink design is still holding it back.

What would be your suggestion to "modernize" it, would this be they way like Alcinoe framework ?
Or maybe some reworks in the internal structures would be enough ?
I hope you have looked more deeper into the FMX structures, and have located the big showstoppers in concept, please let me know.

I work with what I have in hand, but of coarse it may be allowed to make some proposals or feature requests if they will increase the cross-platform ability a lot.

In my opinion there are a lot of good things in the kind of how FMX does its platform encapsulation, same for the basic idea of separation the UI from logic by Styles (which could have a huge potential, if it would be really finetuned and simplified).
The ability to provide styled and platform controls is also a big advantage over other solutions, of coarse it would be perfect if each platform control and other classes would be "always 100%" be ported to Delphi, not only a minimum functionality to get the basic demos running.

 

My first wish would be that Styles would be enhanced to be more flexible and vector-based (or primitive based), beside the huge PNG wallpapers.

To simplify tweaks of existing designs (re-color, re-shape), instead of creating complete new, large PNG wallpapers by external designers for simple style re-designs.

Share this post


Link to post
1 hour ago, Rollo62 said:

My first wish would be that Styles would be enhanced to be more flexible and vector-based

The original FMX styles were actually vector based. IIRC that was replaced by bitmaps for performance reasons.

Share this post


Link to post
5 hours ago, Rollo62 said:

Or maybe some reworks in the internal structures would be enough ?
I hope you have looked more deeper into the FMX structures, and have located the big showstoppers in concept, please let me know.

How to rework FMX? Burn it down and start fresh, with people who know how to properly structure GUI framework, would be the only proper choice. Not the viable one though. 

  • Like 2

Share this post


Link to post
4 hours ago, Uwe Raabe said:

The original FMX styles were actually vector based. IIRC that was replaced by bitmaps for performance reasons.

As far as I know they switched to bitmaps in order to simulate iOS design at the time (and Android, and Windows) that was anything but flat and drawing that kind of designs without bitmaps would be almost impossible and slow. 

 

However, world moved on in the meantime and current flat designs are more appropriate for vector based painting which then turns to be faster, scalable and less resource hungry. Of course, any fast framework will also include caching views and layers for faster drawing (and when appropriate), but that is different from plucking parts of the control from predefined bitmap and combining those parts at the runtime - all the time.

Share this post


Link to post
Posted (edited)
14 hours ago, Dalija Prasnikar said:

How to rework FMX? Burn it down and start fresh, with people who know how to properly structure GUI framework, would be the only proper choice. Not the viable one though. 

Yes thats always an option.

But I still think that FMX is not that far from perfect with some tweaks here and there.

Btw. That 'burn' would also hit FmxLinux and GlScene in same way since they are close related.

Edited by Rollo62

Share this post


Link to post
1 hour ago, Rollo62 said:

Yes thats always an option.

But I still think that FMX is not that far from perfect with some tweaks here and there.

Btw. That 'burn' would also hit FmxLinux and GlScene in same way since they are close related.

 

If you have a building, you cannot change its foundations and floor plans without demolishing the building. 

 

You can do fair amount of remodeling and you can make it better, but you cannot make it perfect if the original foundation and floor plans don't fit your needs.

 

Same is with FMX, it can be made better and it can be usable, but it will always be far from ideal GUI framework because its foundations are bad.

 

Fixing the foundations would be like building the new framework... the framework code, user code, the workflow... everything would be different. 

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×