xaml island Ask if Embarcadero will integrate UWP & WinUI in comming Version of Radstudio

[bravesofts 28]

hello every one

my question is :

 

Will Embarcadero Integrate UWP & WinUI in the Upcoming RAD Studio Versions?

For years, Embarcadero has been a leader in wrapping and integrating native APIs seamlessly into RAD Studio, allowing Delphi and C++Builder developers to interact with platform-specific features with minimal effort. From Win32 to FireMonkey, from VCL to the FMX framework, RAD Studio has consistently evolved to support modern development needs.

However, as we move further into the Windows 11 era, one question remains: Why hasn’t Embarcadero fully embraced UWP (Universal Windows Platform) and WinUI , despite the fact that it has successfully wrapped almost every other aspect of Windows development?

A History of Embarcadero’s API Wrapping Success

Embarcadero has a proven track record of abstracting complex platform-specific technologies into developer-friendly interfaces. A perfect example is how they handled Android development—by implementing a powerful JNI bridge, they successfully enabled Delphi developers to access and use Android native libraries in a fluent, object-oriented manner.

The TImport<T> generic approach allowed Delphi developers to seamlessly bind Java static class methods to their object or instance methods, making Android development feel natural and productive inside Delphi. This was a massive success, removing the usual pain points of dealing with JNI manually.

The Case for UWP and WinUI

Now, let’s talk about Windows.

Microsoft’s WinUI 3, the latest iteration of its modern Windows UI framework, is positioned as the future of Windows desktop applications. While VCL remains the most powerful and native way to develop Win32/Win64 applications, many developers are looking toward modern UI frameworks like WinUI to future-proof their applications.

Delphi already provides built-in support for WinRT, offering low-level access to Windows Runtime APIs. However, full-fledged support for WinUI controls inside the VCL/FMX framework is still missing. While developers can manually use XAML Islands, the process is cumbersome and lacks true design-time integration inside the Delphi IDE.

What Could Embarcadero Do?

1. Introduce Direct WinUI Controls Support in VCL and FMX:
   • Embarcadero could wrap WinUI 2 & WinUI 3 &+ controls in a native VCL/FMX layer, similar to how TEdgeBrowser integrates WebView2.
2. Provide XAML Island Support with Design-Time Integration:
   • Currently, manually embedding XAML Islands is complex. RAD Studio could add native support for hosting XAML controls inside TForm with a corresponding manifest key to make XAML Island design-time integration seamless.
3. Enhance the Windows Runtime (WinRT) API Integration:
   • While Delphi has WinRT bindings, they could be extended to support higher-level abstractions, making them easier to use within VCL and FMX applications.

A Golden Opportunity for Embarcadero

Many of the requested features could be easily implemented with the Universal Windows Platform. However, the application is complex, and it's the outcome of many years of development by different teams. As such, rewriting it from scratch with a new technology like FMX or (VCL + TDirect2DCanvas or StyleControls ThirdParty Lib or Fake Windows10 Controls like TSplitView, TSearchEdit, TRelativePanel, TToggleSwitch, TActivityIndicator, TNumberBox, TDatePicker and so on ?)   isn't an option on the table!!.

Embarcadero has always been at the forefront of making complex API interactions simple. It was true when Borland embraced Win32 in its golden age, and it remains true today with the success of FireMonkey and the JNI Bridge.

With built-in support for WinRT already in place, the next logical step is to wrap WinUI 2 & 3 &+ controls and integrate them into the Delphi IDE. This would bring native, modern UI capabilities to RAD Studio while maintaining Delphi’s ease of use and productivity.

While Embarcadero still hasn’t embedded XAML Islands into the IDE, Delphi developers are logically losing access to a wealth of golden libraries that could otherwise be leveraged in Delphi desktop applications. The longer this remains unsupported, the more opportunities are missed to modernize Windows application development in Delphi.

Final Thoughts: The Future of Delphi & RAD Studio

