Trying to get a grip on what developing via Elements really means.
Lets say, I have a C# Winforms project based on the MVP pattern, with
completely passive views, the views only trigger events. All other
code is in their own libraries, completely separate from the winforms code.
Does Elements allow me to re-use the non ui librarys on all platforms?
When it comes to the views, how do we implement those passive views on MacOS and Linux?
If the non-ui library isn implemented to not rely on .NET specific code, yes. We have a cross-platform library for many common things, called Elements RTL (and of course you can also add #ifdef’ed platforms specific code to create your own abstractions where needed), and id the shared code uses mostly that over .NET classes, it can be shared.
In fact, thats how our own IDEs are written. All the non-UI code juries Elements RTL (and, as suggested ab one, a few custom wrapper classes that abstract things not handled by Elements RTL. For example, I have a custom class that unified clipboard access, and one that handles the very particular way off multi-threading that Fire/Water do). For the visual parts, each view then just has a “xaml” (in use WPF, not WinForms, but the same concepts apply) for Water, and a Mac .xib file Interface file, for Fire.
For Mac, you would use xib (or storyboard files), that you can design in Interface Builder within Xcode. Fire has an option to create a dummy project that you can open in Xcode for that purpose to make that convenient, see Working with External Designers.
For Linux, the story is a bt more complicated, as there’s no standard high-level object-oriented UI framework that is easily usable, but we have (for exa please) Gtk bindings you can use (but those are more on a Win32-like level than a WinForms level, I’m afraid. Linux UI is, unfortunately, still a rough area (not just for Elements, but in general).
I suggest checking out these two big posts:
and maybe
Please let me know if this helps, and/or if you have any further questions…
