Elements compiler?

[Rick.A]

@npalardy

there’s some balance between deep unfettered access to everything so you have to use multiple tools and lowest common denominator across all platforms

@npalardy

Button 
  macOSButton 
  WindowsButton
  LinuxButton

It’s not necessary, we just need the native UI solutions but designing separated interfaces for each platform (in the same UI designer), each one will be only “compiled” for each target platform. You just need to create a common interface for your model. In a MVC pattern, you should design the V (view), for each platform, and create a glue code for each platform too, using the native way of interacting and interfacing it with the “virtual common way” YOU desire in the C part (controller). So you don’t care if events have different names, the 100% value is 100 in platform X and 1000 in platform Y, your glue code will take care of if, you assume 100 for the common code but before transferring the event to it, you divide the value by 10 in Y platform to change the range to 0…100 instead 0…1000, those things.

Yep. This is elegant and but adds complexity.

And yes, it will deserve one entire chapter for each interface/platform in the UI Design manual.

[npalardy]

You can see from the rest of the comments that so far none of us wants to design separate UI’s per platform - at least not one for desktop MacOS, one for Windows, one for Linux
Might as well go back to using Xcode for one target, VS for another, gcc etc for another and just share the code logic which is x-platform using svn external or git etc

My point of such a set up like above was I could design ONE UI and still use #if code in the UI to modify those things on a per platform basis
I think it could be somewhere between what Xojo has today which requires per platform declares to get at the custom per platform elements and lowest common denominator

Xojo’s appeal is to the one man or small shops where a per platform UI person, or per platform expert, may NOT be available to write the view for Windows, one for macOS, one for Linux etc etc etc

How many of us here work in shops that use Xojo that have more than 3 people ?

[Rick.A]

@npalardy

My point of such a set up like above was I could design ONE UI and still use #if code in the UI to modify those things on a per platform basis

This will get us to where we are. Desiring more for each platform and not having it. This we already have.

@npalardy

I think it could be somewhere between what Xojo has today which requires per platform declares to get at the custom per platform elements and lowest common denominator

Using “declares” and “talking API calls” in a NOT WYSIWYG way instead of high level standard simplified Xojo calls and dealing with high level Xojo events some even “templated” for us by the “native” interface designer for Xojo feels like astronauts becoming cavemen.

@npalardy

Xojo’s appeal is to the one man or small shops where a per platform UI person, or per platform expert, may NOT be available to write the view for Windows, one for macOS, one for Linux etc etc etc

Here is the true argument. If you feel your target user base can’t grasp “the best way of doing it” because they will think that it is too complex or too laborious for them (this even destroys the argument “what about to use declares?”), the product is doomed to have a toy interface designer with few elements using just basic things. That we already have, again.

[npalardy]

Declares are not desirable
But its what we have with Xojo

As I said at the end of a prior post

@npalardy

Once you can do something like this I can imagine a way to do this in a designer

I believe it IS possible to have a UI designer that can make it possible to design once and customize per platform

[Rick.A]

@npalardy

I believe it IS possible to have a UI designer that can make it possible to design once and customize per platform

Yes. Design something universal, try to transfer such concept as a native one, and adjust the native one.

The coming .NET6 MAUI have platform specific codes, resources and interfaces. Don’t know how it will work together yet.

[HMARROQUINC]

Yup, it’s me, myself and I over here (I do work with a dba guy but only on a when really needed case).

I just wouldn’t have the time/will/resources to work in platform specific UI. I’m not doing that at the moment since currently I’m working on a web app but I have been in the position where I needed to deliver windows and osx apps, Xojo did the job.

[npalardy]

@Rick.A

Yes. Design something universal, try to transfer such concept as a native one, and adjust the native one.

I wouldnt do this

Folks that have expressed an opinion do NOT want to jump into some other tool

Do that we might as well just code in C++ and then use that portable code in Xcode, VS, etc using the core portable code in each tool

[dwarfland]

My apologies for the radio silence — turns out I ran into a limit of how many posts are allowed on a single day for new users, yesterday, so I could not respond any further. Trying to catch up now…

[dwarfland]

@DaveS

Sure a carpenter needs a hammer and a saw… but I’m not a carpenter

And thats fine. Our main target audience indeed is carpenters, to stay within your analogy, not people assembling IKEA

@MarkusWinter

Elements IS using other people’s language and compiler, so where is the value coming from?

It’s not. it is using our own complete compiler tool chain, Microsoft’s C# compiler doesn’t let you build native code for Windows, Linux macOS, or for the JVM. Apple’s Swift compiler doesn’t let you compile for ,.NET or there JVM (or WebAssembly). Ours does.

We have our own language (Oxygene) and we also support five “other people’s” languages — reimplemented ourselves, with additional features, and the ability to target all platforms with either language, and to mix them.