With Windows 11 pushing developers toward WinUI 2 & 3 &+ and modern app architectures, it’s time for Embarcadero to take the next step. The same ingenuity that led to the powerful Win32 wrapped controls by Borland before and the successful WinRT Bridge units should now be applied to WinUI 2 & 3 &+, allowing Delphi developers to build truly modern Windows applications while keeping the performance and simplicity they love.

So, the big question remains: Will we see a WinUI integration in the next version of RAD Studio? We certainly hope so! 🚀

 

Edited Sunday at 03:58 AM by bravesofts

[pyscripter 737]

28 minutes ago, bravesofts said:

Microsoft’s WinUI 3, the latest iteration of its modern Windows UI framework

Not quite.   See for instance Ohh...WinUI3 is really dead! - When can we expect the announcement? · microsoft/microsoft-ui-xaml · Discussion #9417

 

The Microsoft strategy for GUI App development is utterly messed up:

• WinForms
• WPF
• Xamarin Forms
• UWP
• WinUI3
• MAUI

And there is no longer a GUI designer.  You have to develop XAML in a text editor.  Discussion: WinUI 3.0 XAML Designer · Issue #5917 · microsoft/microsoft-ui-xaml

Edited Saturday at 11:26 PM by pyscripter

[bravesofts 28]

14 minutes ago, pyscripter said:

And there is no longer a GUI designer.

That's a valid concern, and I agree that Microsoft's UI strategy has been quite fragmented over the years.

However, while WinUI 3 may not have gained the traction Microsoft initially hoped for, it is still the underlying UI framework for Windows App SDK. Many of Microsoft's own apps, like the new Windows Settings app, use WinUI. Even if WinUI 3 itself doesn’t evolve into the dominant framework, its components and architecture are still part of the modern Windows development ecosystem.

Also, XAML Islands are still actively maintained, allowing WinUI 3 controls to be embedded into existing Win32/VCL apps. This presents a great opportunity for RAD Studio to bridge the gap rather than requiring developers to migrate to Microsoft's inconsistent ecosystem.

Regarding the lack of a GUI designer—yes, it's a drawback, but that’s exactly where Embarcadero could step in. RAD Studio has always excelled in visual design, and integrating WinUI 3 with Delphi’s existing design-time capabilities could provide a much better experience than Microsoft’s current tools.

Even if WinUI 3 fades, the demand for modern, fluid UI in Windows applications won’t disappear. The question is: Will Embarcadero seize the opportunity to offer an elegant solution for Delphi developers?

[Anders Melander 1946]

I think your arguments are all over the place but ignoring that, IMO they will not, and should not, waste resources on WinUI3. It's DOA and has no 3rd party support.

Move on.

 

2 hours ago, bravesofts said:

For years, Embarcadero has been a leader in wrapping and integrating native APIs

LOL. Compared to what? Clipper?

[bravesofts 28]

30 minutes ago, Anders Melander said:

WinUI3. It's DOA and has no 3rd party support

"If WinUI 3 has 'no 3rd party support,' why does Microsoft itself list Delphi and Java as third-party technologies in their official documentation?

GitHub link: Microsoft Windows-AppConsult-XAMLIslandsLab

Seems like Microsoft disagrees with your claim. Move on. 😉"

[bravesofts 28]

The fact that Microsoft includes Delphi and Java as third-party tech in official XAML Islands documentation shows that they acknowledge these technologies in modern Windows UI development. If WinUI 3 had 'no third-party support,' Microsoft wouldn't even bother addressing interoperability at all !!.

 

XAML Islands and WinUI 3 are different, but both serve to integrate modern Windows UI with existing technologies. If anything, XAML Islands proves there's demand for bridging WinUI with third-party tools like Delphi."*

[bravesofts 28]

1 hour ago, Anders Melander said:

LOL. Compared to what? Clipper?

You're too fixated on the idea that WinUI 3 is 'dead.' Regardless of its status, we need to catch up after our long absence from modern UI development. Whether WinUI 3 is thriving or struggling, the fact remains: it's a framework that allows for modern, sleek UI, smooth animations, and seamless access to WinRT APIs. Can you achieve the same level of design and fluidity as others using only native Windows libraries?

 

Right now, we don’t even have proper documentation on how to use bindings for WinRT.

