Recently I'm working on a game project, and we need to develop some editors for designers to use. While other programmers are all working on Windows, I'm working on Mac OS X. I'm familiar with WPF and Windows Forms development and I'm looking for some GUI frameworks that support data bindings similar to WPF or Windows Forms development.
The GUI framework should satisfy these:
Cross platform
Support data bindings to object (like WPF or Windows Forms)
It's best that it support XML serialization because XML is our data format
By the way, I don't care about the programming language, GUI frameworks based on any programming language are all welcome.
Silverlight runs on MacOS.
It also runs out of browser so you can create an application that doesn't require the browser to be run and hence looks like a regular desktop application.
Depends on the platforms that you want to support, but you could have a look at Moonlight the mono port of silverlight. Have a look at the alternative section of this page:
http://www.mono-project.com/WPF
Knockout.js is said to be good. My colleagues prefer it over Wpf and Silverlight bindings. For instance if you have a fullname prop, which is a result of firstname and lastname, you have to hassle in Wpf with propertychanged, in Knockout.js you define it observable and the runtime makes it correctly notify its observers. It also supports validation.
Although it doesn't have data binding like WPF or Windows Forms, Real Studio does works wonderfully for creating cross-platform applications. And XML is supported, of course.
Try JavaFx, it supports binding better than Java Swing. Also styling is based on CSS instead of Microsoft proprietary style logic.
Both WPF and JavaFX will target the GPU for extra fast rendering; they are comparable and competitor technologies. But JavaFX is cross platform and less likely to be abandoned given Microsoft's track record.
http://www.oracle.com/technetwork/java/javase/overview/javafx-overview-2158620.html
Also, other answers here say Silverlight but Microsoft has abandoned this.
Related
Windows.Forms library contain many bugs which effectively prevent applications from working. WinForms Designer is unable to put WebBrowser control on form. NotifyIcon class doesn't work under LXDE (see the bugtracker of KeePass). Clipboard class is incompatible with default manager of Calculate Linux. Drag and Drop have problems in DockPanelSuite. WinForms Designer is not finished because of opacity problems. WPF was never implemented and no plans to do it.
And mono team says "we don't want to develop WinForms, because this is old technology."
How should one port desktop C# application from Windows to Linux? Rewriting it with Gtk# seems to be too hard...
What is easier - to fix mono WinForms, to implement WPF, or to rewrite all applications in the world to Gtk# ?
As you have already found out Mono WinForms implementation is suitable only for very simple applications. Take a look at "Cross-Platform Desktop UIs" blog post from Xamarin employee Mike James who summarizes available solutions:
Traditional approach
WPF or WinForms frontend on Windows, GTK# frontend on Linux and Xamarin.Mac on Mac OS X. IMO this is the best way to go and it may be easier than it looks if you have correctly separated business and presentation layers in your app.
XWT
XWT toolkit uses the same API and provides native look on all platforms but only a limited subset of components is implemented. Its usability for your projects depends on what components you really need.
HTML frontend
Create HTML frontend using simple WebView component or Awesomium HTML UI Engine. This may be a viable option in some cases but I am not sure whether it is possible to implement systray icons with this approach.
QTSHARP
Open source project which aims to implement .NET bindings for multiplatform QT toolkit. I have never tried it but according to project website it seems to be in early stage and currently tested only on Windows.
BTW I am currently using WinForms for Pkcs11Admin application but I plan to use traditional approach as soon as I hit a blocker bug on any of the supported platforms.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am trying to get my head round the new Windows 8 Runtime that is used to create Metro style apps. I know you can use it with XAML and it is based on .NET so C# and VB.NET can be used to write the apps, but then it seems to have something to do with HTML, CSS, DOM, and JavaScript.
Can someone explain what it is in a few paragraphs, in terms that a .NET UI programmer can understand? (I am missing something “key” that is necessary to understand it.)
We all know that WPF, Silverlight, Windows Forms, etc. will keep working under Windows 8 (and Windows 10) on at least on Intel systems, so please don't tell me that...
At the lowest level, WinRT is an object model defined on ABI level. It uses COM as a base (so every WinRT object implements IUnknown and does refcounting), and builds from there. It does add quite a lot of new concepts in comparison to COM of old, most of which come directly from .NET - for example, WinRT object model has delegates, and events are done .NET-style (with delegates and add/remove subscriber methods, one per event) rather than the old COM model of event sources and sinks. Of other notable things, WinRT also has parametrized ("generic") interfaces.
One other big change is that all WinRT components have metadata available for them, just like .NET assemblies. In COM you kinda sorta had that with typelibs, but not every COM component had them. For WinRT, the metadata is contained in .winmd files - look inside "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\" in Developer Preview. If you poke around, you'll see that they are actually CLI assemblies with no code, just metadata tables. You can open them with ILDASM, in fact. Note, this doesn't mean that WinRT itself is managed - it simply reuses the file format.
Then there are a number of libraries implemented in terms of that object model - defining WinRT interfaces and classes. Again, look at "Windows Metadata" folder mentioned above to see what's there; or just fire up Object Browser in VS and select "Windows 8.0" in the framework selector, to see what's covered. There's a lot there, and it doesn't deal with UI alone - you also get namespaces such as Windows.Data.Json, or Windows.Graphics.Printing, or Windows.Networking.Sockets.
Then you get several libraries, which are specifically dealing with UI - mostly these would be various namespaces under Windows.UI or Windows.UI.Xaml. A lot of them are very similar to WPF/Silverlight namespaces - e.g. Windows.UI.Xaml.Controls is closely matching System.Windows.Controls; ditto for Windows.UI.Xaml.Documents etc.
Now, .NET has the ability to directly reference WinRT components as if they were .NET assemblies. This works differently from COM Interop - you don't need any intermediate artifacts such as interop assemblies, you just /r a .winmd file, and all types and their members in its metadata become visible to you as if they were .NET objects. Note that WinRT libraries themselves are fully native (and so native C++ programs that use WinRT do not require CLR at all) - the magic to expose all that stuff as managed is inside the CLR itself, and is fairly low level. If you ildasm a .NET program that references a .winmd, you'll see that it actually looks like an extern assembly reference - there's no sleight of hand trickery such as type embedding there.
It's not a blunt mapping, either - CLR tries to adapt WinRT types to their equivalents, where possible. So e.g. GUIDs, dates and URIs become System.Guid, System.DateTime and System.Uri, respectively; WinRT collection interfaces such as IIterable<T> and IVector<T> become IEnumerable<T> and IList<T>; and so on. This goes both ways - if you have a .NET object that implements IEnumerable<T>, and pass it back to WinRT, it'll see it as IIterable<T>.
Ultimately, what this means is that your .NET Metro apps get access to a subset of the existing standard .NET libraries, and also to (native) WinRT libraries, some of which - particularly Windows.UI - look very similar to Silverlight, API-wise. You still have XAML to define your UI, and you still deal with the same basic concepts as in Silverlight - data bindings, resources, styles, templates etc. In many cases, it is possible to port a Silverlight app simply by using the new namespaces, and tweaking a few places in code where the API was adjusted.
WinRT itself doesn't have anything to do with HTML and CSS, and it bears relation to JavaScript only in a sense that it is also exposed there, similar to how it is done for .NET. You don't need to deal with HTML/CSS/JS when you use WinRT UI libraries in your .NET Metro app (well, I guess, if you really want to, you can host a WebView control...). All your .NET and Silverlight skills remain very much relevant in this programming model.
From the Build keynote:
They're providing common APIs to both HTML/CSS/JavaScript apps and C#/XAML apps. C# and XAML will be used, but it won't be WPF or Silverlight exactly.
The key idea is that now there is two development tracks - the Desktop and Metro.
The desktop is where the old apps live.
The new class of applications, Metro applications, can be built in a number of ways, including by VB.NET, C# or C++. These three language options can use XAML for building the UI. The alternative is to use JavaScript/HTML5/CSS for the development of both the UI and application code.
Some important points:
Windows 8 feels sort of like an upscaled mobile phone OS.
In Metro, there are no overlapping top-level windows, just as there are none on a mobile phone. If you want an MDI style application, you need to stay on the desktop.
Metro style apps are automatically suspended when not visible. This was done to prolong battery life. This means it won't make sense for many existing desktop apps, which perform background processing even while the user is not interacting with them, to be ported to Metro.
The ARM version of Windows 8 will not support desktop applications. So if you want to write an app and you want it to work on any version of Windows then it has to be a Metro app.
There's modified version of the architecture that'll surely help you understand where exactly the things lies. One of the Telerik ninjas had chat with the CLR team and modified the picture:
Here you can see where the CLR stands. The .NET framework now has two profiles
1- .NET Metro profile (CLR that deal with Metro application)
2- .NET Client profile (CLR runtime for C# and VB.NET applications)
I hope this gives you a clearer picture. Read the full article in A bad picture is worth a thousand long discussions..
Lots of detail from Microsoft here.
The Windows Runtime is exposed using API metadata (.winmd files). This is the same format used by the .NET framework (Ecma-335). The underlying binary contract makes it easy for you to access the Windows Runtime APIs directly in the development language of your choice. The shape and structure of the Windows Runtime APIs can be understood by both static languages such as C# and dynamic languages such as JavaScript. IntelliSense is available in JavaScript, C#, Visual Basic, and C++.
In short, Windows Runtime is a new set of libraries exposing Windows functionality and available to JavaScript/C#/VB/C++. Each language has been made to understand and be able to call them directly rather than having to go through some thunking layer.
Silverlight and WPF are flavors of XAML that run on the CLR. Among other functionality, Windows Runtime exposes a version of XAML very similar to Silverlight, but does so in a native way, not via the CLR. It can be accessed from the CLR, but also from C++.
Given the list of new features announced in Silverlight 4, when is WPF still required?
WPF still has a lot fuller 3D rendering capabilities.
Also even though they announced enhancements to the commanding and binding capabilities, that's no guarantee that it will have the full ability that WPF currently has or will have in the next version
Edit: After playing around with Silverlight 4 beta, it looks like pretty much all of the new features (webcam, file access, full screen keyboard, COM interop, etc) only work when the application is elevated trust, and elevated trust can only be enable when running out of browser. Some of this may change by RTW, but for now, WPF still looks like the only way to do these things inside of a browser window
I've been using mostly XBAPs for browser deployments while waiting for a Silverlight version that includes WPF's full templating and data binding capabilities. Perhaps Silverlight 4 will do it.
Several things that Silverlight 4 definitely won't be able to do are:
Allow you to seamlessly integrate your WinForms and MFC user interface components with your application
Efficiently work with data file structures originally defined in C/C++ (with WPF you can simply copy the code across and easily replicate the original C++ code using unsafe and StructLayoutAttribute)
Include unmanaged C++ code in your application
I have not actually downloaded the Silverlight 4 beta yet, so this list is necessarily incomplete.
The next version of Visual Studio will not be written in Silverlight ;) I can't wait to write an Audio utility in WPF---and Silverlight must be sand-boxed away from the incredible Windows Audio subsystem. However, I can see the day when WPF will be called Silverlight (or perhaps the other way around).
When you don't want to depend on a browser to do your work, when you need full and fast access to the file system without prior confirmation, when doing interop with unsafe bits of code. These are the few I can think of, but they might be other reasons as well, depending on what features Silverlight 4 will really have and how well will they really work.
The applications we (in our company) write today use nothing that is not supported by Silverlight except for local TCP/IP connections without limitations.
This is the only reason we are using WPF.
If we could use Silverlight instead (desktop mode) we'd be able to give our customers
the choice of working on Mac (and linux) systems as well instead of being forced (by us?)
to use a recent version of Windows (you'd be surprised how many companies still use old (partially) unsupported versions).
Even in WPF we try to limit access to the system, we create our own sandbox and
try not to go outside of it. (Never require admin rights, never access stuff you don't have to)
So for what we do, Silverlight + real tcp/ip support would be more than enough...
but there is absolutely still room for WPF and I'm pretty sure it's here to stay.
It all depends on what you're building.
Silverlight will always favor small payloads over functionality. Strategically, Microsoft will attempt to out feature Adobe's offerings using Silverlight, while WPF will be competing against other heavy platforms. If you look at WPF 4 you'll notice a push towards heavier weight features. I try to keep in mind that WPF started out as Avalon which was intended to permanently displace Win32. I won't be surprised if one day Windows XX is "native" WPF and Win32 will be emulated.
If you want to do direct database access through ADO.NET that's not something you'll be able to do in Silverlight 4. Access to devices will still be limited although you will now have some printing support and webcam/microphone. I haven't heard anything about 64 bit support so if you want to offer a 64 bit version of your app you'll need WPF. I also think even if Silverlight 4 makes better use of the GPU, it still won't be to the level that WPF utilizes it.
There are also a ton of other assemblies in the .NET framework that Silverlight doesn't include so if you need any of those you'll need to go WPF.
Just like HTML5 will reduce the need for a plugin like Flash or Silverlight in some cases, Silverlight will reduce the need for WPF but there are still plenty of cases where you'll need it.
WPF is still required if you need to do extensive Rich Text (FlowDocument) editing. Silverlight 4 has the new RichTextBox, but it is limited to very basic content, and doesn't provide the full set of features that are available in FlowDocuments in WPF. A FlowDocument can effectively do what the WinForms RichTextBox can do; but if you only need the basics, a RichTextBox in Silveright may do what you need.
The bottom line is that silver light is limiting. So, if you are going to use a less capable technology you should have a compelling reason for doing so. The only one I can come up with, and it is a big one in some circumstances, is that Silverlight is more platform indifferent. I just can't imagine anyone wanting to bring the browser and all of it's headaches into a solution. There must be a good reason.
Is it possible to build a good medium to full sized application using just silverlight as a host?
A few things that would be needed:
- dynamic pages (one silverlight "screen" can switch between screens, like a normal app.
- similar to a java applet which launches from the browser
I see that Telerik sells RadControls for WPF...but this is only useful (to me) if Silverlight can be a rich client platform through the web.
Although still a somewhat immature platform, Silverlight 2.0 supports many of the features that I would expect from a platform needed to create full sized applications.
Data access through web services and local data/object query support with Linq
Many feature rich controls such as datagrid, treeview, etc
A very usable subset of the CLR (common language runtime)
Access to restricted local storage on the client machine
It is cross platform
There are already some great add-ons, like Telerik and the Silverlight Control Toolkit
For your specific scenario, Microsoft has published a tutorial on Multi-page Applications
Absolutely. I've been looking into this and believe that it's as easy to do in Silverlight as it is in any other language. Remember that Silverlight 2 uses C# 3.0 and from that you can build anything that's not included in the Silverlight version of the CLR. Also, the fact that Microsoft gives you access to the .NET source code means that you can compile the missing parts of the .NET libraries with your application. (No idea about the licensing issues with that though.)
I've seen a presentation of a full featured CRM application two days ago. Although it's still alpha: It looks and feels like any office application. I don't know details but for me it's a proof of concept.
Is it possible to convert an existing WPF Application to SilverLight automatically/with minimal effort?
I would argue that you CAN port Silverlight to WPF with minimal effort. I spent 2 hours porting and application I spent 3 weeks writing. I would argue that those 2 hours spent would categorize as minimal effort.
Sure, you need to create a new project, add the files to the new project and tweak them.
Since Silverlight is a subset of WPF its allot easier to go from Silverlight to WPF than the other way around.
For business logic and non-UI code your code should port almost straight across. I had some minor issues around authentication, as Silverlight 2 will pick up any authentication information in the browser, while in WPF you have to role your own login screen and manage cookies etc.
For the XAML it will port straight across if you don't style your controls. If you style your controls the use of the Visual State Manager, currently missing in WPF, will make things a little trickier. You can either re-style your controls in WPF using Triggers, or you can use the VSM implementation for WPF done by John Gossman. Microsoft have announced that they will add the VSM to WPF to make the two frameworks more compatible.
The perhaps most important reuse tough, is skills and experience. Since the two platforms are so similar you will be able to reuse all your skills in WPF.
I recently did a blog post about the Dive Log sample application and how I ported it from Silverlight 2 to WPF. Might give you some idea of the process.
Not really. I have found some articles regarding the multi-targeting option for WPF and Silverlight at the same time. At this moment, if you are not using PRISM, it is quite a challenge to target both of them, fortunately achievable.
What do you need to have in mind is that Silverlight uses a smaller (thus more limited) library than WPF.
In response to the comments:
Actually, there is already support for silverlight in PRISM (v2). The idea of PRISM is to provide guidance to developing applications not only using WPF but using Silverlight also - Prism V2 formally was known as Composite Application Guidance for WPF and Silverlight.
By using PRISM for silverlight capabilities, it would give you the warranty that your code would work on both platforms with minimal changes, if none (except maybe the different project types for visual studio).
But of course, if you already started developing your application, you would need to change your code to use PRISM.
Will and Bogdan's answers are correct. The keyword here is "minimal".
Rob Eisenberg has a list of differences here (though this was pre-RTW).
List of Differences in WPF & Silverlight
No. Silverlight runs in its own cut-down version of the CLR. It also is WPF-like, not WPF. You'll have to do a fair amount of work to convert it.
Times have changed. Check out Portable Class Libraries, now supported in .NET 4.0. You can build assemblies that can be used on different supported platforms: WP7, Silverlight WPF and even XBOX applications.
Here is a thread about this:
http://silverlight.net/forums/t/3898.aspx