Dalija Prasnikar

AFAIK, everything said at May 2019 RAD Studio Roadmap still stands. https://community.idera.com/developer-tools/b/blog/posts/may-2019-rad-studio-roadmap-commentary-from-product-management

I keep rediscovering those every time I go and write my own... done that few times already...

Considering that code completion and navigation is also broken by inline variables, that is currently the most appealing option.

It is a bug Editor marks inline variables as error https://quality.embarcadero.com/browse/RSP-22158 Until it gets fixed there is not much you can do. Either live with red lines or disable Error Insight.

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,

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. 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. 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.

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...

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.

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.

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.

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.

There are several things to consider here kitchen sink design... while it may look like working in proof of concept scenarios, it is hard to extend its functionality without breaking something 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 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... 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.

You can still submit and publish to the store. But when you submit application that does not have 64bit Android support you get warning that your application is not fully compliant with upcoming rules and that you need to fix that to be able to update your application further after the deadline.

The only other ideas I have is trying to disable themes - they slow down opening and closing process - https://dalijap.blogspot.com/2019/05/disable-delphi-rio-ide-theme.html And the other culprit is Welcome screen - https://quality.embarcadero.com/browse/RSP-21973 https://quality.embarcadero.com/browse/RSP-22257 You can either close Welcome tab and try saving... or rename Welcomepage folder

Also post with comments from product management https://community.idera.com/developer-tools/b/blog/posts/may-2019-rad-studio-roadmap-commentary-from-product-management

Different people have different issues. For me and my eyesight not using any dark theme is imperative. After only few minutes of looking at dark themed IDE or web site I experience colored visual artifacts similar to those when you look at bright light. After 10-15 minutes I can no longer read anything dark theme or light theme and I need hour or two to recover.

There was an answer andout activating XE license with basically the same response from Embarcadero as posted here by @cupwalker posted 20 hours ago there... it is deleted now because it was not an answer...

Problem with TComponent (and subsequently its descendants) is that it implements interfaces but has reference counting disabled in _AddRef and _Release methods so it can be used like regular class. However, people often forget that in such cases _AddRef and _Release calls even though they don't do any counting will still be inserted by compiler and called for any interface reference to such object instance. So if there is alive interface reference to the object after calling Free that interface reference will contain dangling pointer and when such interface goes out of scope _Release will be called on already nuked object. While you may get away with such call without FastMM debugging mode, if it is turned on it will correctly identify the problem. Simple test case that will blow with FastMM in debug mode procedure TestComponent; var Comp: TComponent; Intf: IInterface; begin Comp := TComponent.Create(nil); Intf := Comp; Comp.Free; end;

It works for me, but I am already logged in. Embaradero had some problems with servers this weekend and this is maybe some residual effect. Issues should be solved now, but if you still have problems maybe you should contact Embarcadero letting them know not everything works as expected.

First, this sounds like premature optimization. Yes it is 6 times slower, but you are talking about milliseconds for huge number of objects. Next, if you really need to optimize for speed, you can completely remove getter and setter methods. That is the beauty of Delphi - it does not need them at all and you can freely add getter and setter methods later on (if needed) without breaking the public API. Inline approach can solve the immediate problem, but keep in mind that inline directive is just recommendation for the compiler and under some circumstances such methods will not get inlined (though compiler will give you hint in those cases). Essentially you are writing a whole a lot of code for nothing.

If you care about quality it does not really matter where the bug was reported. What matters is that people who need to know are aware of the bug.

It is not what you wrap, but how you wrap it. There were some issues with SourceTree related both to embedded version of Git and GUI itself. I don't know all the details, but the latest version works fine again, and yes it was never really lightning fast.

Nitpicking... at least you can jump...

Can't argue that... Problem is that expansion to other platforms started as customers request. If we all knew then what we know now, maybe things would play out differently.... on the other hand, maybe not... when you have need to support other platforms and your toolset does not have them, you have to find some that does... when you start moving away, sometimes you may be inclined to move away completely. Also, development team shrinking process happened after expansion to other platforms... Quite unexpectedly, if I may say, because at that point it should have been obvious that more platforms means more work and more work requires more people, not less. We can argue here until the end of the world, but how can you argue anything when actual events (decisions) defy all logic. For all we know, maybe even without additional platforms Windows side would be in similar position as it is now.

Lack of resources, maybe... they have to provide proper support for platforms they have expanded to, Apple and Google have their requirements and their own toolsets and don't care much about other people's problems - with notable exceptions - but again only when it is in their own interest. In that light... Windows can wait for any improvements, regardless of how many customers would actually benefit from better Windows support.