I'm starting a hobby project in which I would like to have a graphical, touchscreen interface for interacting with a kiosk-like device running on top of Windows XP Embedded. For development of a rich UI experience, I was considering using WPF. However, a number of demonstration videos that I have come across have used Silverlight, while I haven't seen a single WPF demonstration.
It was my understanding that Silverlight was targeted towards website developers, while WPF was more targeted towards desktop development.
So this question has two parts. Firstly, what is the recommended graphical subsystem for development of a rich UI experience on a kiosk-like device hosted on the Windows XP embedded platform? Secondly, if it is Silverlight, which version is suggested (1.0 or 2.0) and why?
It seems that WPF works fine on embedded. See here the second comment.
I think that your choice should be dependent on the type of kyosk you want to build. Some kyosks are just an open browser page. And then you have stuff like Microsoft Surface that can be used like an horizontal kyosk :-)
I would recommend also WPF, have done few kiosk apps using it.
also I would recommend http://fpscomponents.com/Product.aspx?id=8 as a virtual touch screen keyboard software component. it's done in WPF and very flexible and customizable.
User can define custom theme(skin), layout and language of keyboard. guys are working with customers and hear theirs voice so any suggestions might be accepted.
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.
Forgive me as this is not programming related question.
I know ASP.NET as well as WinForms development. I would like to know that if i want to learn windows mobile development how difficult it would be for me to start.
Is there a big difference between the two platforms ?
Is coding style and creating form design too different ?
If you know WinForms then you can most certainly rest assured that the Windows Phone platform will be a breeze to learn. I too came from a WinForms background and I found it pretty much a walk in the park to get in terms with Windows Phone. There are of course subtle differences in WinForms and Windows Phone such as Windows Phone uses Silverlight, which is a toned down version of WPF (Windows Presentation Foundation) which is in turn a powerful version if you like of WinForms.
But again, these are subtle differences and you will easily become comfortable using the Windows Phone API.
There are many tutorials on how to get started. Just google or youtube Windows Phone tutorial and you'll find many.
In terms of Coding Style, there are no real differences. The Windows Phone platform is obviously C# compatible so you can quite literally adhere to the same design patterns as you would with a WinForms application.
The main difference I suppose is the use of XAML. When designing a page, you can drag and drop controls which creates XAML.
I'm interested in making a desktop application which I would want to use as a Desktop Manager. This kind-of goes to Desktop Enhancement Category. My requirements are:
Application has to be visually rich, with panels sliding,fading,wiping,rotating and etc.
It should also support flash playback. (swf, flv)
Animations/Transitions should run smoothly.
Lower CPU Usage.
My question is which is a better option to build this application. Microsoft's "WPF" or Adobe Flex(running in Adobe Air to run on desktop). And also respond as why it is better.
Be suspicious of anyone who will give you an answer like "Definately use xyz" to this question. There are pros and cons to both sides.
First, I think you might be confusing what WPF and Air are... WPF is a presentation layer on top of the .Net framework, where Air is a framework by itself. Apples and Oranges. If you want an analog to what Air is for the .Net stack, you probably want to look at Silverlight Out-Of-Browser, which is a much closer comparison to Air.
What is the difference, then, between WPF and Sliverlight OOB? Again, WPF sits on top of a very large .Net framework where Sliverlight OOB is a very light framework (in comparison) like air. It is the difference between a 200 MB download/install and a 12 MB download/install.
So, that being said, I think you should also ask what platforms this needs to run on. Silverlight OOB runs on Mac and Windows where WPF only runs on Windows. Air runs on Mac, Windows and Linux.
The next thing that I see is that you need to do SWF and FLV playback. This will be easier to achieve with Air, since it is native. You CAN do this with Silverlight OOB but you will find yourself rigging something up where you host an HTML control and run the flash movie inside the HTML control. It is a bit more clunky, but it will work.
Other than that, Air and SLOOB are very similar in features. It then comes down to your team and the expertise, IMO. If they are already familiar with the WPF/Silverlight, then a SLOOB app is well suited with minimal ramp-up. If your designers are more familiar with the Adobe suite of tools, then it might be easier to build a shiny app using Air.
In all, the decision between Air and Silverlight/WPF really comes down to preference. That is, once you get past any particular techincal limitations like the flash playback or OS support.
Hope this helps,
Brian
Recently I've stumbled over surface. It's incredible and so easy to develop small applications with surface. Surface is build upon WPF, so surface uses XAML. My idea is now to develop applications with surface. I've searched for some information about this topic. There is nothing about that. My question is now, why nobody uses the surface SDK with WPF to build cool applications. Are there any disadvantages?
I don't really understand your question. But here are some answers to what you may be asking:
Why aren't there more surface applications out there?
Most likely because of the price and the availability. It costs $15,000 for a developer unit and you have to be a business to even get to order it.
Why isn't the surface SDK used to build normal desktop apps
Because it doesn't make sense. The surface SDK contains Surface specific, and multi touch specific additions to the plain WPF stack so it is only useful for surface applications running on a real surface device (or simulator, but that isn't feasible for deployment)
Now if you are building a multi touch application for windows 7, there is a surface toolkit which is based upon the surface SDK. It has most of the nice multi touch enhancements but lacks the hard dependency on the surface hardware. It is very useful for general purpose multi touch development on .NET and is as far as I can tell also used quite much for this purpose.
Do you mean building Windows applications in WPF using the Surface toolkit? There is no reason not to do this. There is a 'good, better, best' model when developing multitouch apps, and if you want to create a true multitouch friendly application, then the Surface toolkit is a good way to go.
I have created an application using the surface toolkit but for normal wpf application.
You have just to have a multitouc tactil monitor.
and every thing will be fine.
It works :)
I am about to start development of a multi-touch application.
I need to decide between WPF and XNA.
Which would run faster ?
WPF already has libraries to support multi-touch via TUIO input.
Does anyone know a similar library or even just sample code to
drag/rotate/move objects in XNA ?
Thanks!
SW.
Touch is just another way of getting input from the user. Whether you route this input to an XNA app or WPF app depends more on what you want to do in the app.
XNA is a lower level api for doing 2D/3D on Windows, Xbox and Zune. WPF has only a higher level support for doing 3D and targets (currently) only Windows. So going with XNA vs WPF is imo more a decision of graphics requirements and platform support.
Since your app is graphic intense it could be more efficient to work at a lower level (read XNA or even SlimDX/DirectX). Reimer's XNA tutorials have a lot of great articles for starting out with XNA.
If you use XNA, you're going to be doing a lot of math to manually analyze the touch information - I'd check out WPF first (or perhaps you can host XNA visuals inside WPF and use WPF's touch input engine)
The Bespoke MultiTouch Framework supports multitouch and XNA together. Paul has a number of XNA samples already built to demonstrate the features you are looking for :-)