This project is still under active development. If you can provide more information for how you got the error in a bug report on GitHub then we will certainly look at fixing it.
Is that the VCL or the FMX library? VCL should be nothing more than a wrapper around native windows controls, FMX emulates native controls in a cross-platform framework. I would find it surprising to see these sorts of bugs in VCL, not in FMX.
Edit: never mind, I see the mac window controls, so FMX it is, and that’s the explanation. Those aren’t mac controls at all, they’re emulations of mac controls.
As a Python dev, and a former (longtime) Delphi developer, I figured I'd give the pip module and test code a whirl. The VCL (and Delphi's IDE) were fantastic RAD tools in their day.
It immediately crashed with a pointer error. So not off to a swimming start. Both strace and gdb immediately browbeats my Ubuntu when I try to look into why it's banjaxed, forcing me to reboot it. Ugh.
I think, much like even-versioned releases of Delphi -- which were famously half-baked and buggy, and you'd inevitably end up dealing with a confluence of bugs until the odd-released version came out a year or two later -- this one could do with a bit more time in the oven.
> It immediately crashed with a pointer error. So not off to a swimming start. Both strace and gdb immediately browbeats my Ubuntu when I try to look into why it's banjaxed, forcing me to reboot it. Ugh.
Delphi, or indeed Kylix, and any subsequent incarnation thereof, has had some form of Linux compatibility going back probably decades at this point. I have no idea if Delphi still does. But it used to, anyway. So not an unreasonable baseline assumption for a Delphi dev to make in 2023.
The github page for the module also claims Linux support; but of course, as we all know, that is a moving and irregular target :)
I just tried on Ubuntu 22.04.1 and the included sample apps worked. I was able to run Simplest.py, ToDoList.py, controlsdemo.py, and HelloDelphiFMX.py.
> I think, much like even-versioned releases of Delphi -- which were famously half-baked and buggy, and you'd inevitably end up dealing with a confluence of bugs until the odd-released version came out a year or two later
I still remember, like some XE(n) version had a really unstable ide/debugger and they didn't even bother fixing it, you had to wait till the next version was released (and you had to pay for it) for the bug to be fixed. There was even some guy that decompiled the ide and offered free fixes online for some more annoying bugs.
This sounds like it might be an issue with how you installed Python. This is something we are working on improving and there is more information on GitHub
Looking through the installation scripts that you have linked to, it appears that the entire python installation must be within the /Delphi4Python directory and not in the usual directories on Linux? Also, the script downloads the python source files and compiles it with the -enable-shared option selected.
That is a strange requirement which will limit the usage of delphifmx.
From the discussion yesterday on Small Visual Basic (https://news.ycombinator.com/item?id=34287417) and also Gambas, Lazarus, Xojo, and other easy and beginner friendly visual IDEs, I was thinking, I really want to have sth like that but with Python instead of Basic or Object Pascal.
So it's interesting to see that today. But it would be nice to have an open source variant of that instead. And also, I don't really just want to have the libraries. I want to have a nice IDE.
So, Python, but what GUI framework? Use an existing one? Which one? Qt? Or some web-based backend, so it could get packaged as Electron app? Or new simple framework? But this is too much effort I think.
And how to do the IDE with integrated GUI designer? New from scratch, or use sth existing? Maybe based on PyCharm?
Those are all the right questions! If you drop me a mail perhaps we could get a threaded discussion going on each of those points? It seems if you have a Gmail address my replies go to spam btw!
The GUI framework needs a lot of consideration.
I wonder if the GUI designer can be a plugin for an existing IDE?
I think the crucial part is the integration with the GUI. You need to hide all the magic about managing the UI and just let the user write event handlers, and not have them worry about blocking the UI.
There's a gui builder for GTK that is sort of VB-like. It spits out a file that you can load with pygobject and then add all your hooks and events. I've used it for some GTK2 projects in the past, only problem is that compiling the python modules on windows seems to be impossible (for me anyway)
It's long abandoned, but there was a Python-based Delphi clone called Boa Constructor based on wxPython. I wonder if that could serve as a starting point for a modern remake.
provided that in no event shall Customer create any Derivative Work that is competitive with or offers substantially the same functionality as the Licensed Software or any other product or software application commercially offered by Embarcadero
A hard pass, sorry. Would be nice to play, though.
Again, I don't have the skills to build this but would sponsor financially and help get it up and running organisationally. This comes up on hn all the time! I was thinking Python, but I could easily compromise on Nim.
My email is in my bio, if anyone is interested please mail me and we can work out how to get a conversation started.
As a person that hates to work with both delphi and python this sounds like hell.
I dislike this so much that I'm willing to settle for java over this.
Because I actually have five years experience in both and what you win in "time" in rad studio you lose in debugging because of how highly opinionated it is. an electron app as bloated as it is, is easier to maintain than this nonsense. Now imagine the unmaintainablity of delphi with whitespace hell of python... Yeah no thanks.
I worked on a millions of LOC of generally not-that-well-written Delphi code back in the day. Aside from the generally not-amazing quality of the code, it was never hard to debug, nor necessarily maintain.
There are many valid criticisms to levy at Delphi and Python, but those ain't it.
Similar. We have fairly large project, a few MLOC with many hundreds of windows/forms, all kinds of IO and whatnot. We've got code in production that was written back in Delphi 3 days (1997) that's chugging along just fine.
The only thing I think is hard to debug is focus related issues, due to the Windows event loop getting in the way. That's hardly a Delphi-specific issue though.
Other than that debugging and maintenance is quite easy. In fact we don't have to spend much at all on actual maintenance, as backwards compatibility has been great in the new versions. For example, the switch from non-unicode to unicode strings took us just a couple of days. And we're in the Nordics so we'd notice quick with our "weird" letters.
> The only thing I think is hard to debug is focus related issues, due to the Windows event loop getting in the way. That's hardly a Delphi-specific issue though.
That and losing the source code for some random, obscure vcl component you found on torry's back in the late 90s :-)
I have desktop product written in Delphi (device control, video, directx, data processing) which is more than 10 years old already. So far I have no problems maintaining it through numerous versions of Delphi.
I see, how many projects have you been part of? How old were they? In the past 15 years, I have seen terrible code bases trying to reinvent grids from first principles to pretty awesome ones with good separation of data and form logic using devexpress that I am proud to be part of and pretty happy developing. This is the kind of experience I have behind me when getting confused by blanket statements.
Translation: trying to use it differently than it was intended. Considering the mentions of Electron, are you expecting it do behave like js in the browser?
That's what I don't understand. VCL is opinionated in ways that should all maps quite nicely to a class hierarchy in Python. What specifically are you thinking off that would look out of place? Method names, maybe - I wonder if they translated those?
Interesting usually junior or medior people have such a strong negative opinion about tools but you touched Delphi so I must guess you have at least a couple decades of experience?
Tools and languages have tradeoffs and it is always more constructive to see them through that lens.
If you want to make a native UI intensive app in no time and iterate quickly, yes Delphi is your tool (remember how crazy fast pascal was building on machines from 20y ago!). Do that in let's say c++ and your experience will be totally different.
Python too has huge qualities for prototyping quickly and gluing apis (to develop ML models for example!).
Usually you like the language because it fits well what you want or like to do.. if you love system programming then Rust or C have a better chance to be marvelous to you.
This library, on the other hand. I ran their sample app and even the one-line text input component has several issues:
- Caret isn't aligned with the letters I type, https://imgur.com/a/OVjB6ru
- Standard keys for navigation aren't supported (e.g. Option+arrows to skip words, which is similar to Ctrl+arrows on Windows, doesn't work)
- Text selection behaves differently from any other application, and it's also misaligned with the characters.
Wouldn't recommend it at this stage.