Has anyone tried ElementsCompiler?
Using it with Swift is free and seems to allow compiling not only for macOS and iOS but Windows and Android too.
I mentioned it earlier on this forum. I haven’t had time to really dig into it, but I plan to soon.
1 Like
Thanks!
“Great minds think alike.” … “Yeah, small minds do too.” 
Actually the saying is “great minds think alike but fools never differ “ 
@Garry liked it, see Recommendation: RemObject's Elements.
Disclaimer, i work for RemObjects — so I’m biased ;), but also, if you have any questions about Elements, I’d be happy to answer them!
—marc
I do encourage everyone to give Elements a fair look and consider adding it to your tool chain. At the very least play around with Swift since it’s free. It’s pretty much the only IDE out there to do that on Windows.
I don’t have any vested interest in their company other than I’d like to see it thrive as I’m a recent convert and customer.
1 Like
How we design user interfaces for Swift for Windows?
I would be too… it might be an approach I could incoroporate into my project
Rick, Garry,
For Windows, our current well-supported options are either WinForms or WPF (I prefer the latter myself, and it’s what we use for Water, our own Windows IDE). You can open Elements project in Visual Studio, where you get full use of the visual designers for WinForms and WPF. (You can work entirely in VS, if you prefer, or you can switch between VS and Water as you see fit, Water is more lightweight).
In general, on all platforms we use the platform-native UI widgets/APIs (ie InterfaceBuilder/Xib/Storyboard for Cocoa, XML Layouts for Android, and we have support for easily editing them in Xcode or Android Studio). But for Windows in particular, the developer experience you get is literally the same as you would if you were using Microsoft’s own languages, since when you open an Elements project in VS, you get the same level of IDE integration as VC# and VB do.
as to “for Swift”, I wanna make a distinct point that Elements completely separates the language from the rest of the tool chain. You may choose to use Swift, C#, Java, Oxygene (our “Next Generation” Object Pascal dialect)*, you can even mix them in the same project — and regardless of language you’re compiling directly against the (in this case) .NET framework, and have access to all its APIs and third party libraries as well. (Similar, on macOS or iOS you’d be working directly against the Cocoa APIs, etc…)
(* I’m leaving out Go because while we fully support that as fifth language, Go is really too limited for WPF or WinForms apps (e.g. no support for classes, which are kinda essential ;). bout you can mix in Go code as well, where needed).
A few helpful links and blog posts:
Make also sure to check out our blog site in general, as well as our docs at docs.elementscompiler.com. Finally, we also have a great support community over at talk.remobjects.com where we’re always happy to answer any questions (but i’ll also be sticking out these parts here, and happy to continue answering questions here, as well!
thanx!
marc
Well… You guys are pushing users to use the competition tools… Eventually they could decide to give up the round trip and just stay there using the languages they offer after a while… You guys should have some kind of compatible WPF Interface Designer integrated and say “Forget Visual Studio” all you need is here.
I’m the type of person that if I hear…
“Use our Tool-X for your developement, but you will have to use Tool-Y or Tool-Z from Microsoft (or whomever) for this part of your work…” then I’ll just go get Tool-Y or Z and walk away from Tool-X…
Sure a carpenter needs a hammer and a saw… but I’m not a carpenter 
1 Like
I think for a LOT of people - the Citizen Developers, the VB crowd - you don’t need to offer everything, but you do need to offer the basics. And that includes a visual IDE.
Elements IS using other people’s language and compiler, so where is the value coming from? Whom do you target?
Xojo had their cult following because they did the 80% that people need very well - but they’ve lost the plot and neglected those 80% over the last 7 years. Maybe they’ll get their act together. I hope so, but I’m not holding my breath.
Elements has a limited amount of time to jump into that space before the big guys figure it out - as Microsoft and Google are known to work on it. If Elements thinks they can succeed as a non-visual environment in an increasingly cross-platform graphical-user interface driven programming World then I think they will just end up as an interesting footnote.
Or in other words: Elements creates interest because it claims cross-platform capabilities - they’ll loose that interest in the not too distant future without a visual IDE when those with a visual IDE finally figure out how to do real cross-platform (after all, Xojo has already proven it is possible).
3 Likes
That’s not true @MarkusWinter. RemObjects use their own compiler, compiling down to CLR CIL, JVM bytecode or machine code. C# is not Microsoft’s language, Java is not Sun’s and Swift is not Apple’s. They are open languages. In actual fact, I think RemObjects do have their own language - it’s called Oxygene.
I think there is some truth in this but it might not be RemObject’s goal. I certainly would love to see a GUI designer in their Fire IDE but, as @dwarfland says they don’t seem to feel that you can make a generic GUI editor. Xojo is proof of that as we all have to resort to the lowest common denominator.
The language called Oxygene is just Object Pascal, the same language we use in Lazarus with modern enhancements introduced with the years, so it’s a DIALECT, not a language; such compiler was even part of Embarcadero’s “Delphi for .Net”, their defunct “Prism” product, included in their RAD Studio. Once Embarcadero gave up the .Net branch, RemObjects continued its evolution under the Oxygene brand and matured its Object Pascal dialect even more. Great dialect by the way.
I didn’t get it. I think you misspelled something here. Maybe “they don’t seem to feel that they can make a generic GUI editor”. Yep, this is a fair point. But not having such ability will shrink their niche even more with the time.
That was just a Xojo administrative choice, already destroyed with the Xojo for iOS. They intended to have a basic set of common components in such way you could write something and compile the EXACT SAME THING to another platform, then Mobile and Web appeared and the “exact same thing” became impossible. The future of Xojo depends of different sets of native components for each platform and decoupling their presentation logic from the model logic as RemObjects intends, and extending the component set for each target platform to levels near to what the native vendor has, but Xojo already have their own “native presentation designer part” a few years ahead, enabling them to introduce the next step they will need to survive a bit faster.
My feelings exactly. The reason I went from decades of .NET to Xojo was because .NET (even though it’s cross-platform-ish) requires the use of Xcode to create Mac UIs.
(which is why I was hoping that you’d create an alternative UI editor to Xcode that could be used with .NET…)
As I wrote on another thread I think there’s some balance between deep unfettered access to everything so you have to use multiple tools and lowest common denominator across all platforms
Xojo does an ok job of balancing this
You can get at most (not all) platform specifics using declares (it would be nice if this was easier but it is what it is) - but the basics you can access are a huge portion of what most apps need
I suppose it would be possible to organize things so that you have
Button
macOSButton
WindowsButton
LinuxButton
at runtime
Then when you run on a Mac you get a macOSButton instance and have access to all its properties at least in code. If you run on Windows you have a WindowsButton and its properties etc
Once you can do something like this I can imagine a way to do this in a designer
cant imagine where I’d have gotten these ideas 
It’s almost like it was your job once!