Memnarch

You are massively underestimating this 😛 If you refactor a base component other visual components dervive from, loading/opening projects might fail. I support the Idea that the ide still loads the dfm as text. Right now it does not allow me to look at it, which is cumbersome. Just like WPF in VS where I always get the XAML editor but not a visual editor when the XAML is invalid.

No that's just confusing wording. The resolution is actually fixed. What the sync comment means is: Expected behavior is seen in fix version. Had the same type of sync comment on one of my tickets and was confused at first, too.

We're already evaluating it. First impression: Promising! However, I'm not sure using GPLv3 is something he should've used, for what he tries to archieve with the dual license.

Exactly. An application has to identify itself as HDPI aware in its manifest. By default this is enabled for your Delphi-Application, but you can disable it. If not enabled, windows passes 96ppi to the application, and all width/height values of all controls are in 96ppi space. Windows then scales up the rendered picture to the actual ppi. This is the reason old applications look blurry. Today, Windows 10 implements a more enhanced gdi virtualization (called System enhanced) where the drawcall is scaled up, instead of the final render, which avoids blurry text/lines. But it's still noticeable on graphics of old applications, being stretched and blurry. You can switch to the old "System" method on an applications compatibility properties tab to see how applications were scaled up pre W10 180x(or was it 190x?) Something you have to credit Microsoft for, is their humongouse backwards compatibility. That's why HDPI was made an opt in, because applications have to manually deal with it. Similar to the WinVer thing they did with Windows 8 and 8.1. If the application didn't say it was aware 8.1 exists in its manifest, the system lied and looked like 8 on the api and file layer. The Delphi-IDE is not marked as HDPI-aware, and recent UI revamps of the IDE made it more incompatible with HDPI than ever. PS: Trick of the day: If you have an old non HDPI application were you draw text or shapes to a temp bitmap, make it device compatible using CreateCompatibleBitmap (TBitmap creates only device dependend ones). That way, when you set it to a resolution of x, the internal resolution of that bitmap is x*systemscale, the gdi system enhanced virtualization will affect it and it won't look blurry. Something the VCL does wrong for some temp buffers 😕

Nope, it's a windows issue The IDE is not supposed to "see" the 115 ppi -.-

WOW i just found out: The reason was me using "custom dpi scaling". I only wanted 115% and not one of the existing settings like 125%. Now it does work as expected....

Hi, At my company, I have 4K screens and a HDPI scale of 200%. The IDE works as normal, because it is not hdpi-aware. Windows is 10 1809 At home I have WQHD Screens and some slight scaling enabled. All IDEs from XE to 10.2 show a PPI of 115 instead of 96 in the Designer. Windows 10 1909 And i can't wrap my head around the issue. I told Windows to disable the system enhanced stuff. But for some reason the IDE is still fed with the true PPI instead of emulated, like normal non hdpi ones do. Anybody has any idea on what i can do? This does screw with ui i write for IDE-Plugins 😐

Hi, I just updated my header translation for LLVM 10. It's available on Delphinus or on my Githubrepo and comes along with the precompiled binary. http://memnarch.bplaced.net/blog/2020/04/llvm4d-llvm-c-headers-for-delphi/

Hi, Some might already know Delphinus. But for those who don't i thought i make a little introduction post, to have a thread for discussion, as I never made one for the international Delphi-Praxis. Questions are always welcome. Delphinus is an opensource Packagemanager for Delphi, which I started in 2015. It has support for Delphi XE and newer. In addition to an IDE integration for package-management, Delphinus comes with a commandline, too. This has the benefit of having a single interface for managing multiple IDEs or run setup-scripts automatically. Currently, packages are provided through Github by preparing a repo to appear in a special Github-Query Delphinus uses to detect packages (See wiki link below). For optimal use, you should add a OAuth-Token to the Delphinus-Config(See wiki link below). Otherwhise you'll hit rate-limits. Offline installation from a folder is provided through the IDE-UI(Folder Symbol). Adding support for creating local folder based repositories for mirroing is planned. Delphinus packages have support for: Copying (source) files Compiling and (if Designtime) installing BPLs Compiling and installing IDE-Experts setting up Search/Browsing path Dependencies to other Delphinus-Packages Optionally, BPLs and Experts may be included as precompiled binary, if your project is closed source. Packages are installed per IDE. I'm working on per project installations. GithubRepository of Delphinus: https://github.com/Memnarch/Delphinus Wiki: https://github.com/Memnarch/Delphinus/wiki My Blog were I (in addition to ther Delphiprojects) post updates about Delphinus: http://memnarch.bplaced.net/ Websetup: http://memnarch.bplaced.net/blog/delphinus/

I started working on support for installing packages per project, instead ide. http://memnarch.bplaced.net/blog/2020/03/delphinus-working-on-per-projectfolder-installation/

In the end, i did summon demons. And succeeded 😄 I'll share what this was all about soon(TM), once the stuff it's for is presentable. Edit: @Dave Nottage here is a blog with details on what it is for:

Hi, Before I start to summon demons, i wanted to ask if it is possible to add non-file related entries under a Project in the Project-Tree through the toolsapi? A Node like the existing ones, for example "Build Configurations" or "Target Platforms". From what i can tell, i can only add something, if it is an existing file?

My Softwarerenderer written in Delphi is now public under MPL-2 :) http://memnarch.bplaced.net/blog/2020/03/mundus-a-softwarerenderer-in-delphi/

AH OK i got the exact situation it happens. Somestimes sfFont is not set in Scalingflags to indicate the font is already at the correct size. But the internal scaling mechanics ignore the property ScalingFlags during loadtimes and use "DefaultScaleFlags" which enforces font scaling. Checking ScalingFlags, i can now properly determine which fonts to scale back to 96ppi after dfm load.

Only do this for Forms/Dialogs/UI that is used VERY frequently and as a huge impact when created for the first time. Consider saving a state in Dataobjects somewhere else otherwhise, if needed.