It pains me to browse GitHub and see people with other Programming languages building stunning applications using nothing but Windows libraries, while in the Pascal section, searching for anything related to WinRT feels like a joke!!.

 

Even if we classified HTML as a programming language, it would still have better access to advanced WinRT libraries than what we currently have in Pascal. That alone should tell you something...

Clipper or else .. Since Delphi community still focus on bad ideas like WinUI is DOA !!

-------------

Clipper or else…? That’s an interesting comparison. Meanwhile, other developer communities are pushing forward, integrating modern Windows APIs, and making the most of what’s available.

If the Delphi community keeps clinging to outdated ideas—like insisting WinUI 3 is DOA instead of actually exploring its capabilities—we’ll just keep falling further behind.

Whether WinUI 3 thrives or not, at least others are building modern UI, leveraging WinRT with ease, and creating stunning applications. Meanwhile, we're still debating if we should even try. That’s the real issue.

Edited Sunday at 02:46 AM by bravesofts

[Anders Melander 1946]

By "3rd party" I mean 3rd party libraries. They seem to have all abandoned WinUI3. Likely because there isn't any demand from their customers.

 

32 minutes ago, bravesofts said:

why does Microsoft itself list Delphi and Java as third-party technologies in their official documentation?

GitHub link: Microsoft Windows-AppConsult-XAMLIslandsLab

Come on. That document is 6 years old but even if it was written yesterday it wouldn't make WinUI3 any more relevant. Try harder.

 

29 minutes ago, bravesofts said:

If anything, XAML Islands proves there's demand [...]

How does the existence of XAML Islands "prove" a demand? Do you understand that "prove" implies that "proof" exists?

 

11 minutes ago, bravesofts said:

You're too fixated on the idea that WinUI 3 is 'dead.'

My mention of Clipper was in reference to your hyperbolic claim that "Embarcadero has been a leader in wrapping and integrating native APIs".

If anything they have been known for lacking behind their peers, such as C++, C# and Java in this regard, so how can they be a leader?

 

Delphi is very good at wrapping native APIs but the potential future existence of these wrappings doesn't make it a leader. They have to actually exist.

 

Anyway, I've already spent more time on this topic than I care. Peace Out.

[bravesofts 28]

You keep shifting the goalposts. First, it was 'no third-party support,' then it became 'no third-party libraries,' then 'no proof of demand,' and finally, a critique of Embarcadero.

WinUI 3 may not be mainstream, but dismissing it entirely while ignoring its capabilities is shortsighted. The real issue isn't whether WinUI 3 is 'dead'—it's that Delphi developers are often late to adopt modern Windows technologies, which only widens the gap.

If you truly believe Delphi lags behind, maybe it's because of this very mindset. Instead of dismissing everything outright, we should be pushing for better integration and innovation.

Anyway, if you're done, that's fine. Some of us will keep exploring new tech instead of writing it off. Cheers.

Edited Sunday at 03:32 AM by bravesofts

[Fred Ahrens 63]

A while ago we used this blog post https://blogs.embarcadero.com/delphi-winui-3-demo/ for our own tests with WinUI 3. 

After some days we decided it might be easier and better to switch to MS dev tools as they could/should have better dev support - all with the background that MS promised WinUI 3 support also for Win32 applications. But whatever we have tried, every related document and support article was pushing to .Net frameworks for WinUI 3 implementation. Let's just ignore here the unbelievable complexity of creating WinUI3 UIs.

Doing some assessment about what we want and could achieve with WinUI 3, it came down to UI design - we couldn't find any other technical advantages that would benefit our projects. After seeing a Delphi demo showcasing an almost perfect UI mockup of the Windows Settings app that used standard components, it became clear to us, the interesting part of WinUI 3 apps is just the UI design - and this can be achieved in Delphi as well. This Settings app even started on Windows XP.
This mockup of course wasn't 100% perfect (e.g. transparency effects didn't look like in WinUI3 apps) - but even here some clever programmers deliver some "render magic" for FMX apps that even replicate those transparency effects perfectly. 
All this without inheriting the platform and framework dependency that you get with WinUI 3.

 

