OK, for reasons I'll explain shortly here is the development schedule for Swift for the next 3 versions (version 3 may not release).

Next version : Source code debugger (largely complete and has been for about 12 months)

Next (possibly last) : Integrate BeebASM again to fix issues caused during other version upgrades

Last (if created) : Incorporate any suggestions that I consider must haves, if no suggestions come forward then this version will not exist.

These mark the last versions of Swift to be built using the Delphi language. After these it will be re-written in another language. This will take some considerable time as it is not a small project so wouldn't expect to see a release for at least a year, so if there are some good and must have suggestions for the final version then get them in as it's going to be some time before any new features.

The reasons for this massive shift is purely that Delphi as a developer language is becoming very rare, certainly in the UK. It had a good popularity some years ago and I myself have worked with it professionally since the very first versions all those years ago (about 15 years, jeeez I feel old). To keep myself employable I need to move on and therefore so does Swift. I will maintain Swift on the last Delphi version for bugfixes until there is a stable version in the re-written app.

As a bonus, we might get a Linux version now !

Good stuff Steve!

Have you considered using Qt as a possible development environment? It's founded on C++, but provides some other extensions, is cross-platform, open-source, and is perfect for writing GUI apps.

Oh, one other thing: if you need some extra facilities added to BeebAsm, let me know, as I intend to put out an update soon. I think in the past the main problem was that BeebAsm can't output a straightforward object code file to the host OS with a filename specified on the command line.

If you like I can add a new command line switch -o <output_file> which could be used in conjunction with a filename-less SAVE command in the source code, to output the file specified in the command line. If that'll make integration any easier, I'll get on to that.

I'd not looked at Qt (or heard of it) before, just had the briefest of looks and I'm very impressed, really like the look of that. In my head the project was moving to C++ or C#. Which one is easier for cross platform, not looked into C# either yet.

IIRC Swift scans a BeebASM source file for the SAVE command to work out the object code file name. But a command line option if it's not too much trouble may make my life easier

Essentially, Qt is a cross-platform layer on top of C++, which tries to provide a platform-agnostic interface to the sort of stuff which is always highly platform dependent, such as the GUI. But, more than that, it comes with its own IDE, and tries to establish itself as a more than just a set of libraries to C++, but a fully featured development toolkit.

I've not used it, but know others who swear by it - and, from what I understand, it certainly has a lot of built-in facilities which make all the common things you want to do in a graphical app really straightforward.

Regarding the other choices, I wouldn't recommend C++ for app development any more, unless you've got some very comprehensive cross-platform libraries to use with it (which is essentially what Qt is anyway).

I'm personally a big C# fan, but the problem with it is it's very Windows-centric. I have no idea how projects like BeebSpriter work (if at all) under Mono, and I'm actually under the impression that Qt gives you a lot more useful functionality straight out of the box. But I like the C# language, and in my opinion the Visual Studio IDE is second to none.

I'll add an output filename switch to BeebAsm, which'll give it the same functionality as any other 6502 assembler. It should then be quite trivial to make it work in SWIFT just like any other assembler (as it'll be possible to bypass all the stuff which adds files to disc images etc).

Yes, I like the the general style of C#, and apart from Swift I don't usually need cross platform. Choices choices... But I really would like Swift to go cross platform and if I don't do it at this opportunity I probably never will. Suppose I could always use both.

A bit less heavyweight, but I've heard WxWidgets is a good C++ library for cross-platform GUIs. It's used by Filezilla and quite a few other programs that tend to look nice, everywhere. It looks to me at first glance to be quite a nice size for a program like SWIFT.

It's worth pointing out that the future of Qt is a bit shrouded in mystery at the minute as it's primary developer, Nokia, has recently committed to a Windows-y future. Qt is certainly not going anywhere - it's huge and used all over the place - at the very worst, I'm sure it would be folded into the KDE guys domain, but it's worth pointing out that there may be some changes in the landscape. Not that I'm suggesting there's any risk with starting a project with it. Just one to watch the evolution of ...

Personally, I'd be reluctant to commit to .NET as a cross-platform solution - Mono is always many versions behind and I don't think Microsoft will ever commit their own resources to develop simultanous versions alongside the Windows releases. Even if they did, there's so much distrust of them based on their own history that - rightly or wrongly - it still wouldn't be likely to get much use in the open source world. If you were going to try out C# and you wanted it to be cross-platform, I think you'd have to try really hard to stick with just the Mono tools and not let the Windows-only .NET extensions etc. creep in.

I'm sure me, Dave J, maybe MartinW and others would be willing to try compiling it on other platforms.

Sam.

I agree, if you're doing noddy commandline stuff C# is OK and will probably run under Mono, but Qt looks the way to go for my money.

I've not looked at it since the days of TrollTech, I had no idea it was still going!

You're kidding?! It's development has actually never been bigger! Well, until the recent announcement ...

When it was owned by Trolltech it was really only famed for underpinning KDE (and due to it's then-non-free licensing, brought about the creation of the upstart alternative Gnome). However, since Nokia bought out Trolltech they've been pouring development resources into it, trying to port it to their mobile Linux platform Maemo, now MeeGo. Not that the outside world has seen a lot from that effort - you have to wonder why they had to put in so much time to port Qt from Linux to ... err ... Linux!

Sam.

Thanks for all your input, sometimes I wish there was only one choice as the choosing can take ages !

Given some of the changes made to GNOME in the upcoming GNOME 3, KDE may well get a lot more popular on the Linux desktop. In addition, the ever popular Ubuntu is looking tentatively at a switch to Qt to underpin it's Unity desktop rather than GNOME.