You don’t have to consider that “value”, but I do, and clearly our users do.

And that’s not the whole picture.

@MarkusWinter

Elements has a limited amount of time to jump into that space before the big guys figure it out

Elements has been around for over 15 years. We have solid compiler technology used by thousands of people targeting 6 languages across all major (and some minor) target platforms. We’re not just “jumping into” this space

@Rick.A

The language called Oxygene is just Object Pascal,

“just”. Evolution of the Oxygene Language | Oxygene | RemObjects Software.

@Rick.A

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.

That’s not true. Oxygene has been around since about 2004. Embaradero licensed the Oxygene/.NET compiler from us and marketed it as Prism for a while (mainly to placate their existing user base who wanted .NET, while at the same time marketing to their customers that “.NET sucks” and they should stay with their aging native Delphi product — which is why the collaboration was not along-term success, Embarcadero didn’t care about the product. So eventually (2010’ish) we split ways again.

Oxygene did not derive from Delphi or any other Embarcadero technology, and it’s not like we picked ups their scraps and ran with them, as you make it sound.

@Rick.A

Great dialect by the way.

That part I cannot disagree with.

@Rick.A

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.

No, that’s not the point. We believe one cannot make good native UI for each platform with a generic UUI editor. People, end users, choose macOS vs. Windows, iOS vs Android, etc for a reason, because these operating systems have vastly different tUI paradigms. Yo can make make good apps (that share a lot of code) that have a bespoke UI for each platform, or you can make shitty apps that use a cross-platform UI. You cannot make a good app with a single cross-platform UI. IMHO.

@npalardy

You can see from the rest of the comments that so far none of us wants to design separate UI’s per platform

And thats fine, Elements is not the tool for you then.

@npalardy

Might as well go back to using Xcode for one target, VS for another, gcc etc for another and just share the code logic which is x-platform using svn external or git etc

Not really, but I won’t belabor the point further.

[npalardy]

@dwarfland

Not really, but I won’t belabor the point further.

I guess I’m missing something
If I have to use Xcode to create a XIB for macOS and VS to create the comparable UI for Windows (and lord knows what I use on linux as thats not my area of expertise)

The reason I ask is because using Xcode on macOS and VS on Windows and sharing the common C++ is exactly what I’ve done and that works - its just a pain to create 3 different, but very similar looking UI’s, one per platform.

How does using Elements change this work flow ?

[dwarfland]

@npalardy

I guess I’m missing something
If I have to use Xcode to create a XIB for macOS and VS to create the comparable UI for Windows

What is so bad about using a platform-native designer for each platform?

@npalardy

The reason I ask is because using Xcode on macOS and VS on Windows and sharing the common C++ is exactly what I’ve done and that works - its just a pain to create 3 different, but very similar looking UI’s, one per platform.

How does using Elements change this work flow ?

The main difference would be that you could sue the same compiler and IDE for your code on for all three platforms, and (optionally) have cross-platform abstractions for many (non-UI) tasks that are normally platform-specific. You also have more direct access to higher-level per-platform APIs (eg Cocoa, or .NET), and your choice of 6 more modern languages other than C++.

But I grant you that if you’re already a C++ cross-platform developer, and happy with C++, you’re mostly there and you’re not really Elements’ core target audience.

[HMARROQUINC]

@dwarfland

What is so bad about using a platform-native designer for each platform?

Nothing “bad” IMHO, just time consuming.

[DaveS]

I think if you step back, you will find a common theme here (at least I do)… and to me that theme is most of the developers here envision a different paradigm to their desired way of doing development (be it Xplat or not).

[npalardy]

I’m trying to understand the value proposition beyond “you can code in X many languages cross platform”
Is there one ?
And I’m not asking this this way to just be inflammatory or obtuse. I really would like to hear from someone who works there what they see the value proposition for developers is.

@dwarfland

What is so bad about using a platform-native designer for each platform?

Depends on the audience you’re trying to attract I guess
Some won’t see it as sucky or awkward
Some will
A lot of the folks here are used to a tool that does let you design one UI that mostly works consistently across macOS Windows and Linux that may need tweaks in code

And, if I have to use VS or Xcode why not JUST use those two and not need Elements entirely ?

@dwarfland

But I grant you that if you’re already a C++ cross-platform developer, and happy with C++, you’re mostly there and you’re not really Elements’ core target audience.

And this is suppose is what my question boils down to
What IS the core audience youre trying to target ?

[dwarfland]

@DaveS

I think if you step back, you will find a common theme here (at least I do)… and to me that theme is most of the developers here envision a different paradigm to their desired way of doing development (be it Xplat or not).

That’s fine. This forum is not necessarily representative of our main customer base or target audience; I mainly stopped by because Elements was brought up by others, met kindly by @Garry.

@npalardy

I’m trying to understand the value proposition beyond “you can code in X many languages cross platform”
Is there one ?
And I’m not asking this this way to just be inflammatory or obtuse. I really would like to hear from someone who works there what they see the value proposition for developers is.

There’s many value propositions, different ones for different people. I’ve listed a few before, but no matter how many I list, one can always ask “but aside from that, what’s the value proposition”?

For me and from my (totally biased, I’ll admit) personal point of view, the main value proposition is that I just really love working with the tool chain and IDE, because I can work smoothly and things seldomly get in my way. Working in Visual Studio frustrates me (always has). Working in Xcode frustrates me (u used to love Xcode pre version 4, nbut it has just gotten slow and blated. I like(d) Objective-C, but it stated feeling old a few years ago, and id not want to go back, but I also really dislike Apple’s Swift. Even if id only ever write Mac code, or even if I only ever would write .NET code, I find Elements gives me the more enjoyable work experience.

I really love our version of the languages; the compiler gives great errors and help (especially compared to Apple swift) and is fast, for all platforms. Oxygene as a language is more powerful than any other OOP language I am aware of, and gets better all the time. I prefer coding in Oxygene over most other languages (although I also use (our) C# and Swift, quite a bit.

I love that I can work on our Mac IDE, Fire, or on our build toolchain, EBuild (which are my main two areas of code work) pretty much without thinking about the platform. Most IDE code I write starts on Mac (because thats where I work), but eventually it;'ll just work on .NET in our Windows IDE as well. Conversely when I work own EBuild I mostly start work on top of .NET (because ot compiler always run on .NET), but the code will seamlessly compile for native Cocoa as well (The IDE reuses some/a lot of the build chain code, and it uses the Cocoa native version on Mac).

I love how Fire is always responsive and never makes me wait, never blocks, never goes modal. I can hit build, see a typo and fix it right away and hit build again without delay, and I’ve only lost the 3 seconds it took me to fix the actual typo. Speaking of which, I love how our compiler can (optionally, but by default when debugging) recover from simple errors and typos, so when for the 387th time I notice I typed Stirng and hit built, or forgot a semicolon, I don’t even have to stop the build, I can just fix it, sure, but the compiler will just build and run the build I started and ignore the error (if it can). Crappy typist that I am, that saves me half an hour each day ;).

Many of our customers love that when they report bugs, problems or even feature requests, things usually get fixed within a day or two, and almost always for the next weekly build. And yes, we do weekly builds, so when there is a problem, you’re not stuck for a year or longer waiting for a fix, and there’s also new improvements and features almost every week.

I could keep going, and these are just a few of many value propositions, and in particular the ones that appeal to me.

But “besides all of those”, and many others, yeah, there really isn’t really much of a value proposition

[Rick.A]

What Norman seems not getting from me is that my desired “native GUI editor” would be in the IDE itself (Fire, Water, Xojo, etc) not depending of external 3rd parties like MS Visual Studio or XCode, Android Studio, or others. It could just write some kind of UNIVERSAL declarative XML layouts (something that integrates the concepts known as XAML for MS, or XIB for Apple, but still XML for Android) and the IDE render them as needed and use them at compile time. All inside that unique IDE, not needing MS VStudio or XCode or anything. Besides starting in a “universal” mode, every layout can be fine tuned individually for any target platform as it would be if using separated layout editors as Xcode, VStudio, etc. So a checkbox can be in a different place in a Mac than it will be in Windows, a slider will exist in a Mac and do not exist at all in windows, etc.

[npalardy]

The way you wrote earlier made me think you were just going to have this IDE generate something you’d tweak in VS or Xcode or whatever

I do NOT want to have to jump into several IDE’s to make an app
I’ve done that and dislike it immensely

Maybe I misunderstood your intent in your prior posts ?

[MarkusWinter]

@Garry

C# is not Microsoft’s language, Java is not Sun’s and Swift is not Apple’s. They are open languages.

Microsoft created C#
Sun created Java
Apple created Swift

That they made them open-source later does not change who put the work in and created them (and still holds the reign btw).

[Rick.A]

@npalardy

Maybe I misunderstood your intent in your prior posts ?

Sure. Maybe you missed the context where I criticized the tooling round tripping to get things done.

Elements compiler?

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.

[npalardy]

[/quote]
What is so bad about using a platform-native designer for each platform?
[/quote]

I’d say “About the same as having to rewrite the business logic in a platform specific language each time”

Granted UI’s are NOT identical from platform to platform and IF a tool were to include a “generic” layout designer the it would be nice to be able to tweak it on a per platform basis that would be seriously useful. I have NO idea how this would work.

On macOS a button is much like a Windows button is much like a Linux button etc.
They have a large set of commonality between them.
Qt and wxWidgets would suggest that theres a large degree of commonalty.

I guess I’d just not write that off
As cross platform tool it would be a huge advantage