BTW: This discussion feels similar like the discussion some years ago about Embarcadero should support Windows Phone as target. At the end it was the right decision to wait for Windows Phone getting some more traction before bigger investments will be done.

[bravesofts 28]

36 minutes ago, Fred Ahrens said:

BTW: This discussion feels similar like the discussion some years ago about Embarcadero should support Windows Phone as target

I completely disagree with your statement. You have oversimplified and diminished the significance of WinRT & WinUI by reducing them to mere "UI design," which is a common but outdated misconception. The reality is very different—those who can seamlessly and efficiently leverage these system libraries are the true masters of desktop programming, whether people like it or not.

Let’s be honest with ourselves: by relying entirely on FireMonkey as a one-size-fits-all solution, we are pushing ourselves toward obsolescence. If we keep treating FireMonkey like some kind of ultimate tool or a magical fix for everything, we will soon find ourselves irrelevant in the world of professional software development.

Desktop Development is More Than Just Beautiful UI

Building desktop applications isn’t just about fancy interfaces—it requires deep system-level control. The real power of WinRT & WinUI lies in their tight integration with the Windows ecosystem, offering native system services, APIs, and deep OS interactions that simply cannot be replicated by a cross-platform framework like FireMonkey.

I challenge anyone to effortlessly call and manage WinRT services using Delphi’s built-in bindings and interop features without hitting major roadblocks. If you think WinUI is just about UI aesthetics, you are missing the bigger picture.

The False "Lack of Demand" Argument

Another common misconception is that there is no demand for native system libraries from customers or major software vendors like Embarcadero. This argument is flawed because how can developers reject something they haven’t even had the chance to experience? It makes no sense to assume that programmers wouldn’t want direct access to powerful, built-in Windows features without relying on third-party libraries.

The Real Reason Behind Delphi's Lack of Focus on WinRT & WinUI

The truth is, third-party component vendors have a vested interest in keeping Embarcadero away from fully embracing native Windows APIs. Why? Because if Delphi had first-class support for WinRT & WinUI, developers wouldn’t need to buy so many external, expensive third-party components to achieve what should be standard functionality in a professional development environment.

Final Thoughts

If Delphi continues to ignore the power of native Windows development in favor of an all-in-one cross-platform approach, it will gradually lose its place in the desktop programming world. True desktop developers need full control over the operating system—not just a nice-looking UI.

It’s time we stop fooling ourselves and start recognizing the real value of native system libraries before it’s too late.

[Fred Ahrens 63]

2 hours ago, bravesofts said:

I completely disagree with your statement. You have oversimplified and diminished the significance of WinRT & WinUI by reducing them to mere "UI design," which is a common but outdated misconception. The reality is very different ...

I just wanted to provide a real-world example why developers decide against implementing WinUI 3. We found easier and (for us) more robust paths for implementing technology that we (=our customers) need in our applications. At the end we have a business to run - WinUI 3 won't put more money in our pockets. - I'm still talking about our little world here and not Delphi in general. But I should also add that I see desktop apps in general as a dying species and expect more transition to web based apps.

 

Your demand for new technology seems to be completely different compared to ours. And that's of course absolutely fine.

[eivindbakkestuen 55]

The above posts make a perfect case for why Ctrl+B should be used sparingly.

[bravesofts 28]

11 minutes ago, eivindbakkestuen said:

The above posts make a perfect case for why Ctrl+B should be used sparingly.

Bold ideas deserve bold formatting...

If the argument is strong, the formatting shouldn't matter, Formatting aside, do you have any thoughts on the actual argument?

or should i switch to italics next time !!—just for variety😉

Edited Monday at 01:58 AM by bravesofts

[Der schöne Günther 332]

Embarcadero has been having too many coals in the fire for years now. Instead of opening the next can of worms, they should be fixing basics like code completion.

 

I remember being in the Microsoft Technology Adoption Program where you got Teams meetings with the developers behind WinUI and other Windows components, got shown not yet released roadmaps and got to ask questions. Back then, it was basically impossible to properly use WinUI outside of Microsoft's Visual Studio (not sure if it was WinUI2 or 3). At that time, they openly replied to me that they had no plans to change that.

 

