FmxLinux bundling with Delphi and RAD Studio

[Rollo62 536]

@Dalija Prasnikar

Ok, good to get your opinion.
Maybe it is the wrong question that I'm asking to the framework, since it already works quite well for my purposes.

My goal is to have a good abstraction of the underlying OS details, to reach the "one source, all platforms" behaviour.
Another goal of mine is to be as close to known VCL as possible, for compatibility and code-reuse reasons.
If my goal would be the "most performant framework", I'm clearly better off with C++, native IDE's or others.

 

I only can say that FMX serves its purpose well for my goals right now, only the current maintaining of all platform services is still behind what it could do (many platform services are still missing or faulty or half implemented).

Saying that, I must also confess that I work only with quite well tested, reliable primitve objects, like TRectangle, TPath, TLayout, TLabel, TButton, TTabControl, TListView, TFrame, etc., and avoid to touch the more "superior" components in the first place.

Maybe only after a lot of practical tests I would consider to use a new component like TMultiView, which I already trried some years ago, but I cancelled that since it caused too many practical issues for me.

There are many advanced controls which still show too many issues, so they likely act as practical show stoppers.
I'm able to wait until more and more controls may get mature, and also I really don't miss any controls right now.

With the abstractions of such "reduced component set" philosopy I can manage my projects well and reliable.

 

Maybe the helpful hint to new FMX users is:
Better lower your expectations, not all components keep what they are promising.

 

Edited June 29, 2019 by Rollo62

[John Kouraklis 94]

There are some bugs and some wierd behaviour in FMX, but saying that the framework is unusable is a bold statement.

 

Can someone produce a list of issues with FMX that make it unusable?

[Dalija Prasnikar 1396]

27 minutes ago, John Kouraklis said:

There are some bugs and some wierd behaviour in FMX, but saying that the framework is unusable is a bold statement.

I said it cannot be reworked, not that it is unusable.

 

That reworking part stands for any other framework, too. You cannot change foundations without demolition.

 

Problem with FMX is that because foundations are not exactly great, many things that should be improved cannot easily be done.

 

For instance, layout alignment logic is totally insane. It does not auto align layouts from insertion order, but from controls existing x, y positions. Try hiding one view and showing it again, and the whole layout will be broken. You have to manually recalculate the whole thing which completely defeats the purpose of auto-alignment.

 

Then like I mentioned before, no separation between low and high level code. Separating those would totally dismantle whole thing. 

 

Poor support for multi-threading - because almost everything is directly connected to UI part that cannot be touched from background threads. It is hard to design fast and responsive UI under such constraints. And you cannot fix that without separating low level and high level code, as well as base, primitive classes.

 

and list goes on...

[Uwe Raabe 2057]

The problem with a bad framework architecture is not that the framework is unusable. If you are only using the framework the internal architecture may be of less interest.

[Darian Miller 361]

1 hour ago, Rollo62 said:

@Dalija Prasnikar

Maybe the helpful hint to new FMX users is:
Better lower your expectations, not all components keep what they are promising.

 

 

Now there's a marketing line for FMX

:o

[Alexander Elagin 143]

1 hour ago, Darian Miller said:

Now there's a marketing line for FMX

...that returns us to the ultimate question: why FmxLinux and not CrossVCL? 😉 Let FMX live in the mobile world and VCL rule the desktop. Lazarus team managed to make LCL (which is a VCL replica) work in many desktop environments, CrossVCL already exists, so I still wonder why FmxLinux was preferred by EMB. Only because it was advertised as the next big cross-platform thing which was meant to replace VCL when it first came out? CLX, another cross-platform Delphi library which was meant to replace VCL, is long forgotten, yet VCL lives.

[Rollo62 536]

@Dalija Prasnikar

Yes and no.

Youre right on the align issue, but I see that the whole align system has big advantages  over VCL. 

It all depends on the point of view maybe.

To solve many issues like you described, I simple can pack sub-components in another level  with TLayout.

