Jump to content

Dalija Prasnikar

Members
 View Profile  See their activity

  • Content Count

    1067

  • Joined

  • Last visited

  • Days Won

    91

Posts posted by Dalija Prasnikar

  2. Posted

    16 minutes ago, Emil Mustea said:

    Please look at "RAD Studio 10.3.2" in the following link:

     

    https://community.idera.com/developer-tools/b/blog/posts/rad-studio-roadmap-may-2019

     

    I think best option is to keep 10.3.2 for a while because 10.4 has deep changes: LSP for Delphi and unified memory management.

    Unified memory management only affects mobile compilers and if you are developing for Android you will have to use 10.4. Developers developing for iOS will still be able to use 10.3.2 for a while, but probably not for too long... and even for them it would be smart to switch to 10.4 as soon as possible to adjust their codebases.

     

    As far as LSP is concerned... code completion and navigation as well as code insight is pretty much broken as-is... I cannot imagine LSP in its first release being so bad that it would justify staying at 10.3.2.

     

    Also 10.3.2 and 10.4 can live side by side... so you can have both and use version that is more appropriate for any particular reason you may have.

    • Like 3

  4. Posted

    I need to check whether or not current computer time is correct (with some tolerance) and currently have following code.

      

      LTime := TIdTime.Create(nil);
  try
    LTime.Host := 'time.nist.gov';
    LTS := LTime.DateTime;
    // do something
  finally
    LTime.Free;
  end;

    It was working fine (AFAIK) until I upgraded the router and basic firewall setting now blocks port 37 which is used by TIdTime... but allows port 123 (UDP) so I switched from TIdTime to TIdSNTP and it is working again. 

     

    So question is... is TIdTime obsolete... are there any gotchas with using TIdSNTP?  Is it safe to switch to TIdSNTP and don't look back? I need to support Windows 7/8/10 with most common settings (software and hardware). If someone decides to specifically block everything... there is nothing I can do anyway.

  5. Posted

    33 minutes ago, PeterPanettone said:

    We really need a genius who writes an add-in which replaces the native Delphi Code Insight with a working one. Such an add-in should also be highly configurable. I would pay up to $100 for such an add-in.

    Not really...

     

    Main problem with IDE is that it uses different parser... so when compiler changes and gets new features IDE part also needs to be updated with support for new features. That is what is missing here. IDE does not know about inline variables. 

     

    According to May 2019 roadmap https://community.idera.com/developer-tools/b/blog/posts/may-2019-rad-studio-roadmap-commentary-from-product-management this problem will be solved by using LSP (Language Server Protocol) https://langserver.org/ 

    That way, there will no longer be discrepancy between IDE and compiler.

    • Like 1

  7. Posted

    2 hours ago, Chris Pim said:

    Has anyone heard any more about this yet? The dreaded 1st August deadline is 3 weeks away after which we won't be able to give our Android users app updates should we need to.

    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

    Quote

    As of August 2019, Google will require that all Google Play Store applications are 64-bit enabled. Android 64-bit support is actively in the works for Delphi as we speak. In time for this new Google requirement, we plan to kick off our 10.4 beta this summer with support for building Delphi Android 64-bit applications. While the usual beta restrictions do not allow for building and deploying production apps, we intend to include a special beta EULA provision that allows 10.4 beta testers to deploy (production) Android apps to the Google Play Store. We followed the same approach for 10.3 and Google’s API level 26 requirement last summer and that process worked well for our customers. InterBase support for Android 64-bit is also in the works.

     

  11. Posted

    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,

  12. Posted

    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.

     

  13. Posted

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

  14. Posted

    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

  15. Posted

    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.

  16. Posted

    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

  17. Posted

    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. 

  18. Posted

    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

  19. Posted

    3 hours ago, Jose Morango said:

    So this means that for delphi firemonkey developers 1 August is already here? We cannot submit to android store already?

     

    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.

  22. Posted

    3 minutes ago, Rollo62 said:

    But have you considered that a dark theme is probably better to keep your eyesight intact ?

    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.

  24. Posted · Edited by Dalija Prasnikar

    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;

     

    • Like 2

  25. Posted

    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.

×