On 3/22/2025 at 11:50 PM, bravesofts said:

Embarcadero could wrap WinUI 2 & WinUI 3 &+ controls in a native VCL/FMX layer, similar to how TEdgeBrowser integrates WebView2.

Except WebView2 has been usable for basically everybody from everywhere, and it's actually good. You can see it being used in a lot  of software, not just Microsoft's own products. 

Just look at how much stuff Microsoft has abandoned in the last couple of years, how much of the "Universal Windows" approach has been dialled down or completely removed already. Not to mention that new GUI stuff has been highly dependant on the most current Windows version. WebView2 even works in Windows 7.

 

I honestly was interested in WinUI around 2018 to 2020 or so, but it certainly never took off. I firmly believe it is not relevant anymore.

[MichaelT 8]

On 3/23/2025 at 2:35 AM, Anders Melander said:

I think your arguments are all over the place but ignoring that, IMO they will not, and should not, waste resources on WinUI3. It's DOA and has no 3rd party support.

Move on.

 

LOL. Compared to what? Clipper?

xHarbour Builder Rulez:)

[MichaelT 8]

On 3/22/2025 at 11:50 PM, bravesofts said:

hello every one

my question is :

 

Will Embarcadero Integrate UWP & WinUI in the Upcoming RAD Studio Versions?

 

A Golden Opportunity for Embarcadero

 

So, the big question remains: Will we see a WinUI integration in the next version of RAD Studio? We certainly hope so! 🚀

 

Yet another Microsoft frontend technology? Microsoft do have a capability to provide the technology, the tool chain, the tools and the IDE or their 'Community' does.

 

The Delphi approach matters for mid-sized applications as result of Microsoft or Apple denying the necessity for dialog based applications in the 1990s, which have been covered by various web technologies later on. I doubt that it makes lots of sense to integrate another GUI technology in anything else but a development environment pretty similar to PyScripter.

 

For different reasons the have always been small applications in a Win 3.x tradition (utilities with GUI) and the real big/complex ones. For the latter C/C++ setting up bigger teams paid. In both cases no one ever needed a GUI designer and for the first the shortcomings of MS GUI technologies concerning GUI in case of Visual C/C++ didn't hurt. VW was the solution for the dialog based applications and those were mid-sized. VB suffered from the OLE and/or early COM approach to let the business developers design the GUI and the business logic and the controls and such stuff should have been implemented  in C/C++. Remember Microsoft touting the return to one development language and that was the C language and C++ later on.

 

The golden opportunity these days arose wtih so called Y2k Bug and companies investing in replacing the IBM Mainframe/Host and the growing of the finance industry in the 1990s.

 

The VCL approach is lean enough and still does it's job pretty well, but for most of us. 

 

For the last decade or longer developer face/experience a certain kind of meta programming, in a different sense but the original one, by JetBrains or special development environment aiming at a certain technology. PyCharm vs. Wing and 20 other alternatives. PyScripter shows in lists of the 10 top Python development environments, while the Wing IDE requires a top 20 list in order to show up. A few years ago, Wing was ranked number 2 or 3 and fell back year by year. If people want a Thonny on steroids there is nothing EMB could do against. Have a look at VS Code or the new JetBrains IDEs. Since the shift to this century we see strong trend into direction of 'terminal style' development combined with more sophisticated and specialized technological underlying. So we can just say, GUI driven development found it's place, but has been a tiny rabbit-shit on the long time-line in which GUI focused programming in addition had it's decade in the 1990s.

 

Third-party does not mean, not being in the position to implement your own widget-set, it means that writing ones own widget set is simply to expensive in a sense of time consuming. Even in case of WPF the controls shipped can be regarded as a sound proof of concept of the underlying technology.

The idea of 'the GUI technology' is a very Microsoftish thing. To mimic the GUI is by far an/the approach enjoying broader acceptance on even on a mid-term already. 

 

...

 

