I don't ever really hear about Qyoto. My question is, is it still around and good to use? Would it be smart to use on one of my projects, or should I stick to gtk# or qt in another language? Are there any projects currently using Qyoto?
I write a small cross platform app in .Net. I originally wrote it on Windows with a WinForms UI. When I ported it to mono I found that the UI really suffered on Linux. In an effort to get a better Linux UI I rewrote the UI in GTK#. It is nice to have the designer, but GTK# is a terrible UI framework when coming from WinForms (never mind WPF). The fact that it is based off of a C framework really shows through. Many things show their procedural roots and it just doesn't feel very .Net centric. None of the controls understand the .Net Framework components. So, for example, you cannot bind a DataTable to a GTK grid control. Also, the documentation is very poor.
Since I use KDE on Linux I've been looking into Qyoto for a long time. Recently I got my application loading a Qt UI. I designed it with Qt Designer and convert the .ui file to C# with the uics tool. This extra step is a pain to someone who's used to Visual Studio. Additionally, Qyoto doesn't really integrate with .Net either. For example, the QT signal/slot mechanism is separate from the .Net event/eventhandler system. Again, the bolts and wires show through.
These and several other factors have forced me to move off of .Net for Linux GUI development. Again, since I use KDE, I will be sticking with Qt. My decision now is between Python and C++. Python is great for RAD, but I'm really looking for a great IDE and that is pushing me toward C++ (Qt Creator).
Last I checked, Qyoto was not stable on Windows. I'm currently using another .NET binding for Qt - qt4dotnet. Works fine but it you can't use Qt Designer with it and the API uses Java conventions because it's based on Qt Jambi. Also there is no integration between .NET events and Qt signals in qt4dotnet.
Update: Qyoto has recently been obsoleted, its successor is QtSharp.
Its very confusing, looks like Qyoto was originally based off another project called QtSharp. Now the new project is also called QtSharp :/
Related
I was making an application with Visual Studio, winforms and I'm using openTK. Recently I thought about making it cross-platform. I'm going to use Mono, because I don't know anything else similar. And I have totally no experience with GTK+. In my application, currently there are 4 windows(of course there will be more in future). I want to make application fast in Windows, Linux and OS X. I have read, that GTK+ is better than WinForms, but still not sure which to choose. So, should I remake everything for GTK+ or stay with WinForms and why? Also, is there any tool, which would do this work for me?
Honestly, you're going to need to tell us more about your audience/intended market to provide a great answer, but my $0.02 from some experience developing there is that GUI development for Mono on the desktop is a multi-target affair if you want to do it "Right". You're going to need to develop the shared backend exceptionally modularly, and then write UI once per platform.
Windows
Windows.Forms as implemented on Mono is a great crutch if your app's in its infancy, allowing you to target Windows immediately and deploy in a somewhat crippled fashion on OS X and Linux. Note, however, that I've been told on IRC that Windows.Forms development on Mono is essentially dead. Old bugs don't get updated, and, as a for instance, I ran into SelectionBackColor not working in RichTextBox on OS X (it's a problem in a lib Mono uses for Windows.Forms on OS X) within a few minutes of testing. Neat that it's there, perhaps good for quick utilities where you can code around its limitations (see question here for an example).
OS X
For targeting OS X, if you have a real, commercial, end-user app, you're going to need to get used to, um, interfacing with Interface Builder. I should make clear here that using XCode and Interface Builder absolutely requires that you have access to a box running OS X. Otherwise, you're stuck with Windows.Forms or, preferably, I think, Gtk#.
Xamarin has done a great job making its IDE stub out connections to native UIs built in XCode. That's how they do it for iOS development as well. It works fairly well, though the documentation is weak. There's a great video from 2011 from Michael Hutchingson describing this process, though I suppose it's getting long in the tooth (ie, "old"). (Direct link to video)
I'm assuming Interface Builder is also your only real choice if you want to target the Mac App Store. But look, it's a native UI that's stubbed to your C# code, which is, all things considered, a great compromise.
Linux
I haven't really targeted Linux. Seems like Gtk# would be a natural fit, but I'm not much hands-on help there. My stuff builds in Windows.Forms, and there are rough edges, just like in OS X. If I got more serious, I would start with Gtk#, and that's where MonoDevelop has its GUI RAD as well.
Example of a serious, mature, crossplatform Gtk# app
Quick note: Banshee uses Gtk# to target OS X, Windows (alpha), and Linux. You can get some great context for how difficult it is to use Gtk# on a large application cross-platform by checking out its mailing list and other resources.
Sorry the news isn't any easier. There is no silver bullet/single right answer.
201607 UPDATE: I think the answer is slowly becoming to use Xamarin.Forms to target cross-platform. You might still be stuck writing a separate Mac interface for now, but there's reason to believe that'll have Xamarin.Forms support at some point too; see below.
Unfortunately, if you're targeting Linux, I think you're still in the same boat as you were before for now.
Windows: You can now use Xamarin.Forms and UWP.
macOS: You're still in essentially the same place, but I had a Xamarin employee tell me last weekend that Xamarin.Forms is unofficially in development for OS X. I believe this is the repo on GitHub. (There's even a branch for tvOS.)
I would suggest that you consider what your target audience is. Writing UI using a framework like GTK# might seem a good idea but to the average user your application won't look like their other Windows/OSX applications which easily can stop people from using it (unless it's really exceptional in some other way).
The best way to do this (which might not be possible due to time/budget constraints) is to put your application logic in a separate assembly and then write UI for each platform, using Winform (or WPF) for Windows, MonoMac/Cocoa for OSX and GTK# for Linux. It also won't limit you to using features that are available on all platform which would degrade the user experience a lot.
I'm facing a similar problem now - but what Karl-Johan said about keeping application logic separate will make the task much easier. Look into a ViewModel pattern (MVVM), and you'll have much less code to rewrite and test for each platform, as the central logic becomes UI agnostic.
So we built a WPF app, now for our next version we need a Mac version as well.
Mono obviously jumps to mind, but our app is fairly intensive for the UI. Is there anything cross platform that is remotely close to what WPF gives you for styling your apps?
Granted the current app is C#, but if we need to go back to c++ for the sake of a clean UI that wouldn't be a problem. Is this a situation where you might eventually get back to writing two separate UIs in C++ one for cocoa and one for win32?
IMHO, it would be much preferable to have two UIs, one for windows, and the other for Mac using Objective-C/Cocoa.
There is no easy way to obtain a "native" user experience on the Mac without using ObjC/Cocoa. Programs not using Cocoa on the Mac can be spotted from far away.
Well, in the end, it also depends on your business objective and your value proposition.
Use GTK+ or wxWidgets or Qt or any other cross platform libraries with c++.
I would suggest an MVVM or MVC approach. The business logic written in C++, if necessary; wrapper classes in Managed C++ and the view completely independant of that. WPF already helps with that by splitting the view from the logic. Now for the mac part, i can't give a good UI Sdk for that. But seperating the business logic as much as possible from the UI makes it fairly easy to use what ever UI API you want to use.
I've always been a big fan of Qt
https://www.qt.io/developers/
a very nice cross-platform C++ UI framework
Probably the solution requiring the least effort, while still having a decent UI on Mac OS X, would be to use Monobjc or MonoMac. If you want to be lazy, you can always use GTK#. It comes by default with Mono and has the added benefit that it is also be compatible with Linux.
I am to develop an application on windows. I have never done that before ;-)
I need to do some heavy audio calculation, which has to be written in C/C++. This part will be a room correction algorithm which currently takes about 10 seconds per channel to run in Matlab. It has to be written in C/C++, since it might be ported to a DSP later on, which has to be programmed in C/C++.
Additionally, I need a GUI to review calculations, visualize results and modify calculation parameters. The tough part of this GUI will be lots of plotting of spectra, spectrograms, audio waveforms and the like.
Now, I hear that WPF is all the rage in Windows GUIs, but it seems to be limited to C#. Is there a simple way to integrate my C/C++ code with some C# GUI code? Or should I rather take WinForms and just write the whole thing in C++? Or would Qt work just as well and provide some cross-platform capabilities "for free"?
I have some experience with C/C++, Matlab and VST-development, but I never wrote a real application and honestly, I don't even know where to start.
Thank you in advance!
I think the biggest drawback to using WPF or WinForms is that you will have to program in two programming languages, which is a big logistics overhead.
I've seen this type of argument before: use C or C++ for low level, something else for high level. In this case Qt/C++ is as high level as WPF/WinForms, with the benefit of very easy integration of UI to your other C++ code.
For spectrograms and other graphs check out Qwt.
P.S: WPF is not all the rage on Windows, in fact the market is quite fragmented and WPF is one of the lesser used GUI toolkits. Most of the code out there uses MFC, WTL, Delphi, Win32, etc.
I have no experience on QT, but I can say that WPF is good but its not that good for high CPU intensive applications, plus you will not be able to directly integrate your c/c++ easily with WPF.
There will be huge learning curve and you will have to write COM Interfaces to communicate with C#/WPF and your native code. or Visual C++ .Net CLI, which is quite difficult and less tutorials are available.
But problem is you will not get any good support because lots of people only use C#, database apps only with WPF/WinForms. The best way to do is, you can write COM DLLs to integrate with WPF, but that will be difficult.
Instead there are various tools available now in MFC, and lot of other commercial libraries are available as well to write good UI in C++ MFC, where integration will be quite easier as you are familier with C++.
Or else Qt, if you already know it.
Libraries:
Prof-UIS
BCGSoft
There may be many, you can search for "MFC UI Elements", Library etc. I have used Prof-UIS way back in 2003-4 they are good.
WPF will tie you to Windows, but not to any language in particular. You can write WPF applications in C#, VB.NET, Managed C++ or any other .NET language.
Winforms is similarly tied to Windows, but you may be able to write your application in such a way that it also runs on Mono, and therefore is cross-platform. However, Winforms is far less capable toolkit when it comes to complex visualizations.
Interop between .NET and native applications is very strong, but it is sure to cause you at least a little pain. On the other hand, implementing the interface in a native environment may cause you even more pain.
If you're happy for your GUI to be tied to Windows and .NET, WPF is the best option for highly visual applications. If you don't want a dependency on .NET or Windows, Qt seems like your only option.
I am a long time MFC programmer and know it quite well. Recently we are planning for a large desktop application. In order to beat competition, one requirement is polished UI. We narrow down the choices to three:
WinForms
MFC
QT4
We looked at some big WinForms applications, such as Paint.Net, and feel that it still lacks power of performance. The startup takes a while and some UI parts do not look very nice.
We had great hopes in QT4, but after writing several programs on it, we find that the looks of a QT4 application is not at par with native Windows UI. It still looks differently. Also we worry about about lack of widgets (for example, the color picker and calendar control in the library quite suck).
MFC is a safe bet, especially with components from Codejock.com. The UI interface looks quite polished with codeJock toolkit. And all widgets needed are there. The problem is that its coding style is quite outdated.
What will you choose for your next desktop application?
WinForms is effectively at the end of its life now. You should look at WPF.
See WPF: Any cool UI ideas i can look at? for links to some nice examples.
WinForms is really easy to get into if you know MFC (it's still based on the core Win32 concepts, so you don't need to learn much to get up to speed). Compared to MFC, you can develop much faster, and there is so much more library support for everything in .net that you have to write for yourself or find 3rd party libraries for in MFC. Often I find the .net solution to a big problem is around 3-10 lines of code, whereas the equivalent MFC solution would be hundreds or thousands of lines. I wouldn't even consider MFC a starter now that I've used WinForms in C#.
We're building some very large C# applications and the performance is perfectly fine. If any small part of the program is really performance-critical, it's really easy to plug in a bit of unmanaged C++. I found startup times abysmal in XP in the early days, but with more recent .nets and Vista, startup time is comparable to MFC apps.
So I'd go for WinForms/.net at a minimum.
WPF is also a sensible future-facing approach to consider.
WPF is a good option if you've got design skills or can ask for someone to prettify your UI. I think it's definitely one of the most versatile options.
You could also use components like DevExpress or Telerik, both have an extensive library of WinForms controls and as of recently WPF controls. I've used DevExpress myself and am rather pleased with the looks. Although these library don't come cheap, but they do carry quite a lot of functionality.
I've never worked with QT4 so can't judge that.
For my next desktop app I would use:
on Windows:
Probably the old fashioned Windows API (without MFC) because I am familiar with it.
Maybe Qt, because I'd like to try it out.
on MacOSX: Cocoa
on Linux: Qt
Not that I am very fond of MFC, but if you are comfortable with it, go ahead. It is not going away any time soon, although it surely won't be updated and improved as much as WPF.
Having spent 12+ years developing MFC applications, and now using WPF for less than a year, there is no way I would go back to MFC. At previous employers, we would spend countless hours customizing UI behavior and getting the right graphical look that would take a fraction of the time in WPF. Not to mention the added flexibility of being able to work with the UI as XAML (XML,) as opposed to the rather outdated resource editor.
If your application has to be C++ (as opposed to C#,) then I assume that using WPF would be a little more non-trivial. I haven't done .NET inside of C++, but I remember the overviews presenting it as a fair amount of extra work.
We at my work are currently revamping a GUI app from VB6 to make it look "prettier". We've chosen the .NET winforms platform for our upgrade since most of our coders are familiar with it. .NET has a few libraries dedicated to graphics, and there is a wide range of nice-looking user controls already built into the library. Asside from those, there are many, MANY custom-made controls out there such as the ComponentONE library, and there are a lot of opensource controls for enterprise use that look nice as well (you can search CodeProject.com's articles section for some free, downloadable controls that look very vista/windows 7-esk).
The framework also natively doublebuffers windows, and has bufferedGraphics classes that you can use to manually handle doublebuffering if you so choose.
However, windows forms do still ghost when dealing with high res images as background pictures and the only way to really fix it seems to be to use the DirectX libraries to draw using the graphics hardware on the machine (which is difficult, but atleast its free).
Hopefully that helps your decision on the platform form the windows-forms side.
I would still consider MFC. It's far from dead and especially with the new 2008 feature pack. You get a host of updates and can now create those fancy ribbon UI elements. If you already know MFC then you know the pitfalls (old but some are still there) and can knock out the work quite quickly.
There a ton of UI components you can buy for MFC and it has the benefit of being fairly close to the metal as far as speed goes. There is no need for your end users to install a framework or anything else.
I write C# for my day job, but all my personal projects are MFC/C++ since they don't require my users to have additional frameworks,libraries,etc installed.
Looking at the C# project templates in VS2008 and the offerings are WPF User Control Library, WPF Custom Control Library and Windows Forms Control Library. Which of these would you use if you wanted to move a legacy active control written in c++ into the world of C# and .NET?
It sounds like you are trying to do several different things all at once:
Migrate your code to building in a newer version of visual studio.
Migrate your use of technology to a newer technology (ActiveX to .net)
Migrate your language (c++ to c#).
If you have a small codebase you are probably as well to start from scratch and port functionality into the new codebase as required.
For a larger codebase you need to realize that this is an expensive task both in effort and defect rate.
An order might be:
Import your code into the newer version of visual studio. Get it compiling. Review the project settings for each project.
Refactor your code to isolate the mfc and activex code as much as possible. Follow good refactoring practices especially if don't have many unit tests before you start.
Consider replacing your ActiveX layer with .net.
Consider which GUI toolkit is best for replacing MFC.
Language - consider moving first to managed c++.
Consider moving from managed c++ to c#.
Most importantly be able to justify doing all of the above!
There is no project template that will do this for you. You might as well read up and start with a usercontrol.
You would have to consider the target application that will host the control. If it is a line of business application I've heard that WPF doesn't offer great advantages over Forms. According to this blog entry however, the author believes that the killer WPF is a LOB application that leverages the graphical power afforded by WPF for data visualisation.
In the end I guess it is a cost/benefit analysis. Do you go down the WPF route and pay the cost of the learning curve for the future benefit of graphical data visualisation or do you stick with the tried and true method and risk developing an outdated application.