Each control can parent any other, and alignment and margins usually work well.

This works suprisingly stabile to me, even if I have several levels and complex TFrames inside.

 

Im not yet convinced, also because I cant see any clear alternative to existing FMX design.  

I still believe thats some parts maybe worth to be reworked, but not the whole System.

Encaptulations of different platforms via  TPresentationProxy seems a quite reasonable approach to me,

to use Styles with possibility of same Basic controls for encapsulation of UI and even animations is a clever move. 

Maybe there are plenty ways to solve things different, but the FMX way is clearly one possible way indeed, with all pros and cons.

Is anything elsa the golden way (Native, Xamarin, Phonegap, Remobjects, CastleGameEngine, Flutter, Unity, Html5,  etc.,)?

I dont really think that there can be a clear winner in this game, in all disciplins.

 

 

Edited June 29, 2019 by Rollo62

[John Kouraklis 94]

What is the problem exactly with alignment? Haven't noticed anything

[Rollo62 536]

14 hours ago, John Kouraklis said:

What is the problem exactly with alignment? Haven't noticed anything

Components visible:= false, true; may reorder components.

[Dalija Prasnikar 1396]

18 hours ago, Rollo62 said:

@Dalija Prasnikar

Yes and no.

Youre right on the align issue, but I see that the whole align system has big advantages  over VCL. 

It all depends on the point of view maybe.

 

It has more aligning options, but that does not change the fact basic logic is broken. Also fully flexible alignment and sizing solution must have separate horizontal and vertical logic. 

 

18 hours ago, Rollo62 said:

To solve many issues like you described, I simple can pack sub-components in another level  with TLayout.

Each control can parent any other, and alignment and margins usually work well.

This works suprisingly stabile to me, even if I have several levels and complex TFrames inside.

 

Deep layout nesting is death to performance. This is not Delphi specific issue. Native Android and iOS frameworks also recommend avoiding deep nesting for same reasons. Of course, some frameworks tolerate more depth some less.

 

18 hours ago, Rollo62 said:

Im not yet convinced, also because I cant see any clear alternative to existing FMX design.  

I still believe thats some parts maybe worth to be reworked, but not the whole System.

Encaptulations of different platforms via  TPresentationProxy seems a quite reasonable approach to me,

to use Styles with possibility of same Basic controls for encapsulation of UI and even animations is a clever move. 

Maybe there are plenty ways to solve things different, but the FMX way is clearly one possible way indeed, with all pros and cons.

Is anything elsa the golden way (Native, Xamarin, Phonegap, Remobjects, CastleGameEngine, Flutter, Unity, Html5,  etc.,)?

I dont really think that there can be a clear winner in this game, in all disciplins.

 

 

Basic idea is not the problem. It is inner code structure and architecture.

 

If you for the moment ignore plain bugs (that can be resolved with time),  then FMX as framework works and is usable.

 

But it will never provide fantastic end user and developer experience because it will never be as fast as other solutions - its inner structure prevents ultimate speed optimizations (it still can be made faster than it currently is) and coding with it will always take more time to achieve goals than with some other better frameworks. And there is little hope for improvement in that area, because inner architecture that is already firmly baked in. Again, some improvements are still possible, but not all the way.

 

[Dalija Prasnikar 1396]

20 hours ago, Alexander Elagin said:

...that returns us to the ultimate question: why FmxLinux and not CrossVCL? 😉 Let FMX live in the mobile world and VCL rule the desktop. Lazarus team managed to make LCL (which is a VCL replica) work in many desktop environments, CrossVCL already exists, so I still wonder why FmxLinux was preferred by EMB. Only because it was advertised as the next big cross-platform thing which was meant to replace VCL when it first came out? CLX, another cross-platform Delphi library which was meant to replace VCL, is long forgotten, yet VCL lives.

Because true cross-platform development means that you reuse code and parts of GUI building blocks for your app. If you have to deal with both VCL and FMX then you lose that advantage,