Heavy rings on fingers wave
Another star denies the grave
See the nowhere crowd, cry the nowhere cheers of honor
Like twisted vines that grow
Hide and swallow mansions whole
Dim the light of an already faded primadonna

(Metallica, The Memory Remains)

 

Love the title of the song :)

 

Beside all your valid thoughts and arguments from a technical perspective, let's say it that way, 'If you are still developing VB-style at the age of 30, you must have done something wrong and using RAD Studio for that changes nothing concerning this remark' - not talking about you.

[bravesofts 28]

3 hours ago, MichaelT said:

Have a look at VS Code or the new JetBrains IDEs. Since the shift to this century we see strong trend into direction of 'terminal style' development combined with more sophisticated and specialized technological underlying. So we can just say, GUI driven development found it's place, but has been a tiny rabbit-shit on the long time-line in which GUI focused programming in addition had it's decade in the 1990s.

 

3 hours ago, MichaelT said:

Beside all your valid thoughts and arguments from a technical perspective, let's say it that way, 'If you are still developing VB-style at the age of 30, you must have done something wrong and using RAD Studio for that changes nothing concerning this remark' - not talking about you.

🔍 Will GUI-Based Development Go Extinct? 🤔

Some argue that GUI-based development is fading away in favor of code-centric or terminal-driven development.
However, the reality is quite different: GUI development is evolving, not disappearing.

 

🧐 Why GUI-Based Development Won't Disappear?

 

1️⃣👨‍💻 Humans Prefer Productivity and Speed

• People naturally gravitate towards tools that enhance efficiency and reduce complexity.

• Development environments like Delphi and RAD Studio provide rapid application development, a demand that won't fade away anytime soon.

• Even with AI-powered coding assistants, GUI tools remain a time-saving necessity in many domains.

• Most developers prefer being productive rather than just looking like hackers typing endlessly in a green-on-black terminal.

• Writing code should be about building real solutions efficiently, not about proving how much you can type without a mouse!

2️⃣ 🚀 AI Is Enhancing GUI-Based Development, Not Replacing It

• AI-powered tools like GitHub Copilot, JetBrains AI, and AI-driven refactoring are deeply integrated into GUI-based IDEs.

• Delphi, C#/.NET, and Python IDEs now leverage AI to accelerate development, proving that GUI-based environments remain essential.

3️⃣ 🏢 Businesses Need Ready-to-Use Tools, Not Just Code

• In the real world, businesses prioritize rapid, efficient software development.

• Companies aren’t interested in reinventing the wheel—hence, RAD (Rapid Application Development) environments remain highly relevant.

• Delphi, C#/.NET, and even Java-based UI frameworks continue to play a critical role in enterprise solutions.

4️⃣ 🛠️ Clean Code and GUI Development Are Not Mutually Exclusive

• Some mistakenly believe that GUI development leads to messy, unstructured code, which is far from true.

• Modern Delphi supports clean architecture, OOP principles, design patterns (MVVM, MVP, SOLID), and well-structured projects.

• Many Delphi projects today adhere to clean coding practices just as rigorously as C# or Java applications.

-----------

🔹 The False Comparison Between Delphi and VB

✅ Delphi is NOT just another "Visual Basic"—it is a professional-grade development environment that offers:

• Full-fledged OOP (Object-Oriented Programming) support.

• Robust architectural patterns (MVVM, Layered Architecture, SOLID, Dependency Injection).

• Comprehensive libraries like FireMonkey and VCL for cross-platform and native development.

• Seamless integration with Windows APIs and modern OS features.

❌ On the other hand, VB had fundamental limitations in its OOP and architectural capabilities.
📌 Comparing Delphi to VB is completely inaccurate and misleading.

---

🟢 Delphi Is Continuously Evolving

✅ Delphi Has Strong OOP and Architectural Support

• Delphi has long evolved beyond just "drag-and-drop" development.

• It supports Dependency Injection, Unit Testing, and scalable architectures.

✅ Seamless Integration with Windows APIs, Including WinRT

• While Embarcadero has not natively included full WinUI support, they have provided highly professional WinRT integration using TWinRTGenericImport.

• This approach is similar to their work on Android libraries, offering a clean and efficient way to interact with WinRT.

✅ The Delphi Community Is More Active Than Ever

• GitHub repositories, Stack Overflow discussions, and Delphi-focused YouTube content demonstrate the language’s ongoing evolution.

• Modern Delphi development embraces clean code, architectures, and high-quality patterns.

---

⚡ Final Thoughts: GUI Development Isn't Dying—It's Evolving!

❌ The claim that GUI-based development is disappearing is an oversimplification.
✅ In reality, tools like Delphi are thriving because they adapt to modern development needs.
✅ Delphi is no longer just about drag-and-drop—it supports advanced architectures, OOP, and scalable patterns.
✅ The competition with C#, Java, and C++ does not mean Delphi is obsolete—on the contrary, it's gaining new strengths.

💡 However, if there’s one thing I can guarantee will go extinct, it’s not Delphi itself, but the era of classic, messy "spaghetti code" development.
🚀 Most modern Delphi developers no longer even have the patience or willingness to open old, disorganized projects because of their lack of structure, logic, and maintainability.
🔥 Clean, well-architected code is the new standard—and that’s where Delphi is heading! 

🔥 Delphi will remain a powerhouse as long as it continues to adapt and evolve! 🚀

 

Edited Monday at 11:16 AM by bravesofts
add resume

[Der schöne Günther 332]

Have you considered joining Embarcadero's marketing team?

[bravesofts 28]

Just now, Der schöne Günther said:

Have you considered joining Embarcadero's marketing team?

Haha, no, but I do appreciate well-thought-out discussions about Delphi’s future. At the end of the day, it's all about exploring possibilities rather than dismissing them outright.

[Dalija Prasnikar 1462]

@bravesofts Maybe you would have better chances of convincing people if you would write your own thoughts instead of letting AI write them for you 

 

Delphi already has VCL and FMX frameworks. Feature wise it makes very little sense for Embarcadero to introduce yet another visual framework. Wrapping WinUI can be done through 3rd party, it doesn't have to be supported by Embarcadero. I would prefer that they focus on things that cannot be provided by 3rd party, like: compiler, debugger, language features, IDE functionality.... 

[Lars Fosdal 1830]

12 hours ago, eivindbakkestuen said:

The above posts make a perfect case for why Ctrl+B should be used sparingly.

I agree. Bold-overuse is as bad as shouting in CAPS.

It doesn't improve the delivery of the messages, nor the quality of the arguments.

[Brandon Staggs 365]

Since the Windows 8 debacle, Microsoft hasn't had a coherent GUI/platform strategy. I can't see any reason why Embarcadero would try to chase Microsoft's fleeting "latest and greatest" in that area. They already have VCL and FMX. That's enough. I'd rather them complete their 64-bit IDE and give me an ARM compiler for Windows than bother trying to get Microsoft pinned down on the "right way" to make new Windows projects. It will just change again in a couple of years.

[bravesofts 28]

8 hours ago, Dalija Prasnikar said:

Maybe you would have better chances of convincing people if you would write your own thoughts instead of letting AI write them for you 

 

Delphi already has VCL and FMX frameworks. Feature wise it makes very little sense for Embarcadero to introduce yet another visual framework. Wrapping WinUI can be done through 3rd party, it doesn't have to be supported by Embarcadero. I would prefer that they focus on things that cannot be provided by 3rd party, like: compiler, debugger, language features, IDE functionality.... 

First and foremost, let me start by expressing my deep respect, admiration, and love for Ms. Dalija's response. She is well aware of how much I appreciate and respect her, as I have for many years.

However, please do not take my response personally or interpret it as an attack against you. Despite my utmost respect for you, I firmly stand by my principles, and I am always ready to stand against the whole world if necessary to speak the truth, and I am proud of that.

Now, my response this time might be very harsh, but since it touches on a very sensitive topic, I will not hesitate to defend it with full determination!

First: The Use of AI in My Responses

The claim that my responses are AI-assisted does not bother me at all—on the contrary, I am extremely proud of this technology and hold it in the highest regard. AI is the only tool in our harsh world that has opened the doors of opportunity for people like me, who have limited resources, to keep up with modern technological advancements. I openly and proudly acknowledge that AI has provided me—and many others like me—with golden opportunities that we could have never even dreamed of!

I repeat, I am proud that almost every aspect of my life is assisted by AI. What truly angers me and pushes me to respond harshly, especially on this particular topic, is the elitist mindset that some people have—trying to prevent others from using this technology. I am firmly and strictly opposed to anyone who stands against people's freedom to use AI or who spies on their private activities using third-party tools to "expose" them for using AI, as if that were somehow unfair.

For example, I do not speak English fluently like you do, yet thanks to AI, I now have the ability—at the very least—to communicate with you as an equal. At the end of the day, AI does not generate my ideas from scratch—it simply refines, translates, and enhances them. What’s even more impressive is that it provides me with advice and polishes my words, compared to the raw, unfiltered thoughts that I write in this chat.

Second: My Transparency and Honesty

I take great pride in the fact that I have no problem with people knowing the reality of my life. I am an extremely straightforward person, and I prefer not to use my real photo on my profiles rather than pretending to be someone I’m not. Unlike many people who present a fake online persona that is completely different from their real-life selves, I choose to be completely transparent about who I am. Anyone who follows my posts (if they understand Arabic) will see this clearly.

I have absolute confidence in showing my real self, both in the virtual world and in reality. It does not bother me in the slightest if people know that I use AI tools to express my ideas or write elegant code. So why is there so much negativity and unnecessary propaganda against people who use AI?

Third: A Point About Programmers and AI

Who can say whether I am typing these words with my feet or my mouth, while you type effortlessly with your golden fingers and closed eyes?

Furthermore, one of the strangest fears I see among programmers is the idea that their employers might find out that they use AI for coding! I find this mindset absurd—especially when you see platforms like Stack Overflow banning AI-generated content for questions and answers!

Fourth: The Issue of WinUI Libraries in RAD Studio

Regarding the integration of WinUI libraries by Embarcadero, you stated that this is not the company’s responsibility but rather the job of advanced programmers and third-party developers. I completely disagree with this notion.

WinUI interfaces are not like Android, where it makes sense for Delphi to rely on third-party JNI bridge units. Delphi does not include built-in Android UI components because the Delphi IDE itself can only be installed on Windows.

In contrast, WinUI is part of the core Windows operating system—the only platform where Delphi is natively supported. This makes WinUI components a fundamental right for every Delphi programmer, and they should be available in the Standard component panel, just like other built-in Windows UI controls. Delphi itself was originally designed to wrap Windows components natively.

Additionally, WinUI libraries have been around since 2012 with the release of Windows 8. Today, we are in 2025—how can we justify such a long delay with such an unconvincing excuse? More than 12 years have passed, yet no one has fully integrated WinUI into RAD Studio. Instead, we have poorly implemented Windows 10-style components that are so unconvincing that even hobbyist programmers would not take them seriously!

It’s time to stop lying to ourselves and be honest—as a developer community, we have completely neglected this technology, either out of arrogance or overconfidence in the FireMonkey framework, treating it as a magical solution for all modernization challenges.

However, there is absolutely no logical reason to avoid wrapping WinUI components in RAD Studio. The process is no longer complicated at all, especially considering the advanced state of Embarcadero’s bridging and API wrapping tools. At this point, the only thing missing is UI integration and component wrapping—a golden opportunity for both the Delphi community and Embarcadero itself.

Final Thoughts: WinUI Integration Will Not Distract Embarcadero

Integrating WinUI components will not take significant time away from Embarcadero’s core focus. The company has already implemented almost everything needed. At this stage, there are likely only one or two steps left, and completing them will not divert attention from other critical improvements, such as the compiler, debugger, language features, or IDE functionality.

On the contrary, this addition will increase the development team’s focus on these areas rather than distract them.

Thank you.

the ChatGpt Chat Link here

Edited Monday at 10:38 PM by bravesofts

[Lars Fosdal 1830]

@bravesofts Place a feature request at EMBT's JIRA. Nothing is